ETHKL#5 - Part2: Petar Tsankov (Chain Security) on how not to get hacked

[Music] so the next speaker is all the way from Switzerland he's dr. Peterson called a PhD from ETH Zurich not to be confused if you teach for a theorem one interesting anecdote I guess from helble's for your view is that when we want to do our token sale last year we were to search high and low for good security auditor we couldn't find we know lalu is now in Kaiba was busy we both will enter at a point consensus doubling all were busy and luckily we found out about this team from ETH Zurich University I just studied on at that point in time I took a stab at it and now there are all over the world presenting a DEFCON 3 ed code and multiple other conferences and with multiple services around so not more necessary more than that I'll just get dr. Peter sank off to talk about how not to get hacked please give a round of applause thank you for the very kind introduction and thank you you and David for inviting us here it's great to be in Malaysia to talk about some of the work have you been doing yeah so let me first introduce the teams that are working on the product that I'll be talking about so on the left you see the research team from ETH Zurich which is working on the research side behind this the technology that you're building and on the right you see that change security team this was shot when we were in Prague few weeks ago so what you're trying to show is as we all know security is one of the major issues that that exists in the film today and we've been working really really hard to make sure that these dozens that we mitigate this issue so that just as you know only this year one more than 1 billion dollars were lost to do two hacks in the until you micro system so in order to fix this issue it's it's very important to understand actually what what is the lifeline of a smart contract and worse security issues appear in this English stage so typically first you will start with the development of the contact meaning you figure out what you want to build and you develop it and the main issue here is that smart contracts are written in new languages people where people are not super familiar with them all right I think that's working so problem ourselves if they're not familiar with them and and they take they make common mistakes introducing vulnerabilities so that's what that was that's the first major issue once the code is done then as we all know the code goes to a code audits to make sure that a third party to certify that it actually correctly implements the functionality that is intended in the smart contract and once the audit is done it goes is in the point on the blockchain and users can start using the smart contract so the main problem with the code what it faces that currently most of the audits are actually don't clearly manually this means that people manually look at the code line by line in fact to figure out if it correctly implement some functionality so what we're trying what we're doing to fix this problem is we're building advanced automated tools to help developers certify their contracts while they're developing them we're also introducing something called machine check audits this means that you can use a machine to certify that the contract is correct without relying on Depot that the code is correctly implemented and we also have monitoring solutions that would allow clients and users to track what's happening to the smart contract whilst you deploy it onto the blockchain so I'm going to briefly talk about the techniques that were building in this in this space here all right so the first instance that we actually started building is in the automated security two space is we built a usable security scanner for solidity and then we also poured this this system to hyper ledger and let me show you what this is so how many people have heard about security file it's one of them all right not many of you so I'm going to tell you what the system does so the main it is that you want to quickly detect generic security vulnerabilities what about the Dow are cave people heard about the Dow Huck all right most of you so this is actually illustrates what happened in the Dow hack the issue was that we had this transfer of either to a contract and then you had zeroing the balance of the user after the transfer is done and the issue is that when this call here is made this actual transfer transfers control back to the contract so malicious user could actually take more money than that then it then it is then it is actually allowed so in order to prevent these issues typically you want to have some kind of security property that captures this unintended behavior so in this context here you may want to say that we don't want to have any state changes after Co instructions like this one so in this case this would be a violation because the balance is said after the Co is made so why is it actually hard to do why is it hard to automatically find some generic vulnerabilities in the code so let's take the security property as an example if you take a smart contracts based on this property I can look at all the Co statements in the contract and I can classify whether they're safe or unsafe with respect to the property so whether they satisfy or violate this property okay and then the questions were can you actually given a contract automatically check for each Co instruction whether this holds or not how many people think this is possible how many all right it's actually not possible and the reason is that smart products are written in turing-complete languages and this means that it's not possible to decide such arbitrary properties on arbitral contracts so this is really the major issue here and when we started working on this all the existing solutions were basically avoiding the problem by looking at subsets of these behaviors and the problem is that while you're looking at some behaviour which means you can actually miss miss to report some of the vulnerabilities which is not really what you want if you want to make sure that your contract is secure so then we wanted to do better than this and we had the following insight we actually looked at many real-world smart contracts and many violations of this property and we it turns out that very often when the smart contracts violate or satisfied such security properties they also tend to satisfy our violence much simpler much simpler properties or patterns so let me tell you what this means in this example so if I want to make sure that this security property holds meaning that I don't have any check state changes after KO instructions I can simply look at the control flow graph on the smart and make sure that no rice can ever happen after such construction and this kind of patterns are much easier to check and this one here in particular if you actually write it on the Union button you will see that you can certify ninety-one percent of all the coin structures in the contract and you can also do the same by the way for violations you can also pray simple simpler patterns that capture definitely violations of these properties for instance if you if you see that a right must always follow a co instruction then this property is guaranteed to be violated so this is exactly the idea that we used to build a security file system it's publicly available here on the subnet so you can go and check it out and this was just one example of secure security property that it supports the actual system implements many other security patterns that you could that you could check your contract against alright so that was the first system we built and this is very useful if you want if you want to target generic security vulnerabilities however very often you also care for to take contract specific properties from your smart contracts because you when you write it you want it to implement some very specific functionality so for this purpose we do this system consume symbolic verifier let me show you what that was the idea here so what's an example of contract specific requirements for example if you're implementing a crowd sound that is meeting tokens you may want to have requirements such as the owner can not means more than 1 million tokens or you may want to make sure that the amount of tokens never decreases so you can just list all the requirements that you have for your smart contracts and then the goal is to verify that these requirements are collected correctly implemented in the source code of your contract so very roughly if you want to check these requirements what is intuitive what is what is the problem here so in order to check it what you have to do is you have to start with the initial block of the smart contract so this is basically the state of your contract once you deploy it and then you can brute-force all the transactions you can send to your contract you can see where the state with the states changes into your smart contract that would be ten to one of transactions then you can do this again you know run again a bunch of transactions and then you have to keep doing this over and over again and then you have to make sure that you know the states here that you can reach with any sequence of transactions or the properties that's that's the core of the problem well that's very hard to do in practice why because this width of these three is really gigantic just think of all the possible transactions you could actually run on a cart on a smart contract and also this depth is unbounded because your users can send any number of transactions to your smart concert so that's inherently the challenge that you have to solve if you want to verify these properties so that's why we don't do this kind of brute force approach we do something else and very intuitively what we actually do is we first instead of running concrete transactions build on something called symbolic transactions meaning that you run with symbolic values instead of concrete values so here my branching factor is now 2 if I have two extractions it's not the total number of transactions you can send to the contract and there is something that's very critical is you also have to use kind of abstraction at these levels when each of these blocks is represented symbolically it captures number of different states and if you use abstraction you could actually guarantee that you get a fixed point of all the states you could reach so if you combine the symbolic reasoning with abstraction what you get is you get a feasible width that you can analyze which is branching on the number of functions in your contract and you can also get a bounded depth on the tree that you have to explore that's the key here so we have build a system based on this idea and there's a specific language that you can use to formally specify the requirements for your smart concert and then the system would either verify not verify or fail to verify sell some properties so it's a completely black box solution that can certify correctness for any sequence of transaction for of any length so this is the system for contract specific requirements and the velocity so to build us an a a base testing solution for smart contracts let me show you what's the idea here so again we start with the initial block of your smart contract and you want to fast your smart contract to see what happens so totally the way this works is you generate random transactions you execute them on the contract and then you get a bunch of space that you would observe while you're running your while you're closing your smart contracts and then here on all these files you can check your properties to make sure whether they hold or not so the hard challenge here actually is to come up with what kind of transactions you have to run on your contract in order to get some high coverage over the functionality whether it's code coverage or any coverage you can think about any metric on adding any notion of coverage over over your smart contracts and the key inside that we leverage here is that if you instead of doing this random through kind of transactions you could actually lose the machine learning to learn what kind of transactions tends to achieve high coverage on general contract so you can just take a bunch of say crowd seventh token contracts and learn this kind of get this kind of knowledge you could also just take the transactions that are deployed on the blockchain and learn from those and then this way you could get significantly higher coverage so just to give you some insight of how much better you could do say if you do run up testing random generation photos that you would get to something like 70% coverage on average contracts and if you do this area based solutions you could quickly converge to much much much higher coverage or over your smart contract all right so this is actually the main technologies that were building for correctness and briefly mention how we use them for bodies well actually we have built an audit platform that combines all these technologies to provide audits for contract so you this audit platform would take the contact the specification of the contract and what's produced on audit report based on the based on the results from these systems and we have been very lucky to work with many clients including hello goat that was last year right and final the final program very quickly mention is that we have you the security or security monitoring solution that could track all the transactions and you could customize it with different properties you want to check on your smart contract and make sure that those holds and if something goes wrong you know it could alert you to fix these issues all right that's everything from me thank you very much