hackhack @hackhackai - Twitter Profile

2 months ago

How do Durable Nonces work? A solana transaction basically consists of a transaction message and the signatures. The transaction message is a list of instructions you want to call. For example, transfer 1 sol from A to B. When you sign a transaction, you attach a wallet's approval to that message. In this case, you'd let A sign, approving their transfer. Without their signature, the transaction would arrive at the validator node, and then be rejected because it needs a signature from A but doesn't have it. Now, what you usually don't want is that someone signs a transaction like a transfer, sends it through the internet towards the blockchain, but the packets never reach the blockchain nodes. So you send it again, and the second try works. But a few minutes later the original transaction ends up making it to the blockchain and now you've sent the transaction twice. For this and many other reasons, we must include a recent blockhash in our transactions. When a node receives your transaction it makes sure that it includes the hash of a block that was created within the last 150 blocks, which is 60 seconds on a 0.4s slot window. now, this 60s window can theoretically be a problem when the time between getting the latest blockhash, reviewing and signing a transaction and then sending it to the current leader takes more than that. It could take more time than that if you're slow with your hardware wallet signing process, and when you take your time validating every byte before signing it manually. That's why a workaround was introduced: Durable Nonces. Basically they allow you to submit transactions that were signed a long time ago. These transactions have to include a nonce in place of the blockhash, and they need to call the advance nonce system instruction so that the validator knows that theyre using a durable nonce (and the durable nonce gets updated). Now which one is gonna be a valid nonce? Well, we can set it up by creating a nonce account, and the nonce will be derived from the latest (real) blockhash and saved in this nonce account. What's interesting is that I can create nonce accounts for others, without their approval (which makes sense as if we'd needed their approval, this means they'd have to sign a transaction within the 60s window, defeating the nonce purpose). Another interesting thing is that the attacker fucked up a little. They created the nonce accounts for the victims from the start. This could have tipped of the victims -- why is there a nonce account for me suddenly? The attacked could have instead created nonce accounts for their own wallets (which generates the durable nonce), then make the victim sign for that durable nonce, and then change the nonce account authority from themselves to the victim before executing the pre-signed transaction! That's why I think that monitoring for nonce accounts in your name is not a silver bullet. It could have been in a different name and changed to your name a second before you're drained. What also becomes evident here is that the drift team likely used hardware wallets, and the capability the attacked had was only to get them to sign a malicious transaction. They didn't compromise keys directly. Using nonces was useful for the attacked because they removed time from the equation. If no nonces existed, the attacked would have to create a malicious proposal, get victim 1 to sign it, and then get victim 2 to sign it. Time would pass between those two signatures. Minutes, hours, maybe days. Even if the victims machines are compromised and on their computers the proposal would render as harmless, this time would introduce risk to the attacker where someone else could see the proposal, figure that its malicious, and flag it. A time lock on the multisig would have helped here, as it could have introduced that same time - detection risk to the attack. But a timelock itself would not have been enough -- it would have to be made sure that someone with an uncompromised computer actually checks out the transactions during that timelock period.

0

42

7

25

4K

hackhackai retweeted

r0bre | Accretion.xyz

@r0bre

2 months ago

Re Drift Hack, part 2 So now that we've established that we have an Admin/Multisig compromise on our hands, lets investigate further and try to figure out what keys of what multisigs were compromised when. First thread can be found here:

r0bre's tweet photo. Re Drift Hack, part 2

So now that we've established that we have an
Admin/Multisig compromise on our hands, lets investigate further and try to figure out what keys of what multisigs were compromised when.

First thread can be found here: https://t.co/OQfSK5ur1s

7

65

5

28

10K

hackhackai retweeted

r0bre | Accretion.xyz

@r0bre

2 months ago

Drift has been hacked. Lots of confusing information going around. I've taken a look at what's actually happening. The core attack sequence is just 3 transactions: 1. Create a new Drift User Account: https://t.co/9B4CRorZzE 2. Deposit 500 Million "CVT" into Drift as collateral: https://t.co/Sr37jul3zB 3. Withdraw Millions of real assets against the provided collateral: https://t.co/FytexVbQ2i (and later transactions) Now, as it turns out, this CVT token was just created a few weeks ago. The core question: How did it become accepted collateral within Drift?

r0bre's tweet photo. Drift has been hacked. Lots of confusing information going around. I've taken a look at what's actually happening.

The core attack sequence is just 3 transactions:

1. Create a new Drift User Account:
https://t.co/9B4CRorZzE

2. Deposit 500 Million "CVT" into Drift as collateral:
https://t.co/Sr37jul3zB

3. Withdraw Millions of real assets against the provided collateral:
https://t.co/FytexVbQ2i (and later transactions)

Now, as it turns out, this CVT token was just created a few weeks ago. The core question: How did it become accepted collateral within Drift?

7

152

26

48

33K

hackhack

@hackhackai

Last Seen Users on Sotwe

Trends for you

Most Popular Users