The 10 Most Common Vulnerabilities Found in Audit Contests by Jack Sanford | Devcon SEA

[Music] [Music] hey everybody great to see you all here thanks for coming out I'm Jack Sanford I'm the CEO and co-founder of Sherlock Sherlock is one of the largest audit contest providers in the space and today we're going to talk a little bit about the most common bugs found in audit contests so if you're a protocol developer or if you want to become a protocol developer one day you are going to be ahead of 90% of other protocol developers just by being aware of these 10 common bugs so just a quick intro on audit contest and why you should care um audit contests have become and are becoming one of the most popular ways to secure smart contract code before deploying a protocol to mainnet uh there's been 625 audit contests run uh the most have happened this year of any years so it's really taking off 36,000 vulnerabilities found 36 million in prizes have been paid out to thousands tens of thousands of Security Experts people who are learning to be Security Experts all from finding bugs in these audit contests and as you can see the biggest teams in the space are using audit contests all of these teams have done an audit contest this year in order to secure their code so what is an audit contest essentially the goal is to find bugs and code usually critical bugs bugs that are going to cause losses for users on mainnet you start with a pot of money you say hey here's 100K or in some cases here's a million dollars and we're going to pay people based on the bugs that they find and anybody can participate so it's a really great way to onboard to crypto really great way to onboard to web 3 security participating in audit contests and depending on the severity of the bugs you find so if they're critical severity you're going to get paid more for them if they're super unique and other people don't find them you're going to get paid more for that and if you find you know three of the four bugs that are in that protocol during that audit contest you're going to get paid a lot of money for that so really cool thing and we're going to rip through super quickly the top 10 vulnerabilities that are found in audit contest these days so number one first depositor inflation attack in ERC 4626 volts this is a super famous attack really annoying because anytime you deploy a new Vault um on a blockchain you're essentially uh exposed to this attack um because the person who puts in the first deposit can essentially put in such a tiny deposit that it causes sort of a rounding issue and then all the deposits after that are a little bit messed up and the first depositor can steal funds that way and kind of Dos the The Vault second one using transfer instead of safe transfer so just using the transfer function in solidity doesn't actually check the success or failure of a transfer and it can also allow for really bad things like re-entrancy with non-standard tokens such as usdt number three missing validation and admin checks so let's say you only want the owner of a contract to call a function or someone on a white list to call a function a lot of times there's so many functions you just forget you just forget one essentially or you forget to check for something that you meant to check for and that's what Auditors are here for and they're really good at finding that stuff um so this happens more often than youd think okay missing check for active L2 sequencer so essentially if you are deploying a protocol on top of an L2 like arbitrum or optimism um sometimes the sequencer goes down not very often but it could happen in the future and it could happen for long periods of time and if you're a derivatives protocol or something where real-time information is super important malicious actors can take advantage of stale prices because of the sequencer being down number five the classic re-entrancy very first major vulnerability ever in ethereum the Dow hack um basically there are certain functions where essentially you can continue the execution outside of the function and call that very same function again and this can cause all kinds of problems there's a bunch of different like surface area for what these um vulnerabilities can do but I'm sure a lot of you have heard of re-entrance C already Beyond transfer rebasing tokens so if you want your protocol to be able to handle any token out there um or even a pretty General set of tokens a lot of them are non-standard a lot of them don't conform to you know things that you would think that they conform to and so smart contracts can get completely dosed or or um funds can be lost because of these tokens um having non-standard behavior with your functions so rounding Precision loss issues this one has become really famous in the last 12 months even if something is off by a couple of way or you know to the 18th 17th decimal place you can have major issues because of the way that solidity essentially or the evm essentially doesn't have floating Point arithmetic so it truncates things it it rounds things a little bit and that can cause a lot of issues um hit in the last three really quickly here using spot price uh instead of t-w and Unis swap so this is something that I think we've all seen price manip ation attacks where someone um basically inflates the value of a certain currency in a Unis swap pool for even one block and then does some attack using a flash loan and then it goes back down so that one is really common uh less common these days thankfully incorrect implementation of upgradeability so essentially you want you want your contracts to be able to be upgraded and it turns out you hardcoded something in an initializer you hardcoded something in the Constructor and you can't actually upgrade your contracts and you only find that out later so that's kind of annoying but not too big of a deal unless it's uh unless the initial deployment of your contracts is super critical last one no slippage check in custom vaults and pools so ERC ERC 4626 is great use you know standards whenever you can uh when you're developing in solidity um because if you have non-standard pools you can actually have um your user sign up to get a trade done at one price and then at the very next block or the very next execution um that price is completely different and it can be off by a massive amount of percentage points so your users can get really into trouble if you don't have slippage checks on your functions there so that's the whole talk if you're looking to become a protocol developer check on these 10 things before you send your protocol to Audits and you'll be ahead of 90% of the other developers out there thank you Jack I see a question over there um when when would you do an audit contest would it be like after you've done an audit or before you do your first audit like or instead of a regular audit what what's the goal there yeah it's a great question if you can do multiple audits I would normally say do the audit contest last because you get 300 people it's a little bit um there's there's more operational um complexity with it because you have to deal with 300 people you know Sherlock and others will D duplicate the issues for you um so if you can do a traditional audit or two before that that's even better because you get to have kind of consultation with somebody and really fix a lot of the things early on and then when you're like hey I think this thing's ready to go to mainnet do an audit contest and you'll find all the other stuff essentially that's the goal hi um are there any standard protocols or platforms for holding these contests that you can recommend yeah so I'm the CEO co-founder of Sherlock Sherlock is one of the the main ones so I'm obviously very biased um but there's Sherlock there's Cod Arina there is immuni does them as well now there's a platform called Cantina Cod Hawks hats so there's a few platforms out there thank you any other questions oh we have one here thank you a is very expensive so what is uh your suggestion for small uh dab with the very tight boxes thank you yeah um if you're if you have a tight budget uh I would say just try to keep your contracts as simple as possible every line of code is going to cost you money uh when it comes to the auditing phase and you really want to pay per line of code like essentially you need to pay for the best people because those are the people who know how to hack contracts and those people exist on the black hat side like the bad guys so you need to make sure you're paying for the best good guys as well to ensure that you find those vulnerabilities before you go to mainnet so if you're kind of bootstrapping just try to keep your code as small as possible as simple as possible use other code that's already been audited if possible um and when you actually do do an audit don't go for the cheapest provider because you really want to get that top talent even if you have a small code base