Billion Dollar Bugs (and How Watchdog Found Them)

Transcript

hello uh I'm Neville so I'm actually an academic researcher by training um most of my academic life was devoted to program analysis and but over the last couple of years I've co-founded ddub together with another researcher Janice Mark Douglas he'll be talking on Thursday as well about of some of these Salient features and techniques that we have developed for symbolic computation and the premise of my talk is rather straightforward over the past year or so we've been able to disclose large vulnerabilities and get large bug bounties for in projects that are pretty

big now how did we do it is one of the things that I'll start to answer but if you want to learn more you gotta you know look into some of the academic research and things like that but since our approach is scientific in nature and by being by just by being virtue of being scientific it doesn't mean that it's better but it means that it's repeatable and so we were able to package it into a product called Watchdog which D5 teams can now Avail of okay so these are some of the clients we work with for most of the people here we're known as smart contract Auditors okay so we work with a lot of these

large projects however since 2019 we've developed tooling free tooling for the security Community including a decompilation framework contractlibrary.com which I'll demo right now okay so you go to library.dw.com and you will find all the smart contracts that have been deployed on multiple chains um now we have ethereum but we're going to have Phantom in a couple of weeks or so and okay so you can you know sort by hottest but also by the very latest contract that's been deployed and then

you can click on one of these and view a decompiled representation of the Smart Connect so whether or not source code has been deployed you can understand what the smart contract does and it's very useful when there's a hack and someone reverse Engineers what the hacker has done and so this is the place to be whenever there's a security incident okay all right the other thing we can do is we can see transactions that have been uh the smart corner has been involved in and you can also trace and debug these transactions now there are multiple transaction debuggers out there tenderly etx.info this one is a hundred times

faster than etx.info especially on large transactions you know so when you've got a transaction debugger that barfs contract library is the place to go and debug that transaction Okay so so you will hear a bunch of talks or you know products saying that if you had applied this monitoring solution then some Pro some hack would not have uh been done it would have been prevented but the proof of the pudding is actually finding and Reporting the hack before

it's done and actually getting um recognition for it right so and so we've managed to do that with a tool called Watchdog all right so and now that's going to be deployed for all projects on Phantom which have a strategic uh importance to the ecosystem so any project which has more than 10 million in tvl you will get Watchdog for free and Phantom is going to pay the bill okay so that's very very good for that community and soon you're going to be able to Avail of this tool if you like end of the year if you have a project on ethereum on or on

the other chains okay so some of these vulnerability disclosures so Harvest Finance was one of them primitive Finance the precursor to for a combo it didn't have any sources defy saver um Vesper BT Finance the biggest one of these was multi-chain so nine bug bounties three million in total since 2021 what's the methods that we used Okay so we've built many different tools among these is a blockchain Explorer which is specifically designed and indexed for

the kinds of queries you need to do as a security researcher okay so it's not good at doing dashboards and things like that but it's very good at finding neither in a haystack sort of very weird past executions and in the blockchain the good thing about the blockchain is that not only are they all the smart contracts available there to be decompiled and analyzed but also all the past executions of all the smart contracts are there for people to just debug and dynamically analyze and this is unique because you know if you had to do a similar thing in other Industries let's say for instance

um for the App Store or for Google Play then you know you cannot do this now Google for instance has access to the to all the apps but the regular um you know organization would not right okay now the other thing is that we model all possible executions of a smart contract and this is the hard part okay we use a technique called Static program analysis and that's you know almost impossible to do in general but you know we we try our best okay now so then you combine these two techniques together okay so the you

know blockchain Explorer Dynamic analysis and static analysis we try to find contracts that control a large amount of funds but are also critically vulnerable and when you when you get that intersection it's a very very small set okay all right so all possible executions one of the techniques we use to model sorry okay so one of the techniques we use is declarative program analysis okay now with declarative program analysis means is that we turn our programs into relations we turn them into something

similar to a SQL database and then say for instance over here we have a program in a representation Which is higher level than bytecode but much lower level than source code we achieved that representation by decompiling or binary lifting that okay the reason why we use that representation is that we want to also model assembly okay so assembly is very similar to bytecode and we also want this to apply to all versions of solidity Viper and everything else and the other reason is that sometimes we don't have the source code okay so combining all these reasons together

makes sense to use bytecode we turn that representation into facts so say for instance here we've got a loop we find out for instance the induction variables that's the loop counters or we find the exit conditions okay and we'll represent these as almost database tables but on a database which is not this based it's memory based so and it's also performs query plans which are very good for complexly recursive queries which we need to be doing to understand these smart contracts the executions data flow analysis things like that okay

Okay so I think I uploaded the wrong version of my slides anyway so okay so let me skip to this so what did did we learn out of this experience okay so we found these major vulnerabilities um clearly it's very hard to write code in solidity so here's a collection an unstructured collection of some of the gotchas in this language all right and gotchas also in the way that you write D5 applications so the very first one okay what is the difference between

this dot Foo and Foo so for whoever's in this room okay so we're in the age range of learning our first programming language that we learned was probably Java or C plus plus okay now for some people maybe you've learned algol 68 or Fortran but I mean in my case Pascal was the first one right right so we've been taught right uh that this dot Foo and Foo are exactly the same thing but what's the difference in solidity well in solidity one is a an internal call and one is an

external call which means that message sender changes now in the context that we saw this code in by changing message sender we could do nasty things because the smart contract that had this code um allowed any calls from itself to do administrative things Okay so we found that issue of course a lot of people here know this especially if solidity if you understand solidity very well okay so it's pretty obvious but you know it can still get you

okay so here's the second one okay so this is the reason why we got we found one of the largest vulnerabilities to date which was in The multi-chain Bridge Okay so here's a snippet of code from multi-chain okay so there was the smart contract it had two functions one which which is deposit and the other one is just deposit with permit okay so most time most um people would use the first function right so they approve the smart contract okay so they approve An erc20 approved for the smart contract to pull

their funds and then they call deposit and this deposit function the very first one over here it does a safe transfer from it's the correct way to be pulling funds from a user's wallet okay so nothing wrong with that but it had another way to actually pull funds out of a smart out of a user so and this used permit so if you haven't seen permit before it's a way to offline a signature okay so that you can offline the approval using ecdsa encryption so you pass that signature

and then the permit verifies the signature and implements the approval so then in the next line this transfer from will succeed okay now can you think of the way that permit is implemented in one of the most popular tokens which is with okay how is permit implemented in a token wet wrapped it think about that that's it

so I bet this is not what he expected all right so rap deed does not have a specific implementation of permit but it has a fallback function Okay so wrapped it sorry permit does not return anything okay it doesn't return a Boolean doesn't return an integer or anything also this fallback function it doesn't add anything to memory to return data and anything like that so it observes the so it's like it's it's compatible with the ABI of permit okay so permit is a no-op in wrapped eat okay so going back

to my so now the we call this a phantom function okay so rap deed has a phantom permit so going back to my previous example here most people would be using the part on the top and so there were over 10 000 approvals to the smart contract but in the bottom part so there was already the approvals but someone could call the bottom deposit with permit and deposit someone else's funds into the smart contract okay because permit will succeed

and then from that they could Bridge or steal the funds of anyone who had ever approved multi-j okay so it's a very serious vulnerability luckily it funds were you know recovered there were some large accounts that revoked their approvals but still there was you know 3 million damage but it was much less than the 1 billion in approvals that there were at that point okay so here's another vulnerability pattern now this luckily we don't see this much anymore but this is something that was in primitive finance and also similarly in some

earlier versions of furry combo and also defy saver and this relates to flash loan callbacks okay so the way you implement flash loan callbacks there's many check boxes that you need to tick okay so in a Flash loan callback a are they for instance or uniswap will call you back after it transfers some funds okay now what the developer did here is that they checked okay that whoever is calling the smart contract is actually a valid pair of uniswap okay however

anyone can actually initiate a flash loan and use the smart contract as a fallback and they can pass a payload here data of their liking now in this case data here was used to perform a swap and to transfer some tokens from users okay so a carefully crafted message and initiating a flash loan would have enabled draining all the funds in this protocol but also all the approvals in this case okay so actually recently I mean recently like

more like a year ago um the the apis of flash loan callbacks were standardized and nowadays all API flashlight API callbacks have the initiator of a flash loan okay so you need to check the initiator of The Flash flow okay so now after we've seen some of these anti-patterns and some of these lessons of how to write bad code let's look into how to write good code okay so I'm gonna go through this very quickly I'm not gonna say how to write secure code because a lot of other speakers here will talk about that but how to

write well auditable code instead okay so one thing that developers need to understand is that not all audits are equal and in fact an audit does not stop when you achieve a complete um not not understand but complete confidence of a project but it stops when the budgeted time ends so how do you make most out of that time okay so there's many things which are obvious you know like documentation testing comments in the code okay informative names so most good projects do this

however there's other things which can make a big difference and these are invariants okay now invariance can take multiple forms and I'm not talking here about formal invariance but in variance written in in source as comments they can be temporal in nature things like you know in order to reach this part of the code okay that there were these conditions that were checked by whoever called it okay things like that another is functional okay so for instance the scale of an amount in a token

and the other one is structural for instance that strategies need to implement some particular function if they do some particular thing okay Okay so now let me skip to here now the other thing about an audit is that it only confirms the security at a particular snapshot in time and the protocols that you depend on they change a lot Okay so what are you going to do about it well you can have multiple engagements but it's very expensive but another way to go about it is to have technology driven

continuous audit service and monitoring okay so that can help some of the medium level projects which cannot afford you know continuous audits continuous manual audits Okay so that concludes my presentation do you have any questions panel all right thank you [Applause]