How to understand a hack

Transcript

I'm ready hello I'm Daniel Von fange uh some of you may know me from Twitter where I posted a lot of breakdowns of hacks and it's something I've been doing uh often for the last two and a half years um so I got here early and I went I was wandering around town and I ran across a huge military display for national day with tanks and apcs and they were letting like five-year-old kids run the gun turrets on the stuff and piles of helicopters on the grass that all took off and flew over the city but that made me think of World War II and in World War II uh the Americans lost tens of thousands of aircraft but they also

didn't lose tens of thousands of aircraft and they just got holes in them and so whenever all over the world American airplanes got holes in them uh as part of the maintenance report they would fill out forms about where the hole was and send it home and it would go to Washington and get tabulated and so they had a professor look at this list of holes that were in the airplanes and try to figure out what they needed to do to change the airplanes you know kind of a system for finding out how to improve the airplane so they got shot down less by looking at the holes that were in the airplane um now there's one really interesting thing that's slightly makes total sense once you understand it but is a little unintuitive at first is that a hole in an airplane that got back to base is a

hole that did not shoot the airplane down and so what you actually needed to do is instead of thinking hey there's a whole bunch of holes here in airplanes that are coming back I need to put more armor there is these are the places that it's fine to get holes and you're okay and it's the places that never come back with holes are the places you need either more armor or more redundancy and so a lot of times people learn uh defending a smart contract by looking at audit reports and to some extent audit reports are like those holes in the airplanes those are the ones that got caught and so the big thing is what are the attacks that did not get caught I'm good I don't show anything yet um they're the ones that did not get caught

um and so what you want to or one really powerful way to learn about the ones that get through all the processes and the tools and the test is to study the actual hacks that happen there's a second uh really kind of powerful thing I'm a bit of a nerd so one day I took a spreadsheet I made a list of every natural disaster or like personal disaster I could think of and I ranked it by How likely it was to happen and how much I needed to do to prepare it prepare for it and how much I can mitigate it because I'm a nerd and so I got to tornadoes and I tried to figure out how likely I was to get hit by a tornado and so I went through lots of weather data and I analyzed the tornadoes in my area and while I was doing this I was hit by

a somewhat completely unrelated realization which is in my area somebody within a mile or two of myself is 600 times more likely to get hit by a tornado than I am just because there's lots of people around me and any random tornado going through my area probably isn't going to hit me it's going to hit somebody else first or hit somebody else and so when you're working with uh if you really want to defend a protocol or really want to stay on The Cutting Edge of hacks the odds are somebody else is going to get hit before you are so it really comes down to learning from these new things that come out and that's another area where learning from hacks is really useful so what we're going to do today is actually break down we're going to take uh it's not my favorite hack of all

time but it kind of has the funniest Story the Platypus hack which the hacker was actually counter hacked afterwards because they did such oh and they also locked up all their funds afterwards and then we're counter hacked so we're going to get back to that in just a second and actually break down uh how to do this so as an auditor or as a protocol your end goal is to understand the vulnerable code that made the hack because if you're an auditor that's what you want to be able to look for in future Auditors and if you're a protocol that's what you want to make sure you don't have and don't write in the future but so how do you get there from just having like a transaction hash or something there's four or five different ways you could potentially dig in to find what actually happens so

there's the funds flow of funds and this shows up on etherscan there's the events that are emitted during the transaction you could decompile the attacker's contract and work through that you could go spend time reading the victim contract and understand how that all works or you can work off the execution trace and actually working off the execution Trace is massively better than every single one of those other ones because once you understand what happens it's usually pretty obvious where in the victim code you need to look to find where the bug is um so I am going to give this a shot now and try uh showing you how to work through a hack let's see how this goes

there's very bad or no Wi-fi here so I'm going to be uh I'm going to try this out if anything goes wrong I have some backup screenshots I'll use uh so kind of step one of uh working through a hack is you got to have a transaction Trace but I would always start with a notepad document uh just or you know some kind of text document that you can put links to you can when you dig up what a contract is you can put its address and then what it is and kind of your understanding as you go through it it oftentimes you get part of the way through and you realize you need to go back and look something else up and if you've got it written down it's really simple process otherwise it's really

aggravating all right so the first step is get the transaction hash uh this is uh sometimes it'll just be posted by PEC Shield sometimes you'll have to go look at the contract and look at the transactions that interacted with it but once you have the transaction hash my favorite tool is samsi sunstool openchain.xyz there's also Falcon by Block Set team these are probably the top two transaction tracing tools right now um and so I'm just going to demo with Sam's tool here and kind of what you want to find out is kind of get the lay of land on the contracts is one of the first things you want to do for a hack and so for this particular or for any hack this tool will show you kind of how the value

changed uh between these different addresses over the course of the transaction and so in this case this address right here ended up with uh 40 million dollars more than it started out with and we can also see that that's the initial contract that was called the attacker named it hello all right and that's going to be our attacker contract most hacks happen from a contract and so uh that's our attacker contract now what you can do with this tool is you can actually rename this thing oh hey I've got Wi-Fi that's a good start um let's try again and now through the rest of this uh call

Trace whenever the attacker does something uh it gets it shows what it is now a if I expand this thing out enough this thing will get absolutely huge once we look through or you know even if I were to expand out these things small things so one big powerful thing you can do when understanding a hack is focus in uh attackers tend attacks almost always follow kind of the same patterns first they set up get a bunch of money from a flash loan then usually they put the contract in a bad State then they exploit that bad State and then they swap out funds repay the flash loan do a whole bunch of other work and so you can uh usually just skip down in through like a flash loan happening and

execution you know in this one I think there may have been two flash loans that happened um but anyway at the end of the day it gets back into the attacker's execution so we're going to skip that first part and if we look down at the bottom of this a lot of the stuff that's happening back here like handle repayment and stuff is uh also the flash loan so in here we kind of have to go through and figure out what happened and what went weird and uh we also kind of need to find out what these names are of these different contracts we can see that things are happening in here um but are you guys able to see the screen enough I can assume yeah not

really it's pretty bad it's pretty rough so here I see a deposit happening and that's kind of a an important thing that's going on so I can expand that out uh and let's see it's no that's I spam aroma I can see that it's happening on a contract named pool um and so I'm just gonna to make this the rest of this easy and save you guys time I looked up that contract on etherscan and I know it's the uh it's their uh pool contract uh so I'll just call it pool um and then if I go down to the next thing

that's important a deposit happens um okay it's the master platypus before this is just I'm putting the names of the contracts onto their proxies my finger is uh sticky because it's warm in here um so if we kind of ignore all the other stuff that's going on here what we have is we have a deposit the funds from this pool are actually

deposited into the master pool and then from the master pool we do an emergency a uh emergency withdrawal um and then a regular withdrawal what uh sorry because I'm running low on time I won't actually break down through that but uh where it goes weird here is this emergency withdrawal and emergency withdrawals are often where strange things happen so what you do when you have uh or once I've identified that emergency withdrawal as where all of a sudden after all this the attacker has doubled the money is I go in and look at the actual code for emergency withdrawal I'm going to bring this over here it's an emergency withdrawal now let's

see all right here's here's emergency withdrawal um and again for time reasons because almost that time I'm going to skip actually how it worked out through this but what's happening in here is uh they check that the user is solvent and then allow them to pull their money but this does not take into account if the user has borrowed any funds and so this is like the equivalent of going to your bank depositing a million dollars asking to borrow nine hundred thousand dollars and

then saying hey I need to withdraw my million dollars and they say well you have a million dollars and your solvent and your account's in good standing here's your money and so they basically doubled their money uh in doing this so that's kind of how you get down to where the bug actually happened questions all right open yes good thanks for the talk are there any online resources where we can go through this in more detail what you just showed here uh I don't know that anybody's other than myself has really explained it I

guess you just give it a shot and try it you know you can uh a lot of times people will say on Twitter where the bug happened and so you can kind of work your way you know simulate your own run knowing where it's going to be and work your way to understanding it that way golden thank you you're welcome you know one really useful thing is to always actually get your eyes on the bug in the code uh because a lot of times things won't actually work out exactly how you thought they did and sometimes descriptions of how hacks worked on Twitter actually don't match how they exactly Act could you talk a bit more about the hack to hacker part a few mentioned is that you think it's more common or is that just a lazy attacker Trend uh so yeah this is a great story and uh so this

attack happened and they put no way in the immutable attack contract to withdraw the funds so all of this money is locked forever in this contract um however block SEC team looked at this and realized that the attacker made a mistake in that attack sequence the attacker made a flash alone or he got a flash loan The Flash loan called back into the contract uh with some funds and then the attack contract started executing it basically took the funds that it received and it put it all into the protocol to you know do all the stuff so there was no authentication on that flash loan calling or uh that call that the flash loan made coming back in

and so what they did is they upgraded the Platypus contracts they then called The Flash loan thing but gave it no money and so it took all the money that it had and went back to deposit and run through that exact sequence that was coded into it but because they had changed the protocol code the protocol code just took the money and ran at the end of the day instead of giving them anything back and so they got back all their usdc that was hacked out and then the attacker had used an account it was linked with his name on another thing you could go see all his scores in first person shooter games and he was arrested actually he was two guys arrested in Paris uh very shortly thereafter so it

is the single worst attacker of all attackers of all defy attack history was this particular hack um one thing I find interesting is that 99 of the time decode is public so it's supposed to also be on the user to double check what they are using before using it this usually doesn't happen because users are under the false assumption that if it's public someone else have checked it and with them a great effort put by the space into the UE user experience

and in general the front end it's really easy for the user to do even very complex things okay so do you think this is solvable at this point like the users not checking what they are using and so I've got yeah two things on you as far as will a user be able to know if any general contract is secure absolutely not uh you know somebody just makes some code and throws it out there however I think uh there's some standards coming from Auditors where the Auditors can actually vouch not only that they audited the contracts but that the contracts that you're actually using are the ones the Auditors audited

instead of just uh you know they got an audit and they changed the code later um and so you know I think in the future it will be easy to tell for big name protocols that someone has actually vouched for the code that's actually running uh it'll be better than it is today but for the anybody no there'll be there's nothing that you know even as a protocol you can't be sure that you've got the code right so much less a user all right I'll catch you all right thank you [Applause]