 All right next up. We have an awesome talk on smart contract honeypots by Ben Schmidt. Please give Ben a warm welcome Hi everybody, I'm Ben Schmidt I'm CSO at Polly swarm if you want to find out more about us talk to me afterwards, but jump right in because Hoping we have enough time, but Today I'm gonna be talking about smart contract honeypots which are Vulnerable things that look like vulnerable aetherium smart contracts that people have been deploying to the main net To try and trick people into sending aetherium to them And then actually failing to exploit the contracts so that the attacker can actually take all their money What we're not going to be talking about today are how to find these things scams that aren't really about trying to attack people who are exploiting smart contracts or Whether or not that's legal or not, I wouldn't recommend doing it, but You could take that as you will so first off just need to go over Some basics about aetherium solidity for people haven't looked at it before So that you can sort of understand what's going on in some of these tricks but the aetherium is a Blockchain platform that allows you to not only send money, but also write smart contracts that Process money in interesting ways So there's two types of accounts that you can have an aetherium One is an external account, which is what normal people use they send money To and from other people and it's pretty standard for crypto currencies The other is a contract account which essentially has associated code and data And that code actually manages How funds fund transfers work and can record things to the chain, etc. So accounts Send and receive transactions which are essentially proposed changes to the state of the chain if they're valid a minor will eventually confirm them to the chain for a fee and At that point they're accepted as valid and stay around for you know To the heat death of the universe the The fees for these transactions are paid in are called gas They're they're paid in aether the Or ETH the default currency on the platform So these contracts All compile down to a simple bytecode that runs on something called the EVM the aetherium virtual machine It's documented in paper. We won't go over it too much in this because most of these things don't actually depend on you knowing all that much about it Because a lot of what they do is actually publish the source code to their contracts, but in ways that are sort of deceptive that More naive attackers don't understand So each instruction Has an associated cost to it. So so this interpreter is turn complete You the the only caveat to that is that every single instruction you run costs you money So if you have something like an infinite loop your transaction will never complete because you don't have enough money for to run for Infinity so that's how they sort of get around the the halting problem stuff So in general most people don't actually directly write aetherium bytecode They use a higher level language and in this case by far the most popular is something called solidity So solidity is statically typed. It's turn complete and it's sort of JavaScript life, but If you try and write certain things like you're using JavaScript and things are gonna break or bad things are gonna happen but What these contracts do is they essentially manage the flow of money so Your goal here is to write more complex things other than just I want to send this money to this other person So you can have it send to five people or write a gambling app that Distributes it to you know people based on some random number generator So every single contract has a constructor that gets run when you deploy it to the chain and that Basically sets up the state of the contract so that constructor after it's been executed when deploying the contract disappears It's not actually stored as the code in the chain but basically runs the setup for Whatever you're trying to deploy the functions in those contracts on the other hand are deployed and by default unless you mark them as limited anyone on the chain can call into these things and when you call into this function It goes off and can modify state in some way so each contract Also has one unnamed function called the fallback function and basically it gets called if the If It doesn't if it's not known what function you were trying to call so if you send something without Specifying what function you want to call or if you call a function that isn't actually there this gets executed a lot of times people just revert in this in this function, but Because you don't really know how much gas it is and it might have been a mistake, but sometimes it will actually do interesting things here so The way that you call functions is you create a transaction, but you also attach some transaction data to it So transactions Transaction data consists of a method ID followed by arguments. So the method ID should is a 32-bit Integer that should uniquely identify a function in the contract and tells Tells the dispatcher where to which function to execute and then you pass along whatever arguments that you are going to use to Call on this thing. So in this example, we're calling approve which Is some function in some contract, but we're attaching Some additional data to it in this case in a theory of madras So this is well documented Constructing data is pretty easy and it's abstracted away through a bunch of different APIs But but if you wanted to code it and you don't have source You might have to work a little bit because you don't actually know what the function signature is So in addition to directly calling contracts contracts can actually call other contracts So this is done through something called message calls, but it's also alternatively referred to as internal transactions but this allows for things like Library contracts, so you deploy it you you want to deploy a certain contract a bunch of times But you don't want to have to pay to store the code more a lot of the code more than once So you deploy a library and then you deploy all these other contracts that refer to the library so You can actually build these nice complex sort of chains where You do one thing in one contract and it updates some other ones that are related, but they're all standalone units It's useful, but it also adds complexity that allows you to sort of hide some interesting stuff And this is just an example of something that's calling back and forth through through an example contract so talked a bit about code, but there's also storage in a theorem which Is the persistent storage area on the network? So contracts need to be able to maintain state between each of the transactions on the network So there is a key value store that basically maps 256 bit integers to 256 bit integers and it Allows you to store data Directly onto the chain and refer to it later So you can keep track of balances manage, you know, whatever There's two other places the contracts can use for data memory and stack These are not persistent, but they are far cheaper use So oftentimes people will try and use those as much as possible if they don't actually need to store it Variables default to using the storage as they're backing. So you have to explicitly declare them otherwise if you want to so There's some common flaws. I definitely recommend looking at my co-workers Paul McCowsky's talk on some of these flaws more in depth, but They're these are the ones that are sort of most relevant to the stock There's unhandled re-entrant control flow Which was used to exploit the Dow contract and stole something like 3.6 million ether but basically what it means is that a Contract calls out to another attacker controlled contract But doesn't appropriately update its state before doing so so the attacker contract can then call back in to the Original contract and execute the same function. So what this allows you to do is say if you don't update the balance of a user Before you do this, you can call back in To the same function over and over and over again and keep withdrawing your money, even though you shouldn't have any at the time Delegate call into vulnerable libraries. So this was used in the parody hack, which basically allowed someone to Call in to a function that people thought couldn't be called in a library that they had That allowed them to re-initialize the library and declare themselves the sole owner of all the funds in this multi signature wallet Which then allowed them to withdraw it to some address There's also a related problem of unprotected critical functions, which came up again in another parody attack Where you could still call this function if you directly talk to the library This allowed someone to actually freeze about a hundred and fifty million dollars worth of cryptocurrency and it's still unrecoverable today And the last one that's relevant is the improper handling of secrets So when you have gambling applications one of the most popular things On the network right now It allows you So so it's sometimes very difficult to get random numbers in there that are actually secure for a gambling app so oftentimes people make the mistake of doing things like storing the secret on the chain and Putting it into a private variable and they think that means that no one can read it But you actually can directly read that off the chain Using some some pretty simple tools. So you can obviously cheat These are some tools for doing all those things. I won't go into them too much But definitely check out the awesome a theory of security stuff. It's sort of links to everything. That's of interest So smart contract honeypots, so the reason this is popular is you've got a ton of bad code And you can send this money that cannot be transferred back. You have no recourse once it's stolen So a lot of people think that's you know free money. So after all these hacks They're with huge dollar amounts lots of people started looking to exploit these contracts so Some enterprising individuals figured out that maybe they could trick these attackers into giving them money When they think that they're gonna get some huge payday. So these honeypots all Without fail require you to send ether into the contract And they look like they're vulnerable to some of these common flaws But they're actually trying to exploit the people exploiting them So I got interested in this because I wrote a smart contract challenge for hack in the box where you it was a classic re-entertcy bug but People weren't actually able To exploit it unless they had a private key that I gave them so so The goal of the challenge was to bypass a withdrawal limit so I put about $50 of ether in each account and people would By default only be able to withdraw three times a very small amount of money like three bucks worth of ether And the goal was to try and withdraw way more than three times So you could use one of these re-enterts this re-enterts the bug to actually get money The the interesting part about it though is that you could only steal The amount of money that was already in your account. You couldn't steal the entire balance of the smart contract Well, just looking at it. That's not obvious and It clearly wasn't obvious to someone else because he went less than an hour later Someone started trying to deposit funds into this and exploit this bug So there's people who are actively looking for these bugs clearly and also not really thoroughly reading the source code to Figure out whether or not it's safe. If I was actually trying to exploit this You know, I basically just had to raise the amount of funds that someone needed to deposit to try and exploit the bug but And you know make it so that they couldn't withdraw any funds. I didn't do that So the guy was successfully able to recover his few cents, but it it just shows how How prevalent this thing is So someone did something very very similar in February currency tycoon Posted on reddit about how he lost some money trying to exploit one of these one of these wallets and the contract was named private bank and was just a simple wallet contract and it had a very very obvious vulnerability so obviously looking at this code the the Contract calls out to an external attacker controlled contract before it actually updates the balances of the user so In theory this should be exploitative and this guy was actually very cautious and took the source code that someone had uploaded to either scan for this contract and Ran it on a testnet and his exploit worked However, when he actually tried to do it in real life His exploit actually failed it looked like it was successful based on some of the debugging information But he never actually got any money and then about so so now He had one ETH in this in this contract and about 20 minutes later someone actually successfully exploited the bug Which was interesting to say the least So what's the problem here? Well, it's internal transactions So the clever thing that this attacker did was when they uploaded the source code to either scan Either scan will actually compile the contract that you upload and make sure that the bytecode exactly matches What is on the chain if that works then they can they will mark it as verified and display that source as the official source Of the contract the problem with this is if you call any external contracts It doesn't actually validate anything other than that the function function signatures that are being called actually match so This particular thing called this transfer log contract and called the add message function in that contract and It actually called into something that was different than what was actually uploaded in the source so You look at the source code and it looks entirely innocent but In reality the closed source contract does something entirely different So it's not logging any messages about a transaction what it is actually trying to do is It will revert any transaction that is made by someone that is not the attacker so the attacker can exploit the bug but No one else can so Afterwards after he saw people submitting stuff in there. He just exploited the bug and stole the money This also means that someone testing with the provided source Will think that it works, but it actually doesn't so a much simpler approach that some people have taken is That still takes advantage of either scan as well is they uploaded some source, but All they did was they hid some code in that source by pushing it off to the side by adding a bunch of white space so This guy just added an owner transfer of the entire balance of the smart contract prior to the execution of sending it to the person who Started the transaction. So that means is the first transfer succeeds. He gets the money and the second one fails and loses his money But an even simpler approach is as noticed by a shit coin Sherpa on Tweet about the best scam he had ever seen a user started going around in various cryptocurrency chat channels asking for support So what he would do is he'd post the private key into these channels? And of course people told him not to do that but would go in but some people would obviously go in and See that his balance had thousands of dollars in Tokens that they could potentially steal So what it lacked was the currency to pay for the gas that was actually necessary to move those tokens So people would send in either and expect to just be able to move it What they didn't know was that there was a script monitoring that account that would immediately transfer out Any currency that was put into into the the account? So it would immediately Create a transaction and transfer all the funds back out of the account to an attacker controlled address that no one knew the What they also didn't know was that the token that he had chosen to put in there actually had a quirk where Just because the balance of the account Showed a lot of money that was available The actual available balance the tokens could be locked. So you were actually able to transfer the funds out of The you actually weren't even able to transfer the tokens even if you won the raise condition Where and beat him to the punch transferring the funds So probably the most technically interesting to me is a crypto roulette where It purports to be a gambling smart contract. So you guess the right number you get you get money The contract had pretty poor secret generation, but even worse it was actually storing the secrets on chain So anyone who looked at this contract would think oh, I can see the secret number. I'll just guess it and I'll make money Well, didn't actually work out that way This trick the the code actually looks very very innocent and like it shouldn't do anything But the trick was is that there was actually an uninitialized structure that you were writing to And by default that writes to storage location zero Well, this guy actually was overriding the secret number on the chain whenever it executed The person would lose and then he would set it to some other sort of random values So you never even knew that that happened and you wouldn't unless you stepped through the contract pretty carefully and the last one I'm going to talk about is the multicator contract and Basically this thing was deployed in late 2017. It was one of the first ones that was out there But the the trick in this contract was that if people didn't know this dot balance was Correct Was updated as Before this function started they wouldn't realize that message dot value the amount that I'm sending in could never actually be greater than this Dot balance on the contract. So You'd send in more money than what was in the contract expecting to get all your money back out and it wouldn't work so It's undeniably satisfying to watch these scammers lose money but You know these demonstrate some serious issues with the ecosystem that should probably be addressed number one there's lots of work to be done with solidity still to make it more intuitive how it behaves and Explorer tools really need to be more careful about how they present data to people because It obviously enables some of these scams But I'm interested to hear to what other people think about that So that's my talk Does anyone have any questions? No, so that's actually dictated by the miners So it's sort of a free market system based on demand Yeah, yeah, so so the miners are the ones who are actually confirming transactions to to this change So it fluctuates based on how many people are issuing transactions Because the way the contract was designed The the the guy was actually able to withdraw his his few pennies from the from the contract But it could have been written slightly differently and he wouldn't have been able to do that at all All right, well, thank you for coming to my talk