DAPPCON 2018: Smart Contract Security - Nick Munoz-McDonald (Solidified)

DappCon 2018 · July 2018 · 17:48

Nick Munoz-McDonald of Solidified addresses smart contract security at DappCon 2018, drawing on the auditing platform's work reviewing Ethereum codebases for vulnerabilities. The talk covers common failure patterns in deployed contracts and practices for hardening dapps before they handle real value on mainnet.

Speakers

Topics

From DappCon 2018, hosted by Dappcon Berlin.

Transcript

so like the talk is listed as smart contact security but it's a like a little bit more specific than that we're doing a bug hunting for fun and profit how to find critical vulnerabilities and smart contracts so a little bit intro Who I am I'm Nick munis McDonalds I'm one of the lead auditors it solidified a smart contract audit and bug bounty platform I've audited Dutch X Mellon per protocol polymath platform etc bounty winner forget coin bank caramel important among others and before this like I was a run-of-the-mill software developer in Prague so like I had no specific security experience I just got introduced to bug bounties by a friend of mine who had recently found some success and ran with it so this is definitely something that if you're a

developer if you're a security professional that hasn't done solidity before check it out that's sort of like the gist of this talk really so first off like where do you sit actually does everyone know what a bug bounty program is can you like raise your hand if you know what a bug bounty program is or can you raise your hand if you don't know what it is okay so there's one guy so I'm gonna go ahead so pretty much when projects are ready to deploy their contracts they've already like finished the development they've gone through an audit hopefully and they want to make sure absolutely that there's nothing that they've missed they do something something that's called a bug bounty and so what that is is they post the code

and the documentation and all that and they give rewards if you can find an issue in their code and like depending on the severity and like the impact or how likely it is to happen then they give you like more for criticals and for criticals it can be really really high like right now auger I think has I'll pay you $200,000 if you find a critical in their system right now Mellon port pay you like a hundred thirty thousand or something like that and even gnosis safe has their eye has their contracts on bounty on solidified right now so where do you where do you find these uh reddit number one like that's that's where I started getting into it through

our eighth dev or etherium or just searching bug bounty like on these place and then of course we have like our own bug bounty platform on solidified web done solidified Iowa so I find contracts and there's active contracts there right now including Mellon port and gnosis safe and also there's another project if you heard of it get coin which does those bounties for like github issues and some people have used it for bug bounties even though it's like not exactly suited for it but definitely check it out because there's still people posting there and so like okay first you have all these these my grantee programs you've compiled a list of them but like which one should you

focus on well as a bug hunter we want to make money but we don't want to spend that much time because if you don't find anything in any of these contracts you basically wasted it so what you want to focus on is make sure that there's a reputable team running the project in the first place just that you know that they're if they put a bug bounty up that they're actually gonna pay you this is a plus it does not like a hard and fast rule but if they pay an ether that's significantly better because you know if they paying their token you never know when it's going to get listed or when you can actually convert it into cash for yourself another thing is that if a valid report has already been submitted

and confirmed that's good for two reasons the first is you know that these people like they're not screwing around like they're gonna take whatever your report seriously and also if they found a bug a lot of the times there's gonna be more bugs there if the code base is large and complex I there's probably not gonna be too many people looking at it right now the pool for people who are even trying this is quite small right so if you have like a ten twenty contract system to get people to like spend the time to even read your documentation requires them to be looking for like massive rewards so the larger more complex it is you can pretty much guarantee that you're gonna have

significantly less competition as opposed to like just a one contract that was posted to re that if the project is rushed or under deadline pressure this is a lawful also another way that you can sort of guess that there's gonna be more more issues so if like they have like quite a short bug bounty period and they like need to launch right after it that's something that I would focus on more and also like if his strong auditing firm hasn't been contracted like usually before going to bug bounty these projects would go through an audit first and that's like a way of making sure that you're you caught like all the low-hanging fruit at minimum and hopefully all the criticals and all the majors and whatnot if you go to bug

bounty without an audit you're probably gonna end up spending a lot more money than you would have so once if there hasn't been an auditing firm a strong auditing firm contracted for them then I'll take a look as well because yeah the strongest sodding firms are quite good and it's quite hard to find stuff and the stuff that they audit so it's just a time saver so how do you develop intuition for these dangerous patterns the first thing I would do is I go to these like resources consensus diligence made this like really really good guide for smart contract best practices they have like a examples dangerous patterns what to do instead to make sure that you

don't fall into these traps because there's a lot of developers that are coming from other paradigms from other languages and they're trying to do the same thing develop software in the same way that they were before and there's a lot of let's say gotchas if you if you go about it that way another thing is to solidity Doc's also quite quite high quality it's specifically the security consideration section it's quite small but it's definitely a good way to start and then check out our audits all of our audits are 100% public we just upload them to github and you can read through them and it's essentially just a list of issues that were identified and suggested recommendations out of fix but they're just like it they're basically like a repository of bug reports and all these different projects and it's a

great way to orient yourself there's also these like wargames or capture the flags where these like capture the ether and Zeppelin have created these little games they have toy contracts that have flaws in them and then you can get like you know points on their leaderboard and what not for figuring out like what the flaw wasn't exploiting it and so this is also like a really good way to develop like an intuition for them and then also there's like the the ncc group released like this that's the top ten vulnerabilities and smart contracts and these are just like concepts that once you learn you had a feeling like you can take a look at the code and be like hmm

there's something wrong here like I can almost sure I'm almost sure of it and then from there you can build the vulnerability so let's take a look at my first critical bug it was an early version of get coin it was back in November I believe or maybe earlier and too long didn't read it allowed an attacker to steal the entire balance in one shot and the thing that allowed this was literally just this require statement right here that's the fix I essentially this they had like a contract which would let you post bounties and then once someone completed the task you could claim it but one of the one of the

problems was that when they denominated the bounty and ether they asked you like how much did you basically how much did you give this contract or how much is the bounty worth and because that value was I only had to be greater than or equal to basically you could give the contract you know like one way and then I'd be like oh yeah I actually gave you like ten and I want it back now and you could drain the entire Gator in that way and so it's like a because of improper validation this is this is just something that's like relatively simple I got paid like four eath at the time it was like a thousand two hundred it quickly became a lot more than that

because of the price raised during that time and I made almost my like monthly salary and I was like oh like hold on like what's going on here I need to try this out more but like again extremely simple in in hindsight like developing some our contracts is extremely hard so that makes finding bugs sometimes quite easy so this is like another example of code that I found unto critical vulnerability in it was in melon port I saw this code and I was like immediately this is vulnerable why well first things first they had an emergency in the name

you know it was like you know something something was going on here the other thing is that there is like a lot of loops and in general like written solidity like loops are not something to avoid but it's something that's problematic you can't use them as liberally as you would otherwise for a variety of reasons but a lot of the times just you can't fit all the entire loop in a block and you like ends up being like a denial-of-service vector so there's a lot of state changes to coordinate there is a lot of state changes happening in this that needed to be happen simultaneously with other ones it was just a lot to keep track of and

it was possible that they forgot something and also it allowed you to call like arbitrary contracts so like down here on line 709 the transfer and actually on six eight six as well that balance of this is something that a lot of people forget these standard functions from like the ERC 20 standard the envelope sit the standard is you know standardized but like the implementations don't necessarily adhere to the standard so like this for me for me to like it I could just give this contract like the address of of a contract that implements balance of or

implements transfer but instead of actually transferring or checking the balance it reenters the contract or call something else anything really it's just allowed arbitrary card it allowed arbitrary code execution and so this was actually an issue is this sort of at least one critical issue and I think one major and maybe minor like once I once I reported this in their bug bounty program they like hired me to audit it and there was like even more stuff and the issue was essentially this is supposed to be decentralized hedge fund management and that means that you were they want to give people the ability to invest in this fund without the fit without the fund manager being able to steal all of the stuff all of your

assets but there could have but to mitigate the potential of like one of the assets that was being invested in being compromised they had this emergency redeem function which would let you take out like a share a proportional share of the underlying assets of the fund so if I had 10% of the fund if I invested 10% of the into the fund then I was entitled to one-tenth of the assets but the thing was with this function they didn't check whether or not you were passing them the same asset at once so you could just take your 10% and ask for asset a ten times and now you have all of asset a so there's in bug hunting it's like a bug

bounty specifically there's ways to figure out like what you should be focusing on because you're being compensated not for checking the entire code not for saying that this code is secure your compensator for finding issues preferably critical issues so these are like ways of figuring out like okay they might have made a mistake here check out the closed issues on their repo if there was like bugs that were they found internally and they reported it in there I get hub repo check out the closed issue and check out what their fix was maybe they didn't fix it correctly or maybe there's like a deeper issue at hand that they just try to paper over read the comments like often teams will know that some code is against the best practice they'll have

like a specific reason for using send instead of transfer for example and they'll write that they'll write in the comment like we use it because of this and whatnot but they still like mess up the mitigation and the vulnerability is still there check out their tests like a really good way of finding out is if they you have like almost no tests for like edge case scenarios like a lot of times people write tests to make sure that their code does what it's supposed to do but not what that it doesn't do what it's not supposed to do read their audit report did a lot of the times with audit reports when they check the fixes it's not necessarily as diligent as the first time that they audited the code so some of the fixes could still have some issues there and

actually the this one had been audited by I think two other firms but by the time I found the the bug in their bug bounty and it took me like an hour so like there's always there's always the possibility that there's something there and actually the last if I remember correctly the last audit report that they had done warned them that looping through the assets this way was potentially dangerous but they didn't actually enumerate this particular vulnerability so like that was another way that I could like it was much easier to find and then use analysis tools like methanol I know ant a I a lot of the times these tools have like especially I Manta has like really high false positive rate so you have to actually go through the report like go through what

reports and just use it as a basis you can't just take whatever the tool outputs and dump it into an audit into a bug report you need to like actually go through it constructive won't like an actual attack describe the attack and like its actual impact when you're making a report so this is just a way it'd be like okay this could be dangerous now I'm gonna try to build a vulnerability on top o bold like build an attack on top of it so key takeaways for potential bug hunters try it out try this out we don't have enough people and participating in these bug bounty programs the rewards are quite high and like even if you don't find anything

you'll still become like a stronger solidity developer with this knowledge read every audit report and bug report that you can get your hands on all of solidifies reports are public and a lot of other entities or a lot of other auditing firms are doing the same for at least some of theirs so definitely check them out read their reports check out the code this is how you develop the intuition and you're compensated for mistakes but not for ensuring that contracts are secure so use that to prioritize where and how long you work on a bounty so like there's no way right now for you to get any money out of like hand find anything and I'm pretty sure this is secure so don't go for that you're just trying to find critical issues it's kind of like you know in and out trot

like go go for the things that look insecure probe them and if you don't find anything move on to the next one and this is for max is like like ideally the system doesn't work like this but this is the reality and this is where the incentives are and for those running bug bounties like large code bases require huge rewards to get bug hunters to even attempt to the like croc your system to even read the documentation for something like the melon port protocol is like actually quite an undertaking so you need to offer like really really high rewards for people to go through all of your stuff be transparent fair and responsive to reports I mean this is pretty obvious just make sure that like people that are

reporting things feel that you they were or they were heard and they were fairly heard and whatnot and bug hunters are trying to maximize their payout over the time spend not ensure that the contracts are secure or compliant to a given standard so like when there's issues when there's issues that you you think are going to be problematic but you don't think that you'll get rewarded for reporting them a lot of times people just won't even spend the time like I wouldn't I wouldn't waste my time reporting like a something like a not being not compliant with the ERC 20 standard if I don't think that they're going to give me a bounty for it and provide as much documentation as possible commented code is not enough and this is something that we're working

on for the future it's a little fighter working on a bug prediction market it's like a new way to incentivize crowdsource security assurances and bug hunting is a way if you open up prediction markets on whether or not a security vulnerability will be discovered by a certain date then you can get you open up a way for people to profit off of making making sure that code is bug free by buying these tokens that would get like well rewarded that will reward you if there is no bugs found so you can actually make sure that people will spend the time because they'll be rewarded either way all right and I think I can open up to questions