<aside> 💡 Attacker(s) minted 120k Wormhole ETH on Solana “The attacker made it look like the guardians (validators) had signed off on a 120k deposit into Wormhole on Solana, even though they hadn't. All the attacker needed to do now was to make their "play" money real by withdrawing it back to Ethereum.”
</aside>
120,000 ETH (~323 Million dollars) was stolen from Wormhole.
Wormhole is a "bridge" -- basically a way to move crypto assets between different blockchains. Specifically, Wormhole has a set of "guardians" that sign off on transfers between chains.
—Wormhole Tried To Negotiate a Bounty—
After the attack, Wormhole reached out via a message in a transaction asking if the attacker would accept a $10 million bounty.
To carry out the attack, the attacker managed to forge a valid signature for a transaction that allowed them to freely mint 120,000 wETH
—Code was patched right before attack—-
Open-source code commits show that code that would have fixed this vulnerability was written as early as January 13th and uploaded to the Wormhole GitHub repository on the day of the attack. Just hours later, the vulnerability was exploited by the hacker, suggesting that the updates had not yet been applied to the production application.
The code upload was described as if it were a run-of-the-mill version update but actually contained extensive changes — a fact that could have tipped off the attacker to the fact that it was a disguised security fix.
— Kevin Feltcher Analysis—
The transactions that minted Wormhole ETH on Solana were triggering this Wormhole function "complete_wrapped”
One of the parameters that this function takes is a "transfer message", basically a message signed by the guardians that says which token to mint and how much
This "transfer message" contract is created by triggering a function called "post_vaa”
post_vaa checks if the message is valid by checking the signatures from the guardians.
post_vaa" doesn't actually check the signatures. Instead, there's another smart contract which gets created by calling the "verify_signatures" function.
One of the inputs to the "verify_signatures" function is a Solana built-in "system" program which contains various utilities the contract can use
Within "verify_signatures", the Wormhole program attempts to check that the thing that happened right before this function was triggered was that the Secp256k1 signature verification function was executed
This verification function is a built-in tool that's supposed to verify that the given signatures are correct. So the signature verification has been outsourced to this program.
The Wormhole contracts used the function load_instruction_at to check that the Secp256k1 function was called first
The load_instruction_at function was deprecated relatively recently because it does not check that it's executing against the actual system address!
Using this "fake" system program, the attacker could effectively lie about the fact that the signature check program was executed. The signatures weren't being checked at all
After that point, it was game over. The attacker made it look like the guardians had signed off on a 120k deposit into Wormhole on Solana, even though they hadn't. All the attacker needed to do now was to make their "play" money real by withdrawing it back to Ethereum
—Jump Replenishes Wormhole Funds—
The parent company for Wormhole stepped in to backstop funds. Jump Trading is responsible for replenishing the lost ETH
