Favorite DeFi Vulnerabilities

Transcript

uh cool thanks everyone um first of all I'd like to thank muli John sratora Stanford for uh organizing a great event it's so nice to see so many familiar faces in this room um it's been it's been quite quite a long time my name is Maddie I'm a co-founder and director of Sigma Prime um I'm here to talk to you guys about our favorite D5 related vulnerabilities um quick word about who we are for those of you who don't know us uh we're an information security consultancy spread across the world we're headquartered in Sydney Australia where I'm based we are a collective of security researchers academics developers all working on blockchain Tech we obviously do security

assessments that's why I'm here to a bunch of evm and non-evm smart contract reviews but we're also very comfortable diving deeper into the blockchain stack re-review consensus mechanisms New cryptographic Primitives Network new networking stacks and whatnot as you can imagine lots of layer to work has been happening lately keeping us very busy we're also very very keen on fuzzing stuff coverage guided white box structural fuzzing is something that we really really enjoy and lately we've been doing a bunch of red teaming and social engineering exercises targeting Dows and blockchain institutions that's that's super fun so that's kind of half of what we do and that's the arm of the business that I look after

but we're also known as the maintainers of Lighthouse as Moody was saying so who's here excited about the merge oh okay cool cool who here runs an ethereum validator oh yeah I suspected I expected a few more hands but that's okay um so yeah Lighthouse has been uh is the rust implementation of the ethereum consensus protocol we've been working on this really hard for the past four years the merge is around the corner two and a half weeks super exciting a lot of sweats and tears have gone into this and it is happening despite what many other people could be telling you on Twitter it is definitely happening so it's it's in Rust so it's free it's open source we see this is probably good it's heavily

focused on security and it's uh pretty fast uh I've mentioned obviously that we perform security assessments we're our blockchain agnostic per se but a lot of the work that we do is on on ethereum for a bunch of reasons I put up some of our clients logos I'm sure some of some of them are familiar to you all uh actually there's a few of you guys in the room today so thanks for trusting us with your security assessment requirements um so yeah I reached out to my team and I said hey uh pitch me your favorite D5 Vaughn that you've found over the past couple of years and I've collected a whole bunch of answers unfortunately I'm not too sure how my colleagues deal with this but a lot of our work is under NDA so we can only publish I don't know if I

had to estimate perhaps about 40 of the work that we do so I'll be tiptoeing a lot during this talk pardon me but hopefully some of them are interesting to uh to the audience a type of bug that we have been finding uh unfortunately quite often is related to typos so this is a a fun example um this is from what I think I know is the very first yield farming contract on ethereum this was developed in 2019 for synthetics and synthetics got us to audit it and it's been it's been fun we've done a bunch of work with these guys for those of you who don't know synthetics it's a synthetic asset protocol you basically stake snx the

native token of the protocol and you can mint any asset eth susd s-a-u-d-s Tesla S apple or whatever so they kind of needed a way of incentivizing liquidity providers to maintain those pegs and this is the first iteration of what came on to be this massive defy farming um craziness that we've noticed over the past few years so perhaps I should maybe spend some time on explaining how we perform our reviews all our security assessments for smart contracts are always a two-step process so our clients come to us they give us there at our Target we you know go off and do what we do best come back with a report V1 of the report and then they decide to fix

stuff or not at that point they come back to us with a V2 of their protocol and then we kick off what we call the retesting phase and the retesting phase is there for two reasons and making sure that that fixes are efficient they do indeed mitigate the underlying root cause and B they don't introduce new bugs in this case the protocol gave us an archive it's quite important a zip archive containing the code base in both cases so two zip archives and we basically you know kind of go through the the audit report had you know integer overflows back then we didn't have that protection baked into solidity a couple of re-entrances anyway stuff

that was quite common back then and still coming these days to be honest but um yeah so kind of running through the code line by line making sure that those fixes are effective the do fix the bugs and something I forgot to mention is that we always write our own tests we do not trust our clients tests is a big thing for us we write our own uni test as part of our reviews we typically use brownie even though we've been doubling a lot with Foundry lately kudos to uh Georgios I'm not sure if he's here and the Paradigm Fox for creating such a great testing framework so I go back home go back through the code base my guys had you know performed the retesting everything seemed fine and I run the tests again and now those tests

fail like this is this is strange run them again they fail again three times they keep failing I'm like this is this is us and obviously had to start looking into this very deeply and notice that the client had actually introduced or had shifted a closing bracket effectively changing the order of operations it's extremely easy to spot now right when you have a clean GitHub diff UI but trust me without this it's very very easy to miss and this is the reason why again we write our own tests um these these things happen quite often unfortunately another type of vulnerabilities that my team really enjoying the finding that has been covered I Believe by one of my peers earlier is an initialized implementation contract in the context of proxies so

proxies you've got a proxy contract making delegate calls to an Implement implementation contract the proxy contract typically contains account balances um you know the state storage admin ownership information and a whole bunch of statefulness and the implementation contract is where the developers are actually building the logic of whatever protocol they're responsible for in the context of uh I think someone actually spoke about this earlier so I'll go fairly quickly in a lot of cases people forget to initialize the implementation contract that alone may not be really really bad itself but if you can get the implementation contract to make a delegate call to an attacking contract that you control that would

self-destruct well you get the gist no more implementation contract implementation contract is gone and that can lead to not necessarily loss of funds but as Emilio was uh was saying earlier you know potentially A disruption of the of the protocol so we spotted this in a whole bunch of um of protocols over the past few years and I believe the largest bug Bounty ever given was for typically this type of bug um it was 10 million dollars paid out by Wormhole I believe through immunify um last year or two years ago cool another type of bugs that we like finding in D5 protocols is related to how popular swapping contracts see the tiptoeing here

is deal with internal accounting right so they always have to build their own you know way of calculating rewards and penalties and a lot of them introduce the concepts of shares they deal with shares but they also deal with amounts and if you juggle between the two it's very very easy to get things wrong and we've raised a bunch of critical vulnerabilities related to this another thing related to the internal accounting is rounding errors or dust that can be left into the contract this may not sound too bad but it can actually render the whole protocol useless also if you can manipulate the contract balance of a certain token and the developers are making assumptions on the balance of the token contract you're gonna have a bad

time and safe casting is also a favorite of mine um particularly when you're dealing with negative prices so you have signed integers being casted back to unsigned integers if you don't do this carefully you are going to have a bad time so poor accounting can definitely lead to uh funds being stuck another type of issue is that I thought was quite interesting because I don't think we've covered this a lot over the past few months is related to deployments and specifically deployments that cannot be done atomically right so complex protocols I can actually talk about this one rocketpool who knows rocketpool here who's out of Rocket pool yeah cool cool cool so it's a decentralized liquid staking protocol

for the ethereum beacon chain and it's a fairly complex protocol 26 28 contracts to be deployed hundreds of evm calls to be made for it to be set up properly in a functioning stack State you can there's no way you can fit this into the block gas limit no way you could optimize the hell out of it you can get Transmissions 11 to spend you know his nights on it there's it's not going to happen so you cannot have unfortunately Atomic deployments even if you're using factories and this actually matters in competitive environment back when the beacon chain was launching uh everyone was rushing to be the first liquid staking protocol to attract as many users as much liquidity as possible so

what happens in this case the developers are deploying contracts contract a b c and d and the competitor is attentively watching the mempool and what they're going to be doing is scripting very easily a way to hijack the deploying process or the initialization process actually so you kind of need to link all these contracts together obviously for this the whole thing to to work and the the attacker here is simply deploying a malicious contract and sneaking in the transaction that will link contract C with the malicious contract and it's all automated so it'll be a serious pain for the development team to actually get their protocol out there uh we've been reviewing a lot of smart contract wallets or smart wallets over

the past few years um always fun the standard issue that unfortunately we've been seeing too many times is the classic replay attack right like in this case Bob wants to send Juanita to Alice sends that transaction to the smart contract wallet first obviously you know gets the data blob signs it with his private key submits that to the smart contract wallet and uh you know you're not using a nonce so Alice can simply just use the signature the same data blob send that to Smart contract wallet and keep doing this and draining Bob's Bob's balance more recently

um protocols have been toying with novel cryptographic Primitives to essentially trying to lower the cost of doing multi-seek and BLS is one of The Primitives that has been used lately and BLS is great we actually use this a lot on the ethereum consensus side of things and this is why we can have an ethereum Beacon chain that can support hundreds of thousands millions tens of millions of users and the way it works is thanks to BLS aggregation so I can actually get a collection of messages signed by different parties aggregate those messages into one single message verify the signature the aggregated signature for that message and have the

mathematical insurance that all of those messages have actually been signed properly by the the different value depth so this is this is great however if you are to implement this naively you are most likely going to be vulnerable to this thing called the Rogue public key attack that's been documented by Dan Bonnet and a bunch of other people Dan Bonita b is the bean BLS those of you who don't know and it's really really really clever and it's not actually that hard so the aggregated public key you should just see it as the sum of all the public Keys used to compose the the aggregation so what if I can pick what if I can come in and be part of those messages and I can pick my own public key so that it negates all the other

public keys so that I can have an aggregated public key of zero well fun times because now you have a signature that is effectively pointing to the point at Infinity so you basically can vouch for any message verify any message your contract that's gonna verify the signature is going to verify is going to be okay yeah you're sweet no worries let's go and you basically can take over any wallet that uses this and we found this very recently the report it's not public yet but I'm very very grateful and and hopeful that it will be in the next few weeks so stay tuned uh for hopefully a blog post explaining this um Merkel proves mishandling Miracle proof Sorry probably need no

introductions um but let's just say that they're a way to prove the inclusion of a certain element in a tree um and they're you know used kind of everywhere these days in the blockchain space particularly in ethereum um I'm gonna need you to conceptualize things with me so let's say you have a bridge right a bridge that is uh kind of responsible for linking a side chain and ethereum main chain you have a contract sitting there and that contract is basically representing using a miracle tree to pack transactions so transactions are grouped in Merkel tree and anyone can execute these transactions by providing a proof and a path those two elements are meant to represent a leaf in the tree or

therefore a transaction a valid transaction now the path essentially tells us whether we should be um hashing from right to left or left to right okay so I can give you the proof but I can't like if I don't tell you how to Hash it probably not gonna going to be that useful furthermore in this particular instance the path was actually used to record whether a transaction had already been executed in the past okay so for a transaction to be executed in obviously two conditions you need it to exist and you need it to you know not have been executed so the problem here is that this variable was a bitmap so just like a un256 right and used as a bitmap

I'm sure you can see the problem actually it's written up here if the tree is of left less depth of 256 you can come up with multiple different paths that will effectively point to the same transaction so yeah you basically are vulnerable to replay attacks and you can come up with different ways representing the exact same transaction and because the path is what is used to represent whether a transaction has been spent or not you can you know drain the contract of of its balance uh last but not least um we've been talking a lot about evm stuff about solidity stuff today but D5 does not solely like D5 security is not just about evm security right

um a bunch of examples like people have been talking about Roll-Ups and wbtc and whatnot um there is off-chain components to the whole thing right I said that we love fuzzing stuff and we particularly enjoy fuzzing serialization that's like if you talk to anyone who's Keen into fuzzing it's like the first thing that you'll Target it's like okay cool you you come up with your own modeling system I'm gonna hit that first um and we do obviously coverage guided instrumented structural fuzzing that yields usually great results um and sometimes the bugs we find um are more interesting than what we anticipate I'd like to introduce you all to Skippy peanut butter bug which is cve

2021 3121 which was identified last year by Kirk from my team it targets go go product of Google product is a very popular Library used by a whole bunch of projects including Docker kubernetes a bunch of others so it made for a very interesting disclosure process um 9.8 was a severity given by Metro and Metro were the ones actually calling it Skippy and we called they called it Skippy Because the actual variable at fault is named Skippy anyway little little joke from these guys didn't know they were that funny but yeah um and the cause here is an integer overflow that leads to an index out of bounds that obviously leads to a panic

and in this context you can basically craft one single packet and send it to this value data or relayer in this instance and the node would go down subscribe even better when the peer-to-peer propagation happens before the deserialization so you basically feed one node the packet your malicious packet that node is going to send it to its peer that beer is going to send it to its neighbor and you basically take the entire network down with a single packet Good Times um yeah that's about it really um that's all I had and hopefully you enjoyed this I'll be around for the panel if you have any questions thank you

[Applause]