Latest version of @hackhackai is scary good

Implemented a new element for our website! try it out on hackhack.ai I heard the best engineers can get >100 score, not sure if this is true

@avici getting hacked today this is one of the first transactions by the attacker. solscan.io/tx/5Rxc6gQcAPpe5W… they then do the same pattern across multiple instructions of the target program (which actually is rain.xyz, not avici) what we see is two Ed25519 invocations followed by a program invocation. the double ed25519 is the smoking gun: clearly this is the attack pattern. the program that is being exploited likely has a bug in its ed25519 signature parsing. It clearly is a case of a Ed25519 cross-instruction aliasing bug. Ed25519 instruction 0 contains a valid signature under attacker-controlled key CLUci.... Instruction 1 sets all three source indices to 0, so Solana verifies instruction 0. But instruction 1’s inline public key is the privileged key 9qZpp..., and its inline signature is just repeated 0x09 bytes. Rain’s WithdrawCollateralAsset path apparently trusts that inline public key, even though it was never the key Solana verified. actually just today, before this hack we found two vulnerable programs with THE SAME BUG using @hackhackai . Maybe would have found this one too if rain was open source

We can help you with that, @hackhackai solves this

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.

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: