 Alright, so the first announcement we have to make is uh that we are running CTF challenges and those challenges actually started yesterday because we are doing a workshop but for some reason nobody really wanted to do anything interactive in the workshop and that means that the challenges are all three still unsolved. Uh those are smart contracts on the ethereum mainnet so if you look at those and this is actually a little bit funny because somebody tried to solve the challenge but in the process of doing so he failed and he added even more ether to the contract so now you can add you can win a little bit more and and this was his second attempt which also failed. So if you're quick enough you can win a total of one point five ether which would be around three hundred dollars worth. Uh and you find this here uh on this GitHub repository. Sure I hope you can read it. It's uh smashing smart contracts workshop or just Google for it. Alright um so we are going to talk about automated exploitation of smart contracts on the ethereum blockchain. Um we are both from consensus uh I'm chief hacking officer or whatever that means at MythX and Daniel is an auditor and researcher at consensus diligence who do uh security audits for smart contracts. Uh so normally we uh help developers to create more secure smart contracts but we also do some offensive research because we want to stay on top of our game. Uh there's a lot of other people who contributed in some way to this talk uh and the code we are going to show so we are going to show four tools today three of which uh introduced for the first time. Uh and there were a lot of contributors involved so all of this is open source uh the MythX core team uh the consensus diligence guys uh um Samson who is a very famous researcher who contributed some of his uh bot research and the ethereum security community in general which is small but really awesome. So uh what we are going to cover is uh first of all symbolic execution for automatically detecting bugs in EVM bytecode and we are going to focus on instances of bugs where uh the attacker steals eth, eth is the native currency of the ethereum blockchain from other contracts so the goal is always to increase your own balance in some way. Uh we are then going to show how to automate this exploit and uh basically write a script kitty tool that you run against the contract and we do everything out of the box. And then we are going to show how to exploit people who are using these tools by tricking them into sending you eth because they don't know what they're doing. And then on the next level we are going to show you how to exploit people who exploit people who use these tools. So it's kind of a a layered approach. A very brief intro to ethereum. Ethereum uh is a blockchain network and it's a distributed state machine so you have this uh so called world state and there's a huge network of nodes and they all agree on the same state which includes account balances so uh the uh the state uh uh includes accounts and every account has a balance and each time uh and transaction gets accepted into the blockchain this changes the state in some way so it might decrease one account's balance and increase another account's balance. And the network is permission less anybody can send transactions but they have to follow the consensus rules of the blockchain. So what uh makes ethereum different from bitcoin is that uh you have a lot more flexibility of how uh transactions can change the blockchain so you can deploy small immutable programs called smart contracts which uh basically uh chunks of byte code in a uh written in a simple stack based language. And what's special about them first of all is they are immutable so once a smart contract is deployed to the chain and you have consensus that this smart contract exists it can never ever be changed. So it's much more like a real world contract where you have a set of rules that everybody agrees to uh adhere to then like an app that you can update anytime later. From the view of symbolic execution there are a couple of things that are interesting first of all executing instruction uh on the ethereum blockchain costs gas which is paid in ethereum's native currency ether uh and that's a spam protection because uh computation is expensive because every node in the system needs to run the same code right? And that means that in a single transaction you can only do a limited amount of uh computation which is good for symbolic analysis because it mitigates state space explosions so there's only a limited amount of states you have to look up. But on the other hand uh the world state can be mutated over subsequent transactions so you can basically split up your computation into little chunks and uh that makes symbolic execution challenging again because you run into the traditional problems of state space explosion and so on. So brief primer on symbolic execution uh here you see a very simple smart contract that's written in Solidity which is the most popular language at the moment and the smart contract represents a cat and has one function and this function either extends the cat's life or it kills the cat and there's a very interesting instruction in Solidity called self-destruct. What this uh instruction does is uh so it was originally called suicide who essentially the contract is going to kill itself, it's going to delete its own code uh and free its storage and um send its remaining balance to an arbitrary address that you specify here. In this case uh it's the zero address. So if you look at this program there are two outcomes that can happen right? If this Boolean variable is true then grand survival is false. Ah sorry it's true and the cat will not be killed, we will reach a normal stop state but on the other hand if it's set to false we will reach the self-destruct instructions. So these are the two possibilities that can happen. So what we do in symbolic execution now is that we uh every time we reach a conditional jump we follow down both paths and we annotate each edge on uh so if you look at this as a uh control flow graph we annotate each edge with the path constraints imposed by the jump condition right? So we can say that uh if the first function argument is true and this actually looks a bit complicated because that's what the Solidity compiler produces but it ends up meaning if it's true then the cat survives, if it's false the cat does and so you could think about the cat being in both states simultaneously. And what that allows us to do now is uh we can ask if you want to reach the state where the cat dies what are the input variables we have to supply to the program? And we can do that by passing this uh path formula uh or this proposition to an SMT solver uh we use set three in mithril for example and this will give us the correct input values that we need to send. And this uh propositions can be arbitrarily complex right? So we can look at very complex programs that have many input variables but we will always get the correct result. So I'm not going to go into much more detail um because we actually practiced this talk a couple of days ago and it turned out to uh take about three hours to do everything so we need to cut uh things down a bit. But if you're interested there's a good execution by my uh uh a good summary by my colleague Joran talking about symbolic execution and then there's a paper I wrote last year called Smashing Smart Contracts that goes into a lot of detail uh can also recommend uh this paper Knowing at Ethereum and there's a lot of other stuff you can just find on Google. We'll have a few more reference at the end of the talk. Right so our symbolic execution tool is called Mithril and it's designed with simplicity in mind so uh if you want to use it you can install it with Python 3 and you can then either analyze solidity code files or contract addresses at either the main net or a test net or uh whatever you like. And I'm gonna show you a very brief demo or half that looks like. So this is a killable smart contract and it has a kill function that uh calls self destruct and there's one prerequisite that we have to fulfill so you need to be in the map of allowed addresses that are allowed to kill the contract right so you have to call a sequence of transactions. The first one is set allow to set uh this mapping to true and then you need to set kill. And so this might look like a very simple demo but that's actually something that happened in practice so I think in 2017 uh there was a heck of the parody wallet library that uh in principle was very similar so there was an initialization function that was exposed and by calling that function you could kill the contract and that's led to I think uh 150 million dollars being vaporized basically so they are not stuck in this contract forever and nobody can ever access those either again. So I'm just gonna show you a small video of how myth will so you run a myth analyze against the source code and the output will be the sequence of transactions that leads you to uh the kill instruction but it will also compute the instructions in a way that the remaining either gets sent to your account right so if you call set allowed and in this case that beef, that beef, that beef represents the attacker's address you would replace it with your own address uh in the second transaction you call kill to kill the contract and then you can see that this first argument specifies where the remaining either should be sent and that's also the attacker, that beef, that beef. So if you just replace this with your own address you will get the either out of that contract. So that was a very simple example but uh myth will can also solve more complex stuff that that goes deeper into into the contracts and so if you get started in Ethereum security uh a very good idea is to check out uh CTF's and challenges and some of the best uh ethernots uh done by open sapling, captured the ether by Steve Marx and the blockchain CTF by security innovation and I just pulled a couple of examples to show how our tool can uh solve these challenges out of the box. So if you look at this code here uh you can see that this is a little bit more evolved so we have a withdraw function that withdraws the contract's balance to the ether and we have a contribute function where somebody can contribute a little bit of ether and then uh some mappings will be set and it will be added to uh uh this mapping here and then there's a fallback function. Fallback function means a function with no name that gets called when none of the functions thing just matches and this may overrides the owner with your address and there are several ways of how you could exploit this but there's one way that is most profitable right where you send the least amount of ether for the most output and Mithril can compute it for you so so I will not show the video now I will just tell you what you have to consider when running Mithril here. So the first thing is that this uh vulnerability is three transactions deep and by default Mithril only symbolically executes two transactions and so the thing is in symbolic execution the state of space that you need to investigate grows exponentially so the the more you set here the longer the analysis will take and for like more real life complex contracts that can be quite a while up to many hours or even days um so the default here is two and if you run it with uh with the default you will not discover anything here so here you would have to set three transactions and then execution timeout if you want that will abort the execution uh if it goes over the timeout because you might not be willing to wait a couple of days for result so what you get here again is the correct transaction sequence to maximize your profit maximize your profit and what you do is you contribute exactly one way which is the very smallest uh denomination of ether it's basically uh like a billionth ether or so and then you call callback with one way and then you call withdraw and this will give you the whole contract balance alright so I briefly mentioned the state space explosion program so look at this contract here there's uh a lot of functions with dependencies on each other and so what Mithril does it uh executes smart contract code in iterations and once you find a valid stop state it will then use as a starting state for the next transaction so you can see that the space of states to explore grows uh very fast and for something like this that use uh needs six or seven transactions it can be quite a while and the couple of ways that we use to um address this problem uh the main way is pruning algorithms so what we're trying to do is to figure out which parts are actually relevant to explore that means for instance uh if you execute a transaction and the machine state at the beginning is completely identical to at the end like if you execute a pure function or view then you can safely discard that state because running another round of symbolic execution will not get you any new results uh we can also do reachability checks so at each basic block we can check whether the constraints can actually be fulfilled or not this also gives us a nice speed up and the probably most advanced thing we do is uh to look at dependencies in between transactions so once we execute the first transaction we build a map of state reads and writes and as soon as we come to the second transactions uh we have some rules uh that allow us to discard a lot of the parts that we encounter uh for instance if there was a state variable that's modified in the previous transactions that is accessed somewhere along that path uh we know we need to execute the path because we might be discovering new pieces of code or new behavior but uh if none of these things is fulfilled we can just not execute the path just to show you um how this looks like so this is a state space graph of a typical three transaction execution and you can see execution here starts at address zero uh and as we get further down we will reach uh several stops and one of these for example is here sorry for that so if you look at this basic block here you will see that execution starts from uh program counter address zero again and and then you get this tree of exponentially growing states and that's not a good thing because it makes uh execution really slow so with pruning enabled you can see we can reduce the number of states quite considerably uh in the example I showed you before it's down by 60 to the percent and this gives us a nice speed up so we run some benchmarks on uh the SWC the smart contract weakness registry and we got speed ups that compound over time with a number of transactions uh as you reach less stop states it uh really gets quite fast but that doesn't mean that it doesn't still grow exponentially so we're still looking at a lot of other things we can do including um parallelization so obviously we could use uh more than one core to run the analysis uh state merging which is one of the techniques called uh used memento core uh and function summaries so that means uh instead of executing functions over and over again uh you create summaries by uh by looking at the constraints exposed on memory and storage by each function and just uh reusing those instead of uh re-executing the code and uh yeah this creates more complex server queries but also speeds up execution and reduce number of states you have to look at so we're already I'm a little bit over time so I will very quickly show you a demo of Scrooge McEtherface which is the next tool so what this tool does is uh it creates the exploit transactions uh created by Mithril and it just sends them to the blockchain and it gives you uh interactive CLI where you can temper around with the transactions a bit uh so this is Ganesh which is a local test node you can see here you have several test accounts and the attackers account is the second one here it starts with 100 eth so I'm not gonna deploy to this test blockchain uh version of a wallet library which is actually the library I mentioned that was exploited in real life before and I'm going to give you a little bit of balance 5 ether so you can see uh it was created and the balance was deducted from the creator account now I'm gonna set up Scrooge with the config in it to connect to my local node and so now it's this is really really script kitty friendly so the only parameter it takes is an Ethereum address it will automatically detect the exploit so in this case you can see the contract can be killed by anyone and what you have to do is uh send this exact sequence of transactions and you now get uh class interface that you can interact with uh you get a list of rates and each rate is represents an attack and these rates have steps that you can uh either first manipulate or execute one by one and uh yeah so call function one with this argument call function two with another argument and then you simply call execute so transactions have been sent and it actually also checks if your attack was successful and if your balance has increased and in that case it gives you a boolean true back so you can see the attacker now has gained 5 eth which is uh um a thousand dollars I think at the moment so that's our tool full screen demo so now that you have this tool you could imagine it would be very easy to use it and steal stuff but unfortunately the Ethereum mainnet is a very tough environment and it's not all that easy so if you naively use these tools there will be uh a lot of people uh out to exploit you one of them is uh front running bots so they will actually monitor the mainnet for exploits being executed and uh Daniel is going to talk about that a bit and they will try to preempt you and steal your exploit and execute it faster than you and actually make your exploit fail and then there are also fake exploitable contracts called honeypots that for example might know that our tools have some false positives and they might make it look like they are vulnerable but if you actually execute the attack they want and they will just require you to send a bit of ether and then make your attack fail and yeah it's super dangerous so go ahead to over two. Okay so uh once again I'm Daniel Luca you can find me online at Clean Unicorn uh I kind of felt like I have to be a white hack with Clean Unicorn dirty unicorn was taken but anyway okay so I have two tools I'm going to show you uh the first one is Carl its purpose is to um mass scan the Ethereum network and find vulnerable contracts it will generate like uh local reports that you can reuse then and the second one is uh Theo it's more specific because after you find the vulnerable contract you will actually um find a way to uh it will actually enable you to exploit that contract. So um Carl it it does mass continuous recon so that means that it watches the blockchain all the time so you can you can um start it it will scan all blocks it will scan all transactions and see if any of the transactions generate new contracts on the blockchain and if they do that it uh pulls up the uh the code uh it pulls up the state and finds and tries to find if it's um tries to find out if it's vulnerable it uses method for that it because it's written in um python you can use the method libraries directly it does exploit generation and it also does uh exploit validation because sometimes there are vulnerable um false positives but it has a way to reduce that number of false positives. So um this is how like the the main the core of uh Carl it uses as I said it uses the method libraries so you can you can do this yourself if you know a bit of python you can um import libraries uh start up the method disassembler you uh point it to an ethereum node and then you tell it to um load from the address the contract address so that means it knows who to scan and then you start the method analyzer it has some parameters that you can play with um for example uh the timeout the number of transactions um what um what modules to test so for example the uh default modules that I'm using is stealing ether and self-destructing contracts you can you can create others and there are already others available in mithril and it generates a report something like this so for example with this report uh we have unprotected ether withdrawal so there is the smart contract um ID uh problem ID is like 105 always forget this um this um thing so the severity is high because you can extract ether and then it tells you some other uh information like what's the contract address but you kind of already know that because you were uh scanning for it the uh um estimated gas usage and the text description just so you have an idea of what you can do with it at the end of that you can see the transaction sequence so what transactions you need to send in order to get ether out of that contract so it makes it really really easy for you the problem sometimes is that you find a transaction sequence but it's kind of hard to make sure that that indeed works as I said sometimes there are um false positives um it's it helps if you know assembler if the source code is available if um if you have all of that available but even then it's still kind of hard so there Carl already has implemented a technique to help you validate the exploit so it uses uh it still uses ganache so just a a small intro uh ganache is uh local ethereum development node um and it just generates a local network for you nobody else can connect to it but it behaves exactly the same as the ethereum network so that means that you can simulate all of the transactions and see if that works so how it actually does is that it forks the main blockchain and uh it sends the transactions to that but when people usually hear forks it's something like there's contentious forks like people are fighting there are two communities and they want to develop the um the network in two different directions something that one feature would be the best other thing that another incompatible feature would be the best so what usually happens with forks is that uh the community splits into two and then you have two different uh networks uh if you know for example bitcoin and bitcoin cash or ethereum and ethereum classic these are two very popular examples but what I actually use is like the technical part of forking the blockchain so in this example on the top part you you see the real blockchain and let's say that Carl identified that in block 100 there is a contract that was deployed and then I need to make sure that this actually works so what I what Carl does is that it starts the ganache and then it creates a different future for that blockchain so for example block 101 is local it's only on my machine the top one is real and the bottom one is local so then in block 101 I can add my own transactions and see in the next block if indeed I exploited that contract so this is uh pretty safe because you're not sending the transactions to the main net you can actually see if you did a good job and exploited the contract and nobody else can see the transactions and nobody could front run you and nobody could do anything to you um so I have a demo of Carl so um in this example I start Carl I pointed to in Fira main net which is a public Ethereum node anybody can use and also ask it to start from a specific block um I do that because I already deployed a block uh a contract there and I know it's vulnerable otherwise most of the times you wouldn't see anything I enable sandboxing which is the forking technique uh which um uh creates the local blockchain and tests uh the the exploit generated and I also enabled uh the output the folder just so in the future I can have a list of files with the exploits available so it's scanning this block it found the contract it finds one issue but it's also firing the sandbox tester so it in this case it's quite fast you can see that you have an initial balance of 100 and you have a final balance of 101.1 so that means uh the exploit is uh uh is valid and you could use this and um exploit the contract this contract I think it still exists on the main net and nobody's actually exploiting it so I'm I'm super sad about that so what Carl does next is that it takes the next lock it checks uh the contract and scans everything so it goes through all of the blocks and you could just leave this overnight and come back in the morning and see if you found some some vulnerable contracts. So the next tool is Theo. Theo picks up where Carl left off so Carl just generates a list of contracts but Theo can actually exploit them. So um it is kind of an exploitation framework because it helps you do some kind of recon uh you can check some things on the main net um you can run the exploit and we also have some uh features that are front running, back running or sandwiching transactions and I'm going to go into detail about that. But first you need to understand what the mempool is. So um miners exist on the main net and they have a list of local transactions that were not added to the block yet. That means that these transactions if they will be added to the block they will actually start to exist they will actually happen. Before that they're not real they are pending transactions. So this miner has a list of um a few transactions and then they receive from the network a new transaction so that means that they will add it to their um mempool list. What actually happens in the network is that you have all of these miners uh people who want to send transactions to the network send to one random or less random node and then everybody sends the transactions among each other in the end they can all kind of have the same main pool but not exactly. But the idea is for everybody to have uh as many transactions as possible just to have the mind. The cool thing is that you don't need any permission to be part of the network. So if you look in the bottom part you can see a hacker who can listen to the mempool and see what transactions will happen on the network but we're not mind yet. Another important part is transaction ordering. So the miners every time they find a block they get a reward so they get some ether. But they also get some fee. Each transaction has a fee attached to it and uh when they add that transaction to the block they also get that fee so they are incentivized to add as many transactions as possible and to have the transactions as profitable as possible for them. So the transaction fee is calculated by gas and gas price. Um the gas part is for each instruction there is a number of gas added so you need to pay for uh complicated computation for example if you do some cryptography if you do some um square um operations you will pay more than compared to a simple addition or simple subtraction. So you have gas times gas price and the gas price is set by the sender if they want to their transaction to happen faster they will have a bigger gas price otherwise they will have a lower gas price. So when the miner um creates the list to um add the transactions in the block they will usually sort the transactions descendingly by gas price and they will add as many as possible until they fill up the block. So in this case we can see that the first transaction added uh has gas price 5000, the second one is 2001, the third one is 2000 and so on and so on. So front running happens like the idea of front running is that you have an information about what somebody is going to do. In this case you see what the mempool is going uh has uh in there but didn't happen yet and you raise them and you do that action first. So in this case the hacker can see a transaction they see that um a specific contract uh is called. The gas price of that transaction is 5000, a specific method is called and once they do that once they see that they can add their own transaction. So in order to front run the easiest way is to just take the transaction add one to the gas price so that means that the miners by sorting descendingly the transactions by uh gas price yours will be ahead of theirs. So I have um an example but first I need to go with you for um through the contract. So we have a contract with two methods these are uh the two important methods in this example. You can claim ownership but the important part of claim ownership so uh this transaction does two things. It accepts 0.1 ether and you need to send that and if the contract was not claimed by anyone it will make you um the player of the contract. The second transaction um checks if you are the player of the um of the contract and if indeed you are they send you all of the ether available in the contract. The cool thing is that if you're the first to do this you will become the player but if you are the second you just add more ether to the contract. So I can show you a demo and um you can uh what we did is that we made a honeypot after this and um this is how it works. So in this screen I have a local geth node which is the official ethereum implement implementation. So it's just mining it's just creating blocks at the moment. And in this screen I have um a local ID it's a web ID that people can use to deploy contracts and test contracts. So I already have this um contract deployed. It has uh I think 10 ether attached to it and it needs 0.1 ether from the attacker to claim all of those 10 ether. Okay. So now I start Theo. I provide Theo uh the accounts private key because Theo needs to have an account in order to send transactions so it needs to be able to sign transactions and send them to the network. And then I also need to provide the contract. Um what it does now it uses the method libraries it scans the contract and it finds uh the exploit path. You can also uh add your own transactions. So it found a vulnerable path uh it's very similar to what uh Carl does to what Scrooge does. So let's say for example um Scrooge is trying to exploit this contract. So what I do now is that I just extract the first exploit and I start front running. So what it does now it's just scanning the mempool for new transactions. So it just looks at the mempool. It queries the ethereum node every second or so and it sees it it checks if any interesting specific transaction is added to the mempool that will be added in the next block. If that happens we will see what what it does. So um now I'm simulating the attacker or Scrooge. So I'm changing to uh Xerox FFC. This is the attacker or the script kitty. He needs to add 0.1 ether. He needs to call claim ownership. So he's trying to uh extract that ether. He's trying to become the owner or the player of the contract. And what immediately happens is that Theo sees that transaction and it adds uh its own transaction. It increases the gas price just to make sure that uh Theo's transaction will happen before the script kitty's. The script kitty will also try to retrieve the ether out of the contract. Theo also identifies that. And it's sending its own transaction and um hopefully at the end we will have we will see more ether in our um in our account. So Theo's account is Xerox 1DF. The one that we see now it's um 110 ether. So it successfully exploited that um that script kitty. So um this was all done locally. And then we thought what if it actually works in the wild. And we had to test it. And um what we see here is that we deployed a very similar honeypot. And this is the victim's transaction. About an hour later somebody tried to exploit the honeypot. We also added this contract source code to make it easier for them to exploit. They didn't know that something was up. And they added they sent a transaction with um a very high gas price. I think they were trying to make sure that their transaction will get picked up really quickly. And so in this case you have 261.12 GUI. And the nonce and uh the position in the block is one. And Theo's transaction was um 261.13 GUI which is like the minimum necessary to uh front run the transaction. And the nonce was zeros and because we're like everything starts at zero it was just before the attackers transaction. So that means that uh they became the owner and they also got the attackers ether. So there are cases when this actually works. You have to deploy your own honeypots and you have to design them in a specific way to make them vulnerable for front running. In our case it also helped if we shared the source code. And a very interesting example that might um have a bigger impact is with decentralized exchanges. So a decentralized exchange it's something like a normal exchange but it exists on the blockchain. So what you can do is that you can sandwich other people's transactions. So for example you see that they will buy something. You buy just before they do and you sell immediately after they bought. So you just you earn some money by doing almost nothing. And there are some cases where it fails. Um it's kind of hard to see what a transaction does if they use a proxy contract. So they use an app in between them and the contract that they're going to exploit. It's impossible to front run if the miner uh is the attacker and they add their own transaction. So that means that they don't need to add the transaction to the mempool first. Um sometimes the ethereum client decides to be unresponsive. But there are ways to defend against the O. So you can create a contract yourself and make sure that at the end of the contract you have more ether than what you initially started with. And if you know that you can also create the honeypot in order to not be uh to beat this too. So there's there's a lot of where you can you can fight a lot on the ethereum network and this is just like there there are a lot of layers. So um what I really want is that I think we need more hackers. I think there are not enough people who are hacking on the ethereum network. I might regret this but at the moment I feel like we need more of you guys to exploit the network and find more problems and just have fun. Um so we have uh a links some links here. So this is um well these are all the tools they're all open sourced. Maybe one important thing to say is that all of the ether that we stole from the people we gave it back. Um and uh I think that's it. We are um open for questions. I know there aren't microphones but we can we're available immediately after this.