Top Hacks since ETHCC 2024

Transcript

[Music] Okay, welcome everyone to the presentation about top hacks since we met last time in Brussels. Um, I am Matias. I'm still waiting for Julian from Rect to uh to appear. So, I'll give you a quick intro so when he comes that you know already who he is. Um and um you might know him, right? He's the founder of Regg News. And this is also where we got all the information from and of course many different sources um about about all of these hacks which happened since

um ECC 2024. So July 2024. And um uh who who isn't isn't familiar with Rec news in here? like who hasn't heard about it? I think it's okay. So, I don't need to say what it is. Um, quick words about myself. So, I'm Matias. I'm the co-founder and CTO at Chain Security and we are um audit company. Uh, we we did we are like more than seven years old and uh really audited a lot of systems out there. We like to do a lot of research, right? and and usually we are

employed inside the Ethereum ecosystem for complex D5 systems. So now let's start. We we really had sadly once again an interesting year in hacks. I don't go by order. I'll go over the top 10 hacks but not in order. We'll start with Vazerax. Vazerx was um a compromised uh multisig um a safe wallet and um the the attackers managed here to trick signers into approving a transfer of the vault uh eventually right so um

this attack started with uh the attackers actually triggering vazier X to go to the cold wallets to transfer funds out. Um they did that by buying Gala and like um exhausting the hot wallet. And so then uh Vazerax went and did a routine transfer. Um they were also protected by Liinal a service which uh co-signed on their um transactions. But now the signers weren't able to actually um trigger that transaction. It failed, right? But but they actually were able to to sign a valid transfer. It was just

not the one they expected. So after three signers signed that transfer, Liinal also co-signed on it. And now this transfer uh this transaction was actually a transfer of the vault ownership to the attackers who at that point um of course had full access to all of these funds. Um there are a few things to learn from this. So we had a very large code wallet holding significant amount of funds and this allowed an attacker to trick people to sign one transaction

to exploit a lot, right? And um it is normal like whoever like I mean sadly you all know that signing a transaction often fails. It's just kind of the expected behavior by now that there are random errors here and there and then you just retry, right? Um and then of course if you build in third party systems and you think they protect you and you don't need to think for yourself anymore but you don't really know what they are actually doing that they in this case just say like yeah sure we had three signatures so we are cosign um means um you might be in a false sense of security

and my major takeaway here was that we should aim for this level which I kind of call three star security. You try that there are no single points of failure. That is step one. And then you try that there are not even points of failure where if two systems fail, you fail. Right? This is for obviously for very large funds. It's very important. So that an attacker on all levels need to at least figure out a way how to manipulate two systems but ideally three systems before they get

those funds. Um a list of the possible things you need to think about are like uh is a single person signing. I mean obviously right is there um just a single communication channel which says please transfer those funds and then blindly a lot of people follow it. Is there a single UI? Is there a single HSM? Is there a single laptop or a single brand of laptop? And so on it goes on and on. Um it is just attackers will look for the weakest link and they'll probe and if the weakest link is just one thing they need to compromise then of course that

is an obvious target for them. Um the other takeaway here if you sign off on systems which do hold significant amount of funds anything which isn't as you expected needs to be like treated very carefully right that you don't ignore errors which you saw just to move on but again I know this is easier said than We are skipping over a similar type of attack which uh a crypto well was tricked into

signing over access to their DS proxy also with a malicious signature. In this case, we have very little information what's actually happened. And for all the hacks I'm going to present today, I just focus on those where we actually can learn because a projects did a lot of um disclosure forensics and published those results. But this is a similar hack. We come to another similar hack, Radiant Capital. Radiant Capital was hacked by um again malicious signing from three out of the 11 signatures and it was again a safe contract. It was in October

2024 and um the attackers in the end were able to run away with 53 million uh across many different chains. Um and what uh the forensic results showed were that the laptops from the people who signed here were compromised. Um now if you have 11 signers then it is often the case that those people sign from dual use laptops. Laptops they also use in their work. It's a broad set, right?

It gives you more resilience um in in like being able to react to things. It's easier to reach three out of 11 than three out of four. But of course, it's also harder to keep all of these 11 in a state where their obsc is very secure. So in this case, the attacker deployed a smart contract two weeks before the hack. they um they harvested over time the three signatures they needed from those um from those employees when they got all of them they they triggered the transfer ownership of the safe and and you have heard it before right so it's it's kind of always the same and then they managed to

withdraw all the funds um so here what did we learn from this one right it is very similar to vasier So multisix have that attack surface. Um in in this specific case um using devices to sign which are also being used in development uh or for other purposes is is an inherent risk. Right? So I'm here I'm quoting Peter from from the great Brock thread newsletter uh from his talk last year which is basically saying buy your devs cheap Chromebooks to do the signing.

Um increasing the signing threshold it can help or lowering actually the amount of people you need to secure it can also help. And um yeah, as always, if you if you need to stop the world, in this case it was a multi-chain attack and you have a measure in place to very quickly shut down access to systems across many chains that can be helpful and we'll see that in a different hack. Um too a few details. Uh later Radiant Capital also did detailed forensics on what happened actually how have these laptops been compromised and

here I want to say that um I heard uh in discussing with people it was a malicious PDF right and now you're afraid of opening PDFs. It's not a malicious PDF. It was something which looked like a PDF, but it wasn't. So, a playbook you see here in the Radiant Capital hack, we actually have seen being used uh to great success again and again and again in the last year, right? So, really this is one to look out for. you have um a telegram account you trust because you already had interactions with them and they reach out to you unbeknown to you the user isn't the user

right the telegram account was compromised and in this case this user was going and like the attacker was telling the developer look I have the security research I want to show it to you and get your opinion right I And it's very enticing to be asked for opinions uh for your technical expertise. And this happened here. And then what they got was a link to a zip file. The zip file contained a Mac app. If you open the Mac app, it opens a PDF, right? And it made it look like you would get a PDF. Um and um in in reality because you executed a

Mac app here of course in the background you you had full compromise of the system. Um so uh through that they were also able to compromise more devices because that uh report was shared right and so on and then they could wait and um wait for the right moment to harvest those signatures. So basically this is what happened with Radiant Capital. Now we um we presented a lot of this actually in a more than one hour workshop in DevCon uh together with um Mood Gupta from Polygon who went over a lot of these things right you can you can of course find it online um of this.

So the next thing which happened was the one hack you all know uh about right the bibbit hack the the biggest hack ever in probably the uh history of humanity if if it's direct theft of funds um I'll quickly go over it because I know like that also a lot of people know a lot about it already but just in case you Don't know what happened here. Bybit had safe wallets as their cold wallets uh as multi6 and the safe um wallet is one which you usually access through uh

the safe website. um this website got compromised and um um like like in in this case a developer who had AWS access to deploy um resources which were used by the website an AWS key on his machine he was tricked into um downloading some uh docker container which uh or yeah docker container which uh I think it was a trading application but basically which compromised his laptop an info stealer.

Right? So this is common. We see that a lot a lot. Right? But now they had the AWS keys. They were able to um exchange the JavaScript file on uh on the server and put in something which specifically targeted by bit. And when then bybit was doing a routine transfer from their cold wallet to the hot wallet, they um they had a multisc in place and and everything right um and then multiple independent signers. But when they signed off on it, all of them relied on what the safe UI tells them. And and it got better. I wouldn't say way better, but it got better today that you have a higher chance to validate what you sign on your ledger than on the safe UI. But

back then it was very hard. And because it's routine transfers, you you don't do this. Um now again the usual thing happened full safe transfer and um you can run away with all the funds. Um so advanced social engineering across the supply chain and that led ultimately to this biggest uh heist uh we we have seen in in this industry so far. uh by bit was very good at like um communicating this very openly. We have we have a lot to learn from this and this actually enabled the industry to improve a lot

but but to some degree you can say it took a 1.5 billion wakeup call. So, what did we learn? Force devastating attack, same type, right? I mean, how many more do you need? Uh, single point of failures. I repeat the same thing here. Um, and and then you can really think about how you remove them. You can try to remove the damage a single transaction can do. My current go-to call is start to develop mobile front ends. Mobile apps. Mobile apps are much harder to compromise and mobile is a much safer environment than a laptop uh inherently so right offer your users um this and safe did it safe actually had

one which is pretty usable right it wasn't used in this case but we should make it a standard trust the mobile app over the website much harder to fish too right so um also if you rely on centralized custodians hold them accountable, ask for like their opsac and that they need to like prove that they adhere to good practices. This signing of malicious transactions blows everything away in number of hacks which we had in in volume right and there is a long tale to this there are many people who do this um with much smaller amounts day in and day out so

don't forget this I'll come to a smart contract hack uh the second biggest this is on SUI's exchange and here Um we uh we we have we have a a kind of simple arithmetic error which which caused then them to um lose 223 million but they were able to freeze a lot and only 60 million were uh leaving the chain. Um of course decentralization versus security the usual thing right. Um so what I wanted quickly to show you what was the underlying thing which happened here. So if you want to convert a number like

0000 one two three into one two three yeah which you you have to do in uh with computers um then it's pretty simple what do you do? Yeah you simply cut off the the three digits on the left right and then this is written as this left shift operator. Now what if the number is higher than 0 0 1 2 3 right or like just if it's a thousand for example you want to revert and how do you do this in computer code right I mean not rocket science you just say if number is bigger than bigger equal 1,00 you revert uh you can write that cooler right then you say like you you left shift one by

three then it's a 1,00 I'm using here decimal mass Right? But of course we do it usually in binary. Um and then you revert. Um why is it written this way? Because we deal with large numbers, right? And then you don't want to have to write 196 zeros. You you write it this way. So so it's more readable. And this is all safe and good. What else can you do? You just look at the leftmost three digits. Looks like this. And in computer code, it looks like this. You have a mask. You say like, "Hey, this is what we look at where the fs are. This is what we have because we have x or and then only only those numbers survive kind of it must be bigger zero and then we want to revert can be written cooler again with with

the left shift operator what happens if you combine both right then then it's not good so this is exactly what happened in this attack a math library on sui was uh like doing the protected shift left which protects against these kind of errors but it did it incorrectly And in this case you see in this uh line you have the mask but then on the second line with in the if condition you actually use the the check which you use if you directly compare numbers and not masks right and then this is what happened here and then um then basically satus in the end got hacked.

So um new blockchains it's dangerous because they they have their hidden bucks of course and you still need to learn about them. Um we we can do that with fastesting libraries uh because they are small and they're easy to fastest. We can even do formal verification for them pretty in like efficiently. Um yeah um we um should in this case we had a silver lining. So was able to stop the attack a lot of the funds from being lost by telling the validators to please um block this.

And this is what um in the end secured a lot of funds um but but of course less centraliz less decentralization. Um we have a few more hacks but we are also out of time. uh the penpai hack re-entrancy uh attack once again um in yeah avoidable to some degree but also not avoidable because it's on top um like making a liquid token on a pendal system which is a very complex system in first place is very complex adding features on top and then I mean do you have to pay to re audit for six weeks

your whole project because of a small new feature yes but of course you can't afford report, right? This also doesn't make sense. So, we are kind of lost here. Um, my go-to message here simply is try to stick with fewer auditors who already know the system. You have a little bit a higher chance that they actually catch it. Um, so yeah, the very last hack on the list on stacks blockchain with Bitcoin. um both like sui bitcoin and like near misses we had show that other blockchains have inherently uh risky behavior in in this case um it was um not understanding the s contract

thing which does something if you know what a message sender does it's kind of safe but if you also know what TX origin on Ethereum does then you know a little bit what happened here that um the attacker contract got got ownership as if they are the vault and then could withdraw all the tokens. This is just how s contract works on stacks. But um um that's that's kind of weird behavior. So also here you need to understand deeply the library before the the language before you can audit it and you must um you must um understand this really. So we are out of time.

Uh I think we don't have time for questions. No. Okay. Thanks everyone.