A (4:32)

Yeah, and we'll break down more of these steps as we go, but when I was looking at this, it really felt like the original sin here was around this, the admin key. So explain how it was set up and how it appears to have been compromised.

C (4:49)

Yeah. So in contrast to last week, we were talking about the Resolve hack and the result hack was unique in the sense that there was one key that had effectively unlimited privileges to mint as much USR as they wanted, which made it easier for the hacker in terms of how many keys needed to be attained and compromised. Here it wasn't a single key, it was a multisig. However, it was a 205 multisig. So this is like the minimum amount of signatures that you would need in a multi sig. So it's one step above a single key. The we're still waiting for an official, I think post mortem. I think Squad have written a few updates that as of right now, it doesn't look like that their infrastructure was compromised. They're the multi sig provider on Solana Drift are still in an Active war room. So we don't know exactly how, although there is speculation with the recent wave of supply chain attacks that have been kind of perpetrated and, and executed by Lazarus or dprk.

A (5:54)

And by that you're talking about the Axios attack that. So I'm not a technical person, but it's something like there's these libraries that just hundreds of millions of people access kind of very frequently. And so, you know, these, these exploits in a way could be sitting in a lot of different systems.

C (6:12)

Yeah, it's exactly that. Axios is, but one of them. Axios is a particularly popular package, but developers in crypto and Web two, they'll install hundreds, sometimes of thousands of different packages and dependencies that are open source and written by other developers. The way that this particular method works is it's actually quite clever. So if you can actually receive control on one of these packages, you just make a tiny modification where you can add a piece of code that effectively once run on any developer's machine, gives you root access to the machine so you can read and write whatever you want. And the second something like that happens, which we've seen with Axios last week with Light LLM, one of the biggest AI packages, but there have been hundreds of packages that have been infected in this manner. You can do whatever you want on the machine. And this is a much easier vector because you don't need to break any cryptography, you just need to maybe do a little social engineering for one of the many open source developers that may not even realize who and how their package is being used by. And you have access to the whole machine, it allows them to cast a wide net.

A (7:26)

The other piece that was interesting is you tweeted about some of the steps that you saw when you talked about that new multisig, you said, basically, so Drift created this new multisig and it was a signer from the old multisig that created it. But then you wrote the signer did not add themselves to the new role. And at first I was like, this must be a typo. I was so confused. And then I realized, oh wait, what he's saying is somebody had gotten a hold of the keys of the previous signer, created this multisig. They probably weren't aware. And then you noted that basically the new multisig was immediately signed by a second cosigner 1 second after it was created, and that met the 2 out of 5 threshold. When you see that evidence of the steps leading to the hack, what does that say to you about how this hack was pulled off and why the admin key was so critical to it.

C (8:31)

Yeah. So this next part is a bit of how I interpret the event and trying to, like, understand how it could have happened. It's still very much in the fog of war, but Drift had actually communicated about the migration to like a multi sig. And again, I think we mentioned that this might be the first time this happened, at least for this specific role. I'll speak on why I think it may have happened like suddenly now, a week before the hack. But it looks like this was a planned event. And I think that the hacker had some type of access that the team didn't know about. And so he may have had access kind of to the rest of the keys, and that's where the two signatures came from.

A (9:15)

Okay, okay. So then the other thing that was so fascinating was so you briefly mentioned this CVT token that they created and they gave it some wild parameters, ones where if anybody had looked at it, they would have realized, like, this is not a legit coin. What were those parameters and why would that flag that this coin could be so dangerous?

C (9:40)

Yeah. So I think just to clarify between two things, the. The coin CBT itself is just like a scam token that was created for the purpose of this attack, had very low liquidity and just a regular kind of token. On Solana, what did have the unlimited parameters and infinite parameters and max parameter set was the market. So this enabled the user or the exploiter to add CVT as a new collateral asset on the Drift protocol. So depositing it as collateral, they then continued to pump the price of that pool, because as they configure, the market could decide which Oracle was being used. So created a token, spun up a fake Oracle, or like a real Oracle that was pointing to the fake pool, pump the price, and then they had all of this kind of credit in the system that they could use to withdraw and drain Drift from all of the blue chip protocols. So this is again why I say it's sophisticated, because this attacker was preparing, he spun up the feed, he was running fake volumes in the AMM where the CVT pool, where the CVT pool was being traded. And the Oracle read the price from and then also created a fake market on Drift with max risk parameters. All of this happened unnoticed, effectively during the time of the exploit and with no restrictions.

A (11:02)

Yeah, yeah. So here's where we get to that original point we were talking about, about how this feels chilling because so far we can see that not only was there A social engineering component, but then there was an Oracle manipulation and then there was market manipulation. Like it's just, you know, using all the tools in the toolbox in, you know, I'm going to give them credit in a creative way. So, so, you know, at that, so at that point, just talk about then exactly what they did with the, with the coin to, to pull off the attack.

C (11:37)

Yeah. So a, in terms of all the toolbox, it's like very reminiscent of at least the market, the, the Oracle manipulation pump of Mango markets. Getting access to all of the admin keys is very reminiscent of usr. So definitely kind of drawing on a lot of different techniques and stacking them together to do this. The main difference here, however, was the manner in which the market was created. So, you know, in any kind of lending application or vault application, it's a, it's a pretty big deal which assets can be whitelisted as collateral because you're extending a credit line against those assets. So again, this was an unknown token. With those privileges of the admin, they were able to whitelist this token and decide where the Oracle was coming from, what kind of AMMs it was reading from. And here, once they pumped on a very low liquidity pool the price of the asset, effectively they had hundreds of millions of dollars in collateral, at least that's what the Drift program viewed it as, and gave them all this credit to extract all of the blue chip assets against it. So there's a few extra steps here, but the actual method of extraction is something that we've seen time and time again.

A (12:55)

Yeah. Honestly, this reminds me of when, for whatever reason, after Avi Eisenberg did the Mango markets attack, he reached out to me saying he wanted to come on the show. And when I interviewed him, and I think I used the word market manipulation or something, I don't remember exactly what I said, like the actual words, but he said to me something like, oh, well, what is the legitimate price of a token? Like, he kind of disputed that it was manipulation. He was saying that was the legitimate price at that time. So again, that's the kind of maneuver that was pulled here, at least when it comes to the smart contract.

C (13:40)

Interestingly, I don't think I've ever shared this before, but Avi Eisenberg also contacted us at that time because after the Mango market attack, he tried to wage a similar attack on aave. And we had configured the parameters such that we have these machine learning models which estimate the cost of the attack. So Avi was asking us for access to it he's like, hey, can I see if my numbers match up with yours? So that was one of the. Yeah, that was one of the crazier DMs that we received at Chaos.

A (14:09)

Yeah, clearly he's not the typical person. But anyway. Okay, so let's talk about the next bit because there's another component that I've seen has been generating some controversy on crypto Twitter, which is this notion about durable nonces, which is kind of a core part of how Solana works. So explain what a durable nonce is, what the purpose is for them, and then how that also became a potent attack vector.

C (14:42)

Yeah, so the durable nonce, basically like what it solves for, is that you can sign transactions that don't have time expiration. And there are legitimate use cases for this. Like for example, in an application where the user doesn't want to be burdened with signing a bunch of transactions, perhaps the application wants to ask the user to give a few permissions up front and then streamline the UX from there. So this is like one of the things that it solves for. But what it did here is as soon as the attacker had access to those keys, they were able to sign in those transactions and not ring any alarms and just wait for the perfect time to execute the attack. Typically without the durable nonce, they would have to sign and execute the attack, I think within a two minute time frame.

A (15:29)

Oh, okay, okay. So here's like a funny thing or. Oh, okay. No, that's okay. So sorry, I'll explain in a moment what I meant by that. So, okay, so Anatoly Yakovenko, the founder of Solana Labs, tweeted about their durable nonce. He tweeted, quote, durable nonce is observed on chain. So to sign it off chain, attacker creates the nonce on chain first and then transfers authority to the target. Your cold storage OPSEC can actually monitor for this and flag it with pager duty. There's no way to not have this feature because cold storage custodians have to have arbitrary amount of time to recover the key. Any system with smart contracts will basically end up with some version of this no matter what. Do you agree with him that there is no other way to not have this, or do you think that durable nonsense should be rethought in some way?

C (16:27)

I understand what Anatoly is tweeting is. My understanding of that tweet is that you can monitor and set alerts for this. So I mean, in theory you can sign any type of transaction here. There was A transfer of authority, which is actually something that we've seen in many, many DPRK attacks that they transfer authority to a different wallet and an attempt to obfuscate, like the addresses and all of this can definitely be alerted and monitored for. So my understanding of the tweet and just generally my thought on durable nonsense is used in the correct way. It's not like a bug in the vm, unfortunately, it's been used for a lot of exploits. It does have legitimate use cases, but for sure it's something that you can monitor and get alerted on. And that's where pager duty comes in. Especially for anyone that's dealing with hundreds of millions of dollars or doing, you know, hundreds of billions or even trillions on an annual basis. From a notional perspective, these are exactly the things that you want to be looking out for. And pager duty is just a very common kind of software solution to alert you when these things happen, get through your do not disturb and kind of get the team that's on call to start taking a look.

A (17:39)

Okay. I guess the one thing is, if the pager is going off, then isn't it too late at that point? Like, like already something's happened. Right. And like you might not be able to do anything about it. So is that really the best sol?

C (17:51)

No. I mean, so basically in anything in security or risk management related or operational security, the way to solve this is actually having like a good setup, sound architecture and robust system. And that's number one. This is like after the fact. And if we look at even hacks from the past month, like USR and even here, it looks like it took the team hours to react. And so that would solve for that second part of knowing that something bad has happened, but it's not necessarily going to prevent it.

A (18:22)

Right? Okay. Yeah. That's why I. I don't know, it feels to me like at the very least, potentially it could be structured differently. But I'm not a technical person, so anyway, okay, it could be structured in

C (18:39)

many ways to your point. Right. Like, this is one of the big breakthroughs in EVM and SVM is that it's Turing complete. You can program whatever you want. There's many ways to prevent it. But when something bad happens or something irregular, you want the monitoring just to alert the team and even the partners who are integrating. Yeah.

A (19:00)

Okay. Well, in a moment we're going to talk about what potentially Drift protocol should have done. But first we're going to take a quick word from the sponsors who make

B (19:10)

the show Possible step into a new era of wealth. Discover Nexo, the premier digital wealth platform. Manage your crypto portfolio with confidence and control. Receive interest on your digital assets. Borrow against them without selling. Trade a wide range of cryptocurrencies all in one platform now available in the US with 30 days of exclusive privileges for new clients. Experience Wealth Club Premiere access, enhanced interest rates, reduced borrowing costs, and crypto cashback on swaps. Get started today@nexo.com Unchained

A (19:52)

back to my conversation with Omer. So one other thing that I wanted to note here was in I mean, you had such great tweets kind of outlining what happened, but one of the points he made was he said there's no time lock, no multi sig and no delays, which is how all this happened. I also saw this is very direct Beanie Maxi tweeted quote what makes this $280 million drift hack so devastating is that it's not a smart contract exploit. We've seen Flash loans breach similar platforms before. In this case, a dev was phished for an admin key. It's inconceivable that no risk factors are disclosed anywhere. And then he said, if I lost my money in this, I'd be certainly lawyering up right now. So I'm just curious, like, when you kind of look at their setup, how would you say it differs from best practices?

C (20:48)

I think there were a few ways. It's not just one, but time lock is definitely one of them. And in this case, like having a time lock and when the transactions were signed and when it actually executed would have given a window of time for the team to potentially stop it. So that's number one the reason for a time lock. Yes, it's hacks and exploits, but it's just also to make sure that you're doing what you think that you're doing. So in lending markets, in derivative markets, when you're listing new assets, when you're changing parameters and you're making changes that are sensitive to the system, it's very common that you'll have either time locks that are a few hours or even a day for the thing to go through for more parties to kind of look at it, whether it's auditors, the risk team, or the core team itself. So that's number one. Like if had even if everything had gone wrong with the time lock, it still would have given them an opportunity to potentially stop it. And definitely for all the 20 plus integrating partners to reduce and mitigate exposure, that's on the time Lock. I can go more into time locks or speak about maybe the multi stick setup or infrastructure.

A (21:54)

Anything you feel like could have been done better.

C (21:58)

Yes. I mean multisig 205, again, it's one step over a single key. So for something that houses so much TVL you'd want to see more three or five. And ideally you can use kind of things like biometrics to ensure that the person who's signing is actually like who you think it is. And there's just so much you can do there today in terms of the signing itself. And then it's just alerting all of these safeguards and admin privileges were compromised by the attacker. But all of this happened without any alert to the core team and not to any of the teams that were integrating. So I think most of this news broke through Twitter. It took several hours. By the time the news was out there, the core Drift team had communicated. There's also nothing that the 20 plus integrators could do. And then similar to kind of the contagion with Morpho and USR that we spoke about last week, it's also on integrating applications to understand the counterparty risk of whatever they're integrating and set up alerts, circuit breakers and risk guards as well.

A (23:07)

Yeah, yeah, it's honestly like. So I don't know Drift and I don't want them to like take what I'm saying as, as, you know, being harsh at a time when they're sort of down bad. But, you know, it just sort of looks like they weren't super paranoid. Like to me, that's how it reads like. And I'm not a security person, but I've obviously written about it a lot. So yeah, there was just like a sense to me like, like, yeah, it just wasn't paranoid enough. But you started to talk about contagion, which definitely was an issue here. So explain, you know, how this HAC started affecting the other money Legos in the Solana ecosystem.

C (23:52)

Yeah, maybe just a word on the team before I jump into that. And just for all teams, I know some of the core contributors pretty well. They spend time in New York amongst other places that we frequent and they're a super hardworking team. I've seen them work all hours of the day probably over the past few years. So I don't know that they're not paranoid. And we'll wait for the postmortem so much as there's all of these audits and things that you should do in a Web3 system. But again, all of these exploits that we're seeing are classic Web2 OPSEC kind of risk exploits. And there are systems like PagerDuty, but also CrowdStrike, Palo Alto Networks, all of these very big companies that they're literally built to do and help mitigate exactly these things. So I don't know about their security posture. We'll wait for the postmortem. But my experience is that this is something that I've seen kind of less prevalent amongst Web3 teams in their understanding.

A (24:53)

Okay, so the contagion.

C (24:55)

Yeah, the contagion. Like you said, this was a top 10 hack in terms of TVL and funds loss, correct? Yep.

A (25:03)

Yeah, at least as of yesterday.

C (25:07)

As of yesterday, yeah.

A (25:08)

When I checked it yesterday.

C (25:10)

As of yesterday. And I think also every time that we check, it looks like the number in terms of funds loss is continuing to increase as more exposure is being kind of disclosed. I think this was number one in terms of discrete protocols that were affected with over 20. So I can pull up the list here. But effectively the.

A (25:30)

Yeah, you can also share it in the chat and the engineer can show it on screen.

C (25:35)

Sure, let me put it in chat. Sorry, this is the wrong one. It's actually on the Twitter thread of the Chaos Labs. So if you want to pull it up. We just published an article that reviews everyone who was affected by this. I'll drop the link in the chat.

A (26:02)

Okay,

C (26:06)

there we go. Now we can talk about the contagion itself. So roughly, you can break it down into three categories of applications that were affected, hit by it, and as a result have lost kind of user deposits in one way or another. The first is the vaults. So Drift started as a pure perp, Dex. They've expanded the product to offer the Drift vaults effectively and a bunch of curators have created their own vaults on top. So there's a curator called Prime Number that had over 10 million deposited into drift via their vault at the time of exploit. Gauntlet had, I think 6.4 million. Nitrade was over 3 million as well. So this is kind of the first, and this is a direct parallel to kind of Morpho and usr. The second is Borrow Lend integrations. So there are protocols like Pyra that use Drift Drift integration in their application to offer the full borrowing and lending stack. So here their application was compromised via dependency on Drift as well. The third is all of the emergence of these new yield products. So you have products like Reflect Money, Trade Neutral, Elemental that have all integrated Drift as their source for generating yield on behalf of their users. So I think now we've touched on nearly 10. There are another 10 that fall into the kind of these different buckets. But again here, by the time that all these teams understood what was happening due to the lack of kind of monitoring and alerting infrastructure, it was already too late.

A (27:50)

Wow. So let's now talk about the other kind of drama that was unfolding while this was going on, which is of course now the hackers have almost $300 million and they start moving it, you know, with the intention probably of laundering it and cashing out. So the community was incensed, to say the least, that Circle did nothing to stop the hackers. Zach XBT tweeted, and here he noted that they were using Circle's cross chain transfer protocol, or CCTP to move the money. And he said, quote, six hours is how long Circle had to freeze stolen funds from the 280 million plus dollar drift hack. Why does our industry allow them to stay silent? And he even tagged the CEO, Jeremy Hilaire. He tagged Circle, he tagged usdc. So why do you think Circle did nothing and generally does not do anything in these types of situations?

C (28:52)

Yeah, I saw that tweet as well, and it's a good question. I don't think that, or at least I haven't seen Circle fully publish what their exact position is on these things. What I do think and what I've seen based on their actions historically is that they're kind of reluctant to act when there's no unilateral legal cover, where it's not coming from something that's mandated by the court and it's upsetting. But on the other hand, I think the counterpoint to that is it sets a precedent. And this one was, it seemed more clear cut than ones that we've seen previously. But there are other instances perhaps where it's less clear. And then what is Circle's role? Should Circle be monitoring for all hacks? I think some people would say that at their scale, there's legitimacy to that point, but others would say that it's not their role.

A (29:44)

Okay, interesting. Well, so do you have an opinion on what would be a better way for Circle to, to tackle these types of incidents?

C (29:56)

I think it's not, it's not binary, it's not clear cut in the sense that, look, Circle today does have the, and they have historically blacklisted addresses. For addresses that are blacklisted, I think many of the bridges will not allow for transferring those funds. But again, those blacklists are usually derived from some like, legal process or some Kind of very clear instruction they get from a different law enforcement agency. So I don't know who spoke to Circle. I don't know if anyone was able to reach them during the time of the attack. I don't know what information was available. And maybe in the postmortem that will become more clear. But, yeah, I mean, if everything was clear, which it wasn't in the hours leading up to the hack, at least not to us, but perhaps there was different information available to internal parties that. That is something that could have stopped the funds from reaching Ethereum and later being mixed. But it looked like the attacker was actually pretty confident that they wouldn't freeze because he moved into USCC and then used the CCTP protocol. So they. They may have kind of made the bet that it wouldn't be frozen without any of the requirements that we said earlier from a law enforcement agency perspective.

A (31:19)

Yeah, yeah. And I think, like, the. The urge to potentially freeze with imperfect information isn't necessarily a bad one, considering what I'm going to ask you about next, which is that many people observe that different elements of this attack resembled the Bybit hack. And as most people should know, that was executed by North Korea. I know nothing's confirmed yet, but, you know, I saw like, for instance. For instance, divergesec tweeted about, like, multiple different parallels they saw, you know, when comparing this to previous hacks by Lazarus. So, like, you know, when you look at it, do you also think that there are certain, kind of like, there's a certain fingerprint to this hack that leads you to believe it could be North Korea?

C (32:20)

Yes. So, I mean, there's a lot of documented attacks that have been attributed to them, and we've seen some of the techniques they've used. Certainly, like, again, this wasn't a random dev that kind of stumbled upon these keys and decided that they would give it a go. This was very methodical. The similarities between this and Bybit, for me are that it was a different kind of form factor and attack vector, but deceptive key signing. So in Bybit, I think they even manipulated the UI on the machines that were signing and the signers were actually signing something that they thought was legitimate, although it was the transaction which transferred the funds to the rogue wallets. That's where it's similar. But the difference here is it took it one step further. They didn't just sit on a transfer transaction, they literally controlled the protocol in that moment. So there were a few more steps involved. Again, touching on the oracle, touching on the fake token that was created in the volumes that were run in that pool. Another layer of sophistication.

A (33:23)

Yeah. Yeah. So what would need to happen for the community, or I don't know who it is that kind of makes a judgment on these things, but what needs to happen for there to be a level of confidence in saying who the hacker was?

C (33:41)

I think right now, what most of the security teams that are in the Drift team itself and whoever they're working with in an attempt to recover the funds are doing are tracing the funds. They're probably seeing if it's associated with addresses that have either been blacklisted or suspected of being tied to the North Korean regime. So there are many ways to kind of. It's yet to be seen, like how they're going to kind of get the funds off chain, like ultimately like this is. Or if they need to. So I think these are the things that are going to happen. Now, I don't. I don't recall DPRK claiming direct responsibility for any of these, but there. There are telltale signs the techniques are. It could be a copycat, but this is like the MO of some of the attacks they've been more successful with.

A (34:34)

Okay, so last question here is potentially a little controversial. I saw Hayden Adams of Uniswap tweeted, quote, people might accuse me of grave dancing for saying it, but we have to stop letting centralized things call themselves DeFi. Admin key can drain all funds. Otherwise DEFI means nothing and its brand is destroyed. No admin key can drain any version of Uniswap for any reason. So there's that view. And then I'm going to ask you about one other one that was kind of on the flip side. Hasu tweeted Every DeFi protocol should have number one circuit breakers for deposit withdrawals and possibly other internal operations as well. Time locks for any change, which you mentioned. Third, security councils that can shut down protocols immediately. And then he said, we don't need insurance. We need to start doing the fucking basics correctly. It's too early for this space to drive without any training wheels. I beg you, sacrifice a tiny bit of UX to gain a lot of peace of mind. The worst possible UX is losing your user's money. So, yeah, what do you think of those two tweets side by side?

C (35:46)

I think they're both fair. Right. And I'll start with Hasu. Like the. The Security Council, the time locks, all the things that we discussed today. These exist in a lot of applications. I was formerly on the Arbitrum Security Council Layer zero has a security Council. AAVE has the risk contributors led by us and other contributors that need to sign on. Sensitive transactions as well. So these things do exist. It's not that they don't. And certainly it could have stopped what we saw yesterday. So it adds friction. I think it's a decision that the teams kind of like need to make. I think it's definitely the right decision and that's number one. Number two for what Hayden was speaking of. Look, this is drift by no stretch of the imagination. Even like Hyperliquid and some of the other per dexes, there are areas in the system that are more centralized than not right. And I think every team like when you're building, it's not that you're either DeFi or pure CFI. There's a spectrum that you sit on. And I think teams make decisions based on the product that they want to go to market with and the customers and users they want to cater towards. So I don't think there's anything like wrong with that. But if you are making those decisions, they need to be disclosed, you need to do them responsibly and you need to architect the system, do the risk audits, do the security audits such that you're doing everything in your power to prevent what we saw yesterday. And users can, if those things are disclosed properly, they can decide do they want to be in a system that's laws, code, it's 500 lines of code and what you see is what you get, or do you want to be in a system that has a better UX and is in the happy path, more accessible to users.

A (37:39)

All right, well, Omera, this has been super fun. Well, fun is maybe not the word. It's a sad day, but it's been really interesting learning how this all went down. Thank you so much for sharing your insight on Unchained.

C (37:54)

Thank you Laura for having me and

A (37:57)

thanks everyone to join this live stream. We will catch you tomorrow.

C (38:01)

Bye, Sam.