Article
10 min read time
Drift Protocol on Solana - Compromised, 250M$ Stolen.
Statement from Drift:
Earlier today, a malicious actor gained unauthorized access to Drift Protocol through a novel attack involving durable nonces, resulting in a rapid takeover of Drift’s Security Council administrative powers.
This was a highly sophisticated operation that appears to have involved multi-week preparation and staged execution, including the use of durable nonce accounts to pre-sign transactions that delayed execution.
Recently, our team at Utila has added extended support for Durable Nonce transactions - so we are pretty familiar with the “The Good, the bad and the ugly” mechanics with that type of transactions.
After reviewing the compromise, in essence, this again (!) is just a “blind signing” attack, with a one-for-one resemblance to the Bybit hack one year ago. The Durable Nonce part? This is just the vehicle - or, if you will, the rocket booster (you will soon see why).
A quick recap of the Bybit hack to show the remarkable resemblance.
Bybit’s treasury, secured by a multi-sig account (Gnosis Safe), on Ethereum - hacked ($1.4B) by compromising the Gnosis Safe UI, delivering an obfuscated payload instead of a legitimate transaction to signers - the transaction looked like a regular transfer, but was in fact reassigning the ownership of the entire Safe to the attacker. This was amplified by the use of an “advanced feature” of the Gnosis Safe. The use of this advanced feature probably went unnoticed by the signers, most likely because the wallet software did not emphasize it.
Now, Drift’s treasury, secured by a multi-sig account (Squads), on Solana - hacked by making 2 out of the 5 Squads admins sign a transaction that reassigned the ownership of the entire Squads mutil-sig to the attacker. This was amplified by the use of an “advanced feature” of Solana - Durable Nonces. And again, the use of this advanced feature probably went unnoticed by the signers, again - most likely because the wallet software did not emphasize its usage.
Before I go in depth to explain the booster rocket stage of the Durable Nonces and how some architectural design of this feature played a crucial part in the exploit, I would just like to bring attention to the fact that wallet software should do more and invest more in the display of the transactions being signed. If you can’t read the “fine print” of the transaction payload you are signing - might as well just sign with your eyes closed.
Durable Nonce Booster Stage Explained
A history lesson
Before jumping straight into Durable Nonces, let’s talk a bit about Solana transactions.
In Solana, to avoid replay attacks, every transaction must specify a recent block hash (recentBlockhash). When the signed transaction is submitted, Solana checks whether the recentBlockhash is the block hash of the last 150 blocks in the chain. If yes - it is considered valid; otherwise - invalid, and the transaction can never be submitted.
How does this avoid a replay attack? because Solana will keep track of all the transactions in the last 150 blocks and will not allow duplicate transactions, so while the transaction is still valid, it can not be replayed, and after 150 blocks - its already invalid.
Why not just check for a duplicate transaction in the entire history of the chain and avoid the whole recentBlockhash mechanism? Because Solana does not actually keep the entire history of the chain. Solana is a very fast blockchain, to support that speed, the Solana blockchain must be very lean and efficient - keeping the entire history of the executed transaction in memory to avoid replay attacks is not feasible - the recentBlockhash mechanic is a pretty good choice.
The only problem is, 150 blocks in Solana are passing in just 1-2 minutes - this effectively means that after signing, you have a minute to submit the transaction to the chain - otherwise you have to sign again, with a new recentBlockhash.
In Utila, where we allow carefully reviewing and approving transactions by multiple principals - this would be a huge limitation, how can you approve something by multiple people if you only have one minute. To overcome that challenge, Utila only assigns the recentBlockhash after all approvals were made, and just before the signature - this in fact gives unlimited time to approve the transaction.
However, not all is solved by this approach:
Some complex transactions, usually dApp-originated, do not allow Utila (or any wallet) to change the initially provided
recentBlockhash- effectively reverting to the 1-2 minute approval flow.It would be beneficial for customers to able to pre-sign transaction, for later broadcast - Think of an “emergency protocol exit” transaction, signed in advance, broadcasted on protocol compromise (Utila actually has such kind of integration with Hypernative)
For the first class of limitations, there is not much to do, at least until the wider Solana dApp ecosystem will take a better approach at transaction approval limits (and allow wallets to change the contents of the supplied transaction).
For the second class of limitations - Enter Solana Durable Nonces (official documentation: https://solana.com/developers/guides/advanced/introduction-to-durable-nonces).
So the Solana team actually saw this limitation and came up with a solution - the solution followed a simple guideline - do not change the transaction format and try to use existing fields of the transaction to not introduce new compatibility requirements on wallets:
Deploy a program on Solana (Durable Nonce account). That program will store a “durable nonce” - which is also a hash, similar to the recentBlockhash. When it is created, it has a unique value.
Now instead of specifying a recentBlockhash - you specify the durable nonce of that account - in the same recentBlockhash field.
So wait, how does that even work? How does Solana know we are using a durable nonce instead of a recentBlockhash, and which nonce account? How does permissions work? How replay protection is achieved?
As said, the implementation the Solana team has chosen was to not change the transaction format - so the only way to do so, was to use the existing transaction instructions list.
A durable nonce transaction, will have the advanceNonce instruction as the first instruction. This instruction will specify the nonce account address. So when Solana sees this instruction - it immediately goes into “Durable Nonce” mode.
A durable nonce account can be created by anyone - but during its creation you can assign an owner, which is the only account that can use the durable nonce account from that point - this solves the problem of permissions - not allowing someone else using your durable nonce account which is just a public program on Solana - visible for all.
The replay protection is achieved by the fact that Solana checks before executing the transaction that the content of the durable nonce account is indeed the same as the hash supplied in the reused recentBlockhash and if so, the transaction is executed and the content of the durable nonce is updated to a new nonce - which blocks the replay of the same transaction. Since the nonce has been updated - this allows new transactions to reuse the same nonce account instead of deploying a new one for each durable transaction.
This how Solana achieved adding support in a long sought feature, without changing the transaction format - existing wallets can just sign transactions that use Durable Nonces.
This design was slick and simple, but it almost broke Solana for good.
Now with the introduction of Durable Nonces in Solana, it was possible to steal any asset on the Solana blockchain.
Because of the design to reuse existing fields (recentBlockhash, instructions) and because of the need to support replay protection.
The Solana team decided that if a Durable Nonce transaction fails during execution, the durable nonce account must still advance. Because it is modeled as an instruction (advnaceNonce), they mistakenly implemented it as “If reverted and durable nonce, keep all changes the transaction has made” - this, of course, is epically incorrect - it means that if you would craft Durable Nonce transaction with the following instructions “advanceNonce + Send $1M from anyone to attacker”, the transaction would obviously revert, because the attacker does not have permission to any one - but the advanceNonce instruction would cancel the revert - effectively keeping the changes!
Luckily, this vulnerability was discovered before all hell broke loose, and was promptly fixed. (source: https://neodyme.io/de/blog/nonce-upon-a-time)
This was the first victim of the complexity of reusing existing fields.
The Drift Attack
Now, lets piece it all together into the second victim - Drift.
As explained above the attacker had to compromise 2 signers (out of 5) and execute a blind signing attack on them that will change the ownership of the Squads multi-sig program.
But there's a risk: If one signer executes the transaction against the Squads program - all other 4 signers and perhaps other security tools can inspect the transaction on chain, and alert that something fishy is going on.
To de-risk, the attacker chose to compromise two accounts and submit both transactions - at the same time.
That could be tricky, since it means compromising both signers at the same time.
But what if the attacker can just make each signer sign - and not broadcast the transactions, and only after he has both signatures - broadcast them together? Possible - but because these transaction expire in 150 blocks (1-2 minutes) it becomes very infeasible, unless…
You use durable nonces.
However, with durable nonces you must first create a Durable Nonce account - this means that both compromised signers, will not only have to sign the compromised transaction that changed the ownership of the Squads program, but also to deploy a durable nonce account - that’s 2 transactions instead of 1 by each compromised signer and again, this may raise the suspicion of the Squad owners: "Why would one or two of the owners start using a durable nonce account?"
But wait! Let us remember the design decision of the Durable Nonce account creation - anyone can create a durable nonce account and then reassign its ownership to you! And this is exactly what the attacker has done: https://solscan.io/tx/59yWWZjnLeu3WP6Dqj4NW21NWHhdNwkToCbypdNrAHKmhk5C37ZDUygbuDVPSN2XqYzME88k6Ss3sBKGdrmrWrX3
And this is how booster phase has been executed:
A day before the hack took place, the attacker created durable nonce accounts for both victims.
Then made them sign some transaction which was never executed - no one except those signers ever experienced anything weird.
Those signers did not understand that they were signing a Squads account ownership transfer transaction - so obviously they didn’t understand they were also using a durable nonce account (most if not all wallets don’t even show it specially in their UX).
After getting both signatures - it was game over.
How could have this been prevented
This hack was very well thought-out, also technologically, but mainly the amount of de-risking to execute it perfectly.
To prevent hacks like this, usually there is no band-aid solution but here are some mitigations that could have helped:
Drift used a 2-out-of-5 Squads account with no timelock. Increasing the requirement threshold to 3, or employing a 24 hour timelock could have saved the day.
Signers that posses great power should understand exactly what they are signing.
Sometimes this is hard - because if the transaction is Squads dApp originated - you only have 1 minute to approve
This means wallet to dApp interactions in Solana should be improved to allow extending
recentBlockhash- such that signers have more time to read what they are signing, today everyone that does complex DeFi in Solana - puts too much trust in the transaction construction logic of the dApp, which can be easily compromised.
Wallets should improve UX around Durable Nonces - The wallet should warn the signer that the transaction they are signing will be valid for much more than the “regular” 1-minutes,
Blockchain Security companies should start tracking the creation of Durable Nonce accounts on their client’s wallets. There could be many false positives - but this would have at least given a day in advance warning to Drift’s team.
Stay safe out there!
Explore more
Subscribe
Subscribe
for Utila news and insights
Thought leadership, product updates, and partnerships - delivered only when we have something interesting to share.
See how Utila fits into your stack.
Live walkthrough, no commitment.
Companies who trust our enterprise-grade governance, security, and operational control: