Top hacks since Devcon SEA - what did we learn?

Transcript

[music] [music] Okay, welcome everyone to the top hacks since last Defcon, which is surprisingly long ago. So, it's a sadly surprisingly long list. I'm very happy to be here together with Mood and Nick. Um, start with quick introductions. >> Hey folks, I'm Mud. I'm the CTO at Polygon Labs. Uh before being the CTO, I was the SISO leading security at Polygon Labs. Um Polygon the L2, which was the L2 before L2s existed. Uh and yeah, like I've worked on uh SUJIS swap, R&D, I've

worked at Polymath, I've done a bunch of cyber security stuff and now just combining the security side with engineering at Polygon. >> Hi, I'm Nick. Um, I'm a research engineer that's part of the safe research team. I've been working recently on self-custody and account security. I'm trying to make people's wallet safe, I guess. Uh, formerly a core dev at Cow Protocol. So, I've been around the DeFi space a little bit as well. And I am also an avid tinkerer. So, I heard that there's a make your own hardware wallet happening and definitely want to playing.

>> Yeah, I like to pitch that one. Uh, so I'm Matias. Um I'm the managing partner at chain security. Uh chain security is one of these uh audit companies out there. So among our clients are many many uh of the the DeFi projects, the projects in the space also the chains. We also [snorts] like to do a lot of research. Um, and so here comes quickly a shameless plug for a talk you should visit if you are developing smart contracts are responsible for them which is at 5 where Jiannis will talk about what Glamsterdam the upcoming hard fork changes so that your smart contracts if they do some try catch things might break. So I recommend that but let's go

on and head over to Nick. >> All right. Um, I mean, we talked a little bit about this, but new people came into the room, so we're going to say it again. There's a small CTF challenge that you can all participate in. It's um, try your hand at hacking a contract like it was like one of the hacks that we talked we will talk about later. Uh, it's lots of fun. There's a special surprise. Uh, so do give it a shot. Okay, let's start. So, first hack, what should we talk about first?

>> Okay, so any suggestions from the audience? What should we talk about the top hack since last Devcon? Okay, so I'm somewhat of a magician. We have Binance as the next hack. So 6 and a half mill billions we 6,360 million that has a ring like of dollars was stolen. Um about uh like 2.7 has been frozen so far. So almost four still pending um which is sort of the net loss at this point but I'm sure we'll recover more as we as time goes on. It has lots of learnings. So we'll talk about this

first. I'll give a brief summary of how it happened and keep in mind this is um like just based on the facts that Binance has disclosed publicly. So it it has still lots of things missing. Uh I hope Binance does a proper postmodern which has the details because every postmodern is learning opportunity for others like we we should be like the um aerospace industry like if an airplane ever crashes there's a proper investigation proper report so it never happens again like that's not a standard practice in our space. Uh unfortunately lots of hacks happen um and they never get uh a proper postmodern. So we the same things keep happening again and

again. So I hope Binance will change this. They've already done a good job at communicating so far. But that being aside the way it happened was essentially um same old story it started with spear fishing. Um let's say engineer B in Binance's word uh was approached by the hackers uh with a job opportunity. they uh gave them uh they gave the engineer P a take-home assignment uh very similar to the CTF we just gave everyone that hey uh fix this code or find issues or whatever and um like once you have uh like once you have done the assignment

then reach back or it was a live coding exercise. The moment the engineer ran that code on the device it was game over for that device. The device was compromised. Um so like at that point uh the attackers had control over engineer B's uh device only because they obviously like there just at this step there are many problematic things. One the engineer running uh untrusted code on their work device. Um this is probably the takeaway. But uh once the attacker had access to this laptop, they started doing their recon and privilege escalation and seeing like where else they can infiltrate Binance through this

uh laptop because this laptop in itself didn't had anything to steal. Um but it doesn't mean it doesn't open up other doors for them. It's just an entry door. So they realized it opens a bunch of doors through an internal AI tool springboard they had. So what they did was they jumped from this engineer's laptop to let's say DevOps A uh their laptop uh through the springboard tool. Once they jumped on the DevOps a laptop obviously the whole exercise started reconing what it has and so on and they realized it has uh token which allows container deployments on the wallet infrastructure.

So the way the wallet infrastructure was working at Binance was obviously there are uh MPC/HSMS which are the underlying signers and the key holders. Um these were secure technically but how do an HSM or an MPC knows what to sign that's the signing pipeline that's the container which feeds information to this MPC or this SS HSM and the MPC HSM like just sign whatever comes from this container that's the standard practice across the industry it's it should not be the standard practice but it is now what this means is the single point of failure becomes this container. If you

compromise this container, you can ask for any signatures from the HSMPC um and it will sign them. That's exactly what the attackers did. They compromised the container. They compromised the signing pipeline. And once uh the signing pipeline was compromised, it was game over. They asked the uh MPCHSM to sign withdrawals of $6 billion. And MPCHSM saw, okay, it's coming from my trusted container. I'll sign it. um it signed it and the money was drained. Uh Binance reacted quickly to stop uh more infiltration and loss but like 6.3 billion was already stolen. The way it was stolen is also interesting. Uh do we have EIP7702?

Yeah. Okay. Let's do the learning first. So what did we learn from this uh hack or what will we learn from this uh will learn from this hack? So few things I want to highlight. One, although the hack started from an engineer being spearfished, um that was that is not the problem here. Uh simply because like it's not the engineer that failed. It's the system that failed that led one engineer being compromised um into $6 billion of loss. Like people are going to get fished. That's no like there's no way around it. All you can do is reduce the chances, but it's going to

happen sooner or later. Um, if it's not fishing, it can be bribery. If it's not bribery, it can literally be a $5 uh wrench attack. We have seen a lot in France uh lately. Uh lots of kidnappings happening and so on. So like one engineer should just never be able to take six and a half billion dollars. That that was the main problem here. That that's the main take. If we take away like one thing from this hack, that's it. Like if if your system lets one person steal $6.5 billion, that's the problem. The person being compromised is not they're going to get compromised one way or another. So it's not the engineer's fault, it's the systems fault. So don't hurt the engineer, please. Um then uh another

thing to mention is um um rate limiting. So like 6 billion being stolen in one sweep using EIP7702 which we'll talk about in a bit but it's just again a system failure. It should the system should not allow $6.5 billion taken away in like immediately. uh if you look at tradfi no bank would allow you to make this sort of transfer u without multiple authorizations delays and whatnot like it's just even much smaller amounts so why does binance have the have a system which allows this again a system failure uh you can have uh limits especially on

the EVM environments you can use a smart wallet you can use polygon's smart wallet as well selfless plug but it literally has um like rate limits built in. You can rate limit which token, what amount, what uh period and so on and it would be enforced on chain. Um you can build your own smart wallet. Binance has the resources to do it. You don't need to use a third party one. They can build a very simple one. Um so like that's the other thing like have rate limits everywhere in systems. There is no reasonable use case where there is a $6 billion withdrawal required within 5 seconds. It can wait a few minutes like at least. Um so that's the second

takeaway. And then faster freezing uh is obviously like we already froze $2.7 billion or so um which is great. But the downside of this is that now the hackers know this can be frozen. So they will pivot faster. They will move out of USDC and USDT faster rather than staying in it waiting to be frozen. They will move out of arbitum faster. They'll move out of polygon faster and so on. So we need to also catch up like we we also need to have f even faster response uh as time passes. So it's something we're doing fairly well now but we need to keep

improving. it's going to be sort of like a cat and mouse game uh with the attackers. Um and then one more thing I want to add is like another takeaway is uh like HSM's MPC whatever wallet you're using is only as secure as the pipeline that is sending signatures to it. Um this was the root cause technical root cause of the Binance app that the pipeline got compromised. If your pipeline is compromised then your key being safe doesn't matter. The hacker never got the private key from Binance.

The private key is still safe. They can continue using the same one. They shouldn't, but they can. Um it's the part that compromised was the uh pipeline sending data to the signer. Uh which means this is as the pipeline is as needs to be as secure as the HSM or MPC wallet itself. Um you can have rules within certain HSMs. uh you can do that or you can uh have an enclave uh build everything there or there are bunch of other ways but basically you need to secure the pipeline as well. A single person should not be able to change the container image of the pipeline. Um you it should require multiple signatures and so on. So these are the main takeaways would say from Binance hack

details are still rolling in. Um but that's it for now. We'll >> yeah I can add just one more. um when you see how these transactions which left Binance wallet um timed right then you see that like Ripple was hit first and the big extractions which then we'll also use the sweeper we'll quickly go into came 15 minutes later um at some point Binance reacted by um sweeping funds from another hot wallet to their cold wallet and you see this on chain how it was done and you realize that this was done in the heat of the moment and you had they were able to do it

quickly but it was not something they prepared for. Um, so it took time, right? And when you need to patch this into a system which still has like hundreds of millions in the not compromised hot wallets in that moment things like you sweat a lot, right? So errors can happen here. You really try to prevent that. The message here is a learning you we can prepare for very rainy days. We'll get into more hacks, but almost no measure you can think of to prevent harm is like enough, right?

You can you should really think of like to the maximum extent you can go and often for those also which don't run protocols but which are users in protocols, it's escape hatches, right? Run to code wallet safety. Um so this is the only one to add here and it will get more and more important to be able to do this quickly. One of the things which was used here and which was also like on axe uh like described of course a sweeper was used. A sweeper is a version of a wallet um a 7702 wallet which is a smart contract right so that if you don't have the private

keys you can still control that address like if you had the private keys and then it's done very efficiently right every ease which gets sent in immediately gets forward any [snorts] ERC20 which gets sent in and it doesn't really get sent in right it's just a balance change on another smart contract you can efficiently sweep. This went on in the case of Binance for 3 hours when actually still people were sending in more money to that compromised hot wallet. Um and um likely even some refunds, some automated triggers of refilling an two empty hot wallet triggered stuff like that, right?

So um this is also something for everyone who has been fished ever perhaps on not a lot of money but where that happened to their Meta Mask or whatever hot not so important wallet hopefully on their device they will likely now see that this is something being deployed at their address right so so this is offtheshelf malware you can buy cheaply very good code very efficient code Um, so, uh, just so you know, even though your ledger, your cold card, we'll get into those later, is still holding on dearly to your seat phrases, um, your account might be

compromised even going forward until you recover it, which in the case of Binance took them three hours for good reasons because if you're not prepared to that, you need to [snorts] hack into your system to somehow delegate again to address zero and so on, right? So this is I think an important take-home message here. We'll get into the next hack. Bitget. Bitgget. Why BitGet? Right. First it is again one of the top hacks we had. 388 million were taken here. It was similar. We know much less about the BitGet hack than we already know about the Binance hack. So again, a

little bit a shout out to Binance to keep it up and disclose more and a shout out to BitGet to perhaps release more. We know they did forensics on this and they shared very little of this, right? Product A was compromised. Product A in Bitkate's in Bitgate's case was a security product. Was it their edr? Was it their web application firework? Was it some other script they selfdeveloped and don't want to talk about? We don't know, right? We can only speculate. But they say it was a zero day. If you trace when this happened and you ask your agent to find zero days around that time, there are [snorts] some

suggestions of which software it could have been, but it's all speculation, so I will not name it here. Um they gained privileged access to that. They also had um a control software they call it product B which also was compromised. um they were again able to laterally move to the signing infrastructure. So same story here. It took BitGet was very fast in incident response actually in shutting down withdrawals, shutting down deposits which are for a centralized exchange generally the entry vectors you think of, right? It's like something in our public facing website is broken.

Someone got some like compromised users or whatever, right? We shut this off. It took them quite some time to figure out what's actually broken, right? which is a hot signing infrastructure which kept like withdrawing stuff for quite some time. What did we learn here? Like yeah, private keys can be very well protected. It's really all of these exchanges use hardware security modules to protect their stuff. But it's not enough. Uh it was mentioned already. I will not repeat this.

You need to treat security products which you put into your like chain into your systems also as attack vectors, right? They can be and they will be attacked. Um the general other recommendations isolate the wallet infrastructure more like put for some withdrawals humans in the loop to ensure that this is something you actually want to do. Limit the damage of a single transaction. Limit the damage here. Like put in like anything you can to slow down the max velocity of funds losing like like um leaving your system. It's just repeating the same test emergency

response. Test if really bad things happen, what are you going to do? Because you'll be so happy about having those playbooks in that moment. So take away from these first two and there are a few more but those are the biggest ones. Compromising hot wallet signing infrastructure led to the biggest amounts of funds lost. The fewest amount of hacks but the biggest amount of in volume and they usually were done through like highly targeted attacks. But then these attacks we know of for quite some time.

Let's go to the next by bit. I just had to include it because I realized it has been so long since last Defcon. You all many know it. I think it has been talked about a lot. It's it will be a speedrun. 1.4 billion lost,430 million hacked through a supply chain attack. the uh developer was compromised who had the ability to upload uh code on the safe wallet, the UI, the website of safe, right, which was [snorts] used by by bit um to sign off on transactions.

Um this was done with a very specific like uh change which just targeted by bit. They tricked the signers into believing they would sign some routine transaction. It really wasn't. It was changing the safe uh the smart contract to another version, right? Changing the master copy. This is on the good end something where we learned a lot from something very specific which is if you sign a transaction from a multisc and safe by far is the multisc which is most used by crypto projects which aren't at the stage of banks [snorts]

in like being able to spend money on the infrastructure. um use multiple use multiple front ends right and we do have multiple front ends by now and the like community stepped up and develop those tools and today what I know a lot of people do they ask the agent to validate and that's perfectly fine right you have two things which validate the agent and the safe UI so it gets much harder for people to compromise this speedrun but also quickly throw go back long time ago uh back then Mood and I did the same presentation at the same venue well not here but at DevCon uh it

had similar hacks it had similar takeaways I highlight this slide because unchanged right is a single person able to like take away all the money now yeah you always will have a problem do you have a single action source meaning someone it's not a single person but an alert which can be faked and then it goes out to three people and they all send immediately the money to the attacker right also a problem single communication channel a single UI like we talked about but then in depth and we are at that stage where it's about in-depth thinking of of this is do you have a single brand of a laptop right

can that be compromised do you have a single operating system do you have a single HSM and then this is why I I'm currently pitching Austin Griffith's workshop next week and not next week tomorrow where he builds wedgie like $30 um do your own hardware wallet right so don't use that alone but it's one out of three would be perfect if we live in that world um single type of operating system if you want to get paranoid but we might have to only the paranoid survive a single internet connection. Right? We will get to know a lot more about interesting hacks.

Let's go to the next one. All right. So, the next one is going to be about Poly Market. So, this is relatively small compared to the other hacks that people have talked about. It's only 3 million, but uh recency bias. It just happened. So, it's worth to bring up. And I also think there's a few um interesting things to learn about it. So at its core it was like in other cases it was just a plain old software supply chain attack. Um poly market uses um something called debug bear which is a performance analytic tool that they use for you know tracking UI performance making sure things are working and collect analytics this way. um debugs bear GN DNS was hijacked and uh they actually replaced what debug bear so

debug bear loads a script at runtime. This is like a post served from their CDN and their DNS got hijacked and made the script that was being sent something malicious, something that had additional code that was used to extract funds from users. So if during the hack, during the incident, if you opened up uh Poly Market and logged in, then your funds were at risk. Um very basically it worked by um it would read the credentials first from your local storage. So some credentials are stored somewhere in in in your browser and it it read those and it uses those later on. It would go through the page the uh like the react hooks like the data in the page the DOM all this stuff and traverse it and try to find the trading

client and the signing client. These are components that are used for actually signing transactions, doing withdrawing the positions, doing the trades and uh you know get itself in there. Um and then finally it would request signatures to move balances to the attacker. Um yeah, it actually used uh the books bearer own domain in order to uh communicate back with the attacker which was really interesting because to get around um like u you know browser policies against cross domain uh cross domain um requests and things like that.

Um yeah and it again it was very targeted. They actually had multiple paths depending on what type of wallet you used on Polygon, but we'll get into that in a little bit. So what can we learn from this? I think one thing that's important to to to learn is just how dangerous supply chain attacks are and that they're they're also not super direct. Like it wasn't an npm dependency or like a buildtime dependency that got that got compromised. It was DNS from a third party provider whose scripts you load in at runtime. So we have software is getting more and more complex comes from many places and it's all coming and all of these pieces have to be solid. None of these pieces can have compromises

because if one of them do then you can potentially you know form formulate an attack from there. Um and also like you know in a client in the browser your different third party code does not have any special um fine grain permissions. So you can't say that the script loaded from debug bearer can only read performance metrics. No, it actually had access to the whole page and it used this access um very maliciously. Um so what can be done? What can we do in order to prevent these kinds of uh interface attacks? Well um you could have add additional guards or policies on d like actions that have high economic impact. So, for example, withdrawal, you could change it so that withdrawals can only go through to

pre-approved accounts with delays to approve these accounts that kind of make it harder in to to exploit a compromise of the UI. Won't ever protect it 100%, but I I believe that security is all about Swiss cheese. If you get enough slices of Swiss cheese, then there is no hole all the way straight through. And so, you add these things together and you just make it harder and harder for for the attackers. You can also um design for hostile page code. So you can make design decisions and engineering decisions in how you build to try and protect against um this you know this you know have your threat model also include what happens if my UI gets compromised um and you know spend some time securing

these complex supply software uh complex software supply chains like for example in poly market's case um they didn't have any u these like integrity checks on the script pulled from CDN and adding these would have potentially made this attack not work. Um because then the hashes wouldn't have matched and the script wouldn't have been loaded. And finally, I think I mean this may be a little bit biased because I I work I work with on a wallet, but uh make wallet consent meaningful. Um, I would argue that in Poly Market's case, uh, wallet consent isn't really meaningful.

And I just don't mean clear signing or anything like that, but have the consent actually, um, do something meaningful, like, uh, it's not just a button you click on the interface, but it actually there's some cryptography behind it. And, uh, I actually took three screenshots of different transactions, uh, that are, you know, withdrawing from from Poly Market. Does anyone want to guess which one is malicious? Or which ones? No, the last one is not malicious. It's the first one actually, but they're all they're all identical. There's like very little that you can do to tell the

difference. Um, actually the last So the first steps are I think one of them is an approval. Um, I think I don't remember exactly what the steps are, but the first the first three steps are fairly normal. they're just you know interacting with the token for example and the last step is the actual withdrawal and even in the withdrawal it's not immediately clear who you're withdrawing to there's an indirection about like a withdraw request ID and it just makes understanding what your transaction does very hard and again if um there poly market has actually who here has used poly market before does anyone have used the magic signer the signer with with Google you do so do you have to sign anything like on a separate web page. No. So,

this is what this is another example what I mean by meaningful consent. The you're consenting through the web page, the same web page that might actually have a um a compromise. So, the consent isn't really meaningful because the web page can't consent on your behalf. Um so, yeah, and actually the the scripts did slightly different things depending if you're an EOA or if you're one of these magic wallets. if your magic wallet actually exited positions in order to increase the amount that it stole from you because you don't have to consent. The next one >> okay before we go there I'll add an interesting bit from the poly market hack. Um so well well two things actually one I beg all of the wallet developers to add transaction decoding

uh simulation using AI now like let the users know what they are signing not gibberish like no no nobody reads that gibberish like no matter who you are like it just it's not a real thing uh we can ask people to so please like all of the wallet developers work on it I beg you um then the second thing I want to say is so one interesting tidbit about the poly market hack which is not known publicly. So fresh information for everyone. Um so the hacker's funds a good chunk of it was frozen on polygon.

The hacker uh can't move those funds. So the hacker did something which is interesting and is is not very common. they started going to the validators of Polygon 1 and one and trying to bribe them to uh like join a coalition so they can unblock their transactions. Obviously, Polygon is decentralized. It has hundreds of millions of dollars of uh like stake at uh at the line. So, none of the validators joined in. Uh but it just shows like how far attackers can go. And this was not a state actor or anything. It was just like some random person, let's say, uh doing this for um like about $3 million, which is a good amount, but it's not like super big. For

hacks that are in hundreds of millions of dollars, you can imagine the kind of bribes being paid or other extreme things like kidnappings and so on that the attackers might do to get their way through in. So, it's like uh yeah, decentralization definitely helps there. Even if you are running a centralized thing, at least don't give all of the power to one person that might get bribed or hacked or sawed uh in a way. We move on to Kelpdo. You want to talk about it? >> Yeah, I can do it. Uh let's see. So, Kelp DAO.

This one was one where we whoop where we um have um again this um developer laptop entry it was um good I mean it was an attack which when you read through it you think pretty advanced right it wasn't this drive by malware which uh someone clicking on a link and installing the wrong tool. It wasn't the fake job interview tricking you to download something. No, this one was different.

This one was um the in in the layer zero infrastructure, you need multiple attesters to what's going on in another chain. I mean, it's a bridging software, right? They need to listen to what's happening on other chains to attest and then release funds. In this case, the attackers were able to um in memory change on the um devices from layer zero what they were believing to be true.

Then they were dossing an external validator so that layer zero would fall back to like just trusting one something which was in this case configured on kelp to be okay and um through that eventually would sign off on something resembling an infinite mint de facto. [snorts] This then really only caused and still causes major pain across the DeFi space due to the contagion mostly hitting AVA because they had like a onetoone uh oracle against this um asset which

was their printed this RS and so it was the attacker was able to basically drain all the available liquidity from Ave and um recovering that was and is still very expensive. Um this is also because while some protocols actually are profitable, it is they are not by far as profitable as someone like a centralized exchange and that Binance can just say, "Oh, there happen to be six billion lying around. We can cover that." Right? is obviously unthinkable for any D5 project.

Um so yeah this is why this caused a lot of pain but but the hack was um technologically pretty pretty good. We can take some learnings but they are specifically very like uh directed at that hack like configure it securely. We have these cases where we do deployment validation right? If you deploy a smart contract or some system, we look into was it deployed correctly meaning which mostly means we look at the state and there we flag like okay you configured it insecurely with too little thresholds in something like that right so this is still done rarely but sometimes it is done this can help of course uh you can in general again try to get towards more

like be more decentralized more distributed in who you trust Um and the last one don't clone random GitHub repositories right this just something which is dangerous all of these >> I can add on one more bit on the kelp hack. So um I I'll try to add a more generic learning there. So if we if we go back one slide um it these are very specifics but the underlying pattern is u risk isolation in some sense like any one component can always be compromised but it should not lead to the whole system failure. I'll give another example which makes it clear. So there

was this bug in um apttos disclosed by hex a few months ago um essentially arbitrary state right um so it was very complex to execute so it's not like I I can just hack laptops right now but it could in theory and in practice lead to the attacker writing random data on random storage which means I can just increase my USDT balance on Aptos from $0 to a billion dollars and the chain would continue working. All the validators will accept it. It's the state now. U now what this means is obviously you can steal all of the funds on Apptos itself like you can make everyone's balance zero. you can make

your balance whatever you want it to be. But it also exposes uh a vulnerability in bridges that is just across most bridges very common and this was a bridge hack after all uh essentially which is just reliance on single point of alias like the chain. So bridge for example Dbridge layer zero overall they are securing like tens of billions of dollars maybe even hundred billion like I'm probably so hundreds of billions of dollars um and they're trusting Aptos to keep it secure doesn't have hundreds of billions of dollars of security at it um they are even trusting weaker chains

than Aptos sooner or later a chain like they're trusting is going to get compromised which can lead to drain of these bridges like let's say they are on chain chain A uh is supported by a bridge uh and I inflate my balance to $10 billion on chain A. I won't get anything from chain A but I can bridge this balance to Ethereum to um other chains arbitum polygon whatever using these bridges and withdraw funds from there uh withdraw real funds from these other chains which had no bug uh it's just layer zero or Dbridge backing that is being withdrawn so chain risk isolation and risk isolation in general is very important um like for example

here very particularly what you can do is uh a chain should only be able to bridge out as much as was bridged in. Like if it if $10 came in, the chain should not be able to bridge out $100. Um I know few very few companies in uh right now in the in our space have that level of sophisticity because most are just using the standard DVN or standard bridging and so on. Um, Polygon obviously has ag layer which was built from ground up to fight against these scenarios. We have pessimistic proofs as our core feature which essentially protects against this uh attack. Uh, and also shout out to the folks at USDT0.

Uh, the security team may or may not be in this room but they also have um protection against this attack vector that they do not let more funds go out from the chain than came in. uh they built their own custom DVN to add this functionality because the default stuff out there doesn't have it uh but they did it like if you are managing serious amount of funds this sort of things are what you need to work on you can't just pick the most famous bridge and say I'm good like kelp tried that didn't work out so you you just can't trust a component even a bridge without actually understanding what's going Yeah. What all connects those are it

were ways to make users sign malicious transactions, right? And then then again it was usually highly advanced attacks. But then there are many more where users were strict to sign transactions which are not that advanced, right? And and if you look into the U numbers which are like going up a lot currently of the tickets to be handled by SEAL we we are like with the last update from todayish we at 99 per week right we were at like below 80 last week and so on and this is just a one of these charts you don't want to see. Um so these kind of attacks we talk about here as part of

top hacks with a very advanced version have their other very non-advanced version where we have more than 80% of the total hacks by number ledger wants to cover ledger I will cover ledger >> okay so ledger again it's another example of a supply chain compromise. So in October roughly 100 million was stolen from from users and Ledger attributes the thefts to implants in Ledger devices that were uh sold from a third party reseller.

Um yeah so there actually uh here's uh some pictures from the safe office in Berlin. We uh actually had one of uh one of my colleagues his personal device that he bought at media marked on Alexander Platz. So like the biggest electronics retailer in Germany in the most visited place in Berlin uh had one of these inside. So you can see like the anatomy of a lot of people have talked about it so I'll go over it very quickly but the anatomy of the implant is you have a little extra board that shouldn't be there. Uh it has um a modem and a little processor for doing some work.

That's number one. Number two is uh they actually use a smaller battery so everything fits inside the same uh the same case with some uh with like a battery circuit. Um here it's just wired to the main board. So, uh, actually some models even had an extra resistor here to trick the Ledger into thinking that it had a full battery because the smaller battery would mess with its, um, battery level indicator. And then just an antenna to send everything out. >> So, if your Ledger is always running out of power, perhaps look into it. >> Yeah, you should look into it for sure. >> Um, these device are actually the nanos are really easy to open. So, it's uh, doesn't probably why they were chosen.

Um, so what did we learn from here? So I think for me I think the these attackers are incredibly clever. They didn't break the hardware. They didn't break any cryptography. What they did was, you know, break our assumptions. Uh, the secure element on the ledger was intact. The the private key wasn't leaked. The the pneummonics weren't leaked and instead the implant would just monitor the SPI connector. So like the connection between the the the actual device and the screen. And so when you set it up and you put in your keywords, it recorded those and read your keywords and then sent them out later. Um, so it's like imagine you had they installed little spy cameras in your room when you did your ledger setup.

That's basically what they did. Although the spy camera was inside your device. So what we should do for sure, question your assumptions. Sometimes they may be wrong. I would argue they're here. Um, if possible, I mean, this is again hindsight 2020, but if possible, you should try to buy directly from resellers. Uh, sorry, the opposite. Buy directly from the company and not from third parties. It's not always possible, but it's good. Um, for uh larger holders, I think you should consider multi- signature setups with diverse signing hardware. This is also something that was in from the previous slide. Uh so you have different hardware wallets, self-made ones, treasure, ledger, um probably name a few more and uh diversify how you use how you get how

you sign these things as well like what interfaces you use. The more diversity the better. It makes it harder to attack becomes a a like exponentially more difficult problem. Uh but please do not stop using hardware wallets. Um this is also very important to take uh take here. So I'll jump to the next one. cold card. >> Okay. Yeah, we'll keep it quick. So, cold card was a randomness uh issue. So, uh there are similarities with more hacks, but basically at the hardware level, it was supposed to have 128 or 256 bit of security, but a firmware they pushed changed the RNG source from hardware to software, which was only 40 bits. 40 bits is like is not meaningless, but it's insecure in this

time and age. All 40 bits were exhausted offline by the attacker. They brute forced every private key possible and drained whatever had balance. So it it took about 15 days for them to go through the keys from zero to end. Uh but that's your time like 40 bits only 15 days like you you need many more bits as we as hardware gets uh faster as AI makes optimization as cryptography breaks. So uh don't yeah you have to be careful where your randomness is coming from. It may not be as random as you think. Uh we'll skip this one. I'll come back to it. No ways to get your seed phrase. It's again like randomness like

so Emodra issue was also of randomness like the keys were um again 256 bit or 128 bit but same thing as cold card they had a bug in their key generation code which changed the randomness from uh like the hardware level for from HSM generating the key to just injecting a uh unsafe key. The key they injected were numbers like four um and 17 and whatnot. I don't remember exactly but just very small numbers which can be brute forced by hand if you have to. Um so it's it's again like it just they were there for over one year. The reason

they didn't get compromised sooner is that nobody was looking and this is true in a lot of things and like almost all of the software there are bugs everywhere. It's just a question of when someone looks at that particular piece uh and it starts breaking down. The more attention something gets by like having more uh news around it, having more money and so on, the higher the chances that someone is looking at that codebase. So even if there is an old codebase which has which has not been hacked and is safe like don't trust it to be safe like it just might be that someone has not looked at it in a while.

Um so yeah like this was the reason I added this like emotra although it's not cryptoreated is the main learning from me is not really on how to prevent this that's just RNG like proper software formal verification all that like the boring stuff the interesting bit for me here is the opportunities it opens for us hackers like the tinkerers um now this what this means is this uh we we all know the one of the trusted root authorities private key which means We can generate SSL certificates for any website in the world and a device which has not been updated since this hack was disclosed will accept it as legit. So any of your IoT devices which I'm

probably sure are not getting updates anytime soon. Um like you can MIT them, you can figure out yourself like what traffic they are sending. You can modify the traffic. So you can hack your own fridge, you can hack your own smart light and so on. So it just opens up many more doors for tinkerers and for forever thankful to e-madra for that. Um it just opens us opportunity for us to exploit our own things. I don't think practically it would have that big of an impact. Although there are teams which are slow in patching this for example even on your MacBook curl hasn't patched this like Apple patched it at Safari level but if you use underlying tooling like curl it was not patched yet. So if

you were using a public Wi-Fi like Devcon um and it was compromised by someone which is fairly easy to do. We are in India we are like the guy running the hardware gets paid maybe $100 a month um then your max can be compromised. So it has real impact but the learnings are like maybe don't use untrusted Wi-Fi and also don't break RNG. I really wonder if this one will be featured the next time we do this as one of the parts which were needed to compromise because you had heard about these hacks of fridges in Europe, right?

I don't know paps, right? Where where they turn off the turn on the heat on fridges and then all the um like supermarkets have a problem in many of the routers in many of the switches and so on. There's also old some management hardware if it has some way to get updated it usually trusts some HTTPS um to as as the trusted source right and this is not trusted now anymore so I am expecting that while tinkerers profit from this definitely um attackers do too and I wouldn't be surprised if that would be one of the things which gets featured in the next big hack >> and be careful your fridge doesn't kill

um super tier we have to skip some um so so this one um was uh a very interesting bug actually and I've seen them in many cases right caching invalidation it's one of these things which is super hard to do it stays hard so uh in in like they had to do um proofs and um they were able to um create a proof which was um invalid but the cash has it still as like a early part is valid.

another one later would trust that. They created roughly 4K uh LBTC converted that this was again an advanced hack like and the hackers here um are actually white hats but not really right. So the hackers returned I think 80% or something like this kept 600 as a bounty. This is Bitcoin right? So times a lot. Um and um and then in that sense they like the project and so on got away with a blue eye but still it's like many many millions which were ultimately stolen here.

Uh oh yeah >> yeah just like the learning from there I will take is the timeline between uh vulnerability disclosure and it exploitation is compressing to hours like the reason liquid got hacked was not because this bug suddenly appeared the bug was there since 2018 it got hacked in 25 because it was fixed in 25 publicly disclosed um and that's what brought the attention it was publicly disclosed 5 days before uh it was actually applied by the validators and so on. So the PR was created but it was not applied yet. The nodes were not upgraded yet. Um the p the fix also introduced another bug which was exploited. Um but basically the whole

thing happened and the hacker said it in the uh in the in their messages as well. Um like that they saw they realized the bug from uh the patch that got released and um that's how it got wrecked. So uh the timelines and like open a comes to mind they had one vulnerability which is disclosed and within 1 hour there were live exploits on it. I'm for just forgetting the name but the whole point is the timeline between disclosure and exploitation is going to zero. It's like just crashing. So we need to be patching our systems with security updates like as soon as they are out. Automated patching is more important than ever. um like PHP disclosure which like they said

okay there is going to be a disclosure but we're going to disclose it after two uh days and details started leaking is not the ideal situation to be in we need to have much faster response time >> yeah but it's also a case like imagine a bug in a public like in a popular crypto library or li P2P or whatever right one of these things if we find it how can we even disclose it we had a panel on this with like Sky and agnosis on so on yesterday. What can we do? And I think the PHP approach is the only one we have which is basically saying there is something because what a lot of companies projects who ran on PHP did was they turned off their servers,

right? They just shut it down um because they knew it something is coming and they have no chance. Um and we always look that things are safe, right? Safety is one of the properties of a distributed system. Lifeness is another one. And as you might know, if the livveness isn't there, then the safety is usually there. Um, so this uh this is something to prepare for. But let's go on. We have a few more uh as we jump over I guess uh Sus uh an interesting hack from again the technologically side of things. It's a very like um a smart contract hack in the end where a library was attacked.

I can talk more about what happened here but in the interest of time one of the things when you rely on libraries is right they can have issues. So what we usually advise is you should extensively fast test them because you have very good um uh alternatives to validate if the output is true. you can good can do good diff fuzzing but today you can do something much better just use AI AI just understands that code and does inbrain diff of it I couldn't find an AI dumb enough anymore who wouldn't oneot and not with web search or whatever right if I give it a

obviously modified version of the exact sittus incident right? Which was some bit shifts, some X or like a little bit assembly like operations. It's just bomb. It's that, right? Even the lightest version of AI was using was just saying, "Oh, yeah, it's that." What else do we have? A final one. >> Yeah, bouncer. I mean, we should get to the CTF, but uh just to there's it's also been talked about a lot, so we don't have to go into detail here. there was a rounding bug that was amplified by other features and um yeah and they managed to drain a whole bunch of pools.

We can go to the learning slide directly. This gets a little bit more interesting. Um so yeah um the the act the risk of rounding causing issues was highlighted in the trail of bits audit many years before the actual incident. So just you know sometimes defensively guarding against risks and category of bugs even if you don't have any evidence of an exploit that can use them can prevent these kinds of things in the future. So you know again being defensive um and also um testing and formally verifying things is very hard and what's even harder is deciding what you test and formally verified. Um I don't know if you saw Mully's talk at the very beginning of the of the conference but this coming up with the informal spec for formal verification is the hardest part of formal verification

and uh it obviously missed some things here and also do continue to audit and formally verify just because in this case it didn't work doesn't mean that it doesn't prevent other issues from contin one thing I want to highlight is this one you make everyone's life easy code simplicity as a feature right it's so easy to add complexity today when we get fixes from someone, it's suddenly 50% more code, right? And it took them an hour. No. Okay. So, thinking how to simplify is still very hard. AI is very bad at this because it's so easy to add more stuff. Adding debug bear to your web front end is easy and quick and perhaps not worth the risk. So you

should in general simplify and kind of bunker down on your dependencies as much as you can in this age and it gets a little bit easier too right each dependency many many dependencies you can just like replace by your own coded version yeah there are the drawbacks of it but yeah generally simplicity as a feature has been undervalued a lot and might be undervalued because it's suddenly so easy to add complexity. So please don't Yeah, that was the last one. General categories and we have one more.

>> Yes, the drift one. So this one the only one thing I want to mention. So it is the most advanced social engineering hack we have ever seen. So I would recommend everyone to read about this and how it happened because it's just an exciting story. But the main thing I want to highlight is it started from a conference just like this one by networking. So people came to a conference, people were networking that's how it started. Um what like so maybe in next DevCon we'll see what this conference leads to how many social engineering attacks started here. Um so be safe out there.

>> Finally going back to the CTF challenge. Did anyone figure it out? You did. We have lots of people. All right. Pick one. >> I can raise his hand first. Uh the gentleman there with the shirt. Yeah, >> the first that I saw. I'm sorry if I saw wrong. >> I have already raised the issue as well. So file uh there was a npm package. There are two bugs and the npm package is save file name was downloading the version release that that was there. So yeah. >> Yes, correct. I put in a malicious little npm package. So if you did open the uh the the thing and run npm test, there is a file. Uh can you go to the next slide?

It just writes a file there. So I did do anything malicious, but it's just to show how easy it is to get caught up in like a you know like a conference and just like play around with some code and then uh someone actually had access to your uh to your home directory. But there actually was a bug and uh if you uh it's a rounding error. You want to explain it or should I go? >> Yeah. No, no, no. Please, please. >> No, go for it. >> I think like >> Do you want to explain it? >> It's a rounding error. That's it.

>> Okay. It's just a rounding error. >> It's an off by one rounding error, but like the bouncer hack, there is actually a way to amplify it to steal large amounts, which isn't obvious. Um, specifically, the very first person to enter this like share pool, you can front them and raise the value of a share very high and then you can actually pull out a lot of value. So even if it looks like it's just one way, it's not that big a deal, there's actually a uh there are situations that you might not consider that allow you to fully exploit large amounts of value. >> And yeah, I think we are at the end. Uh yes, >> it's the only way to say stay safe.

>> This this is the final one we can say here. Um I I asked um Pascar PC Vachio right who who is running safe of what to advise. Um that is a t that's not actually it's the the longer version of what he said. Um so we we are coming to an age where turning things off sometimes is the right way to do uh to fix things. So this is a little bit scary. Uh we haven't been there for long time. [snorts] I think we are exactly at four. I don't know if we do have more time or not.

No, thumbs down. Okay. Yeah. But anyway, we we are all uh available online, Telegram and so on. Um, if you have >> [music]