This is a story about how a simple software bug allowed the fourth-biggest cryptocurrency theft ever.
A guardian with no teeth
Bridges use wrapped tokens, which lock tokens in one blockchain into a smart contract. After a decentralized cross-chain oracle called a “guardian” certifies that the coins have been properly locked on one chain, the bridge mints or releases tokens of the same value on the other chain. Wormhole bridges the Solana blockchain with other blockchains, including those for Avalanche, Oasis, Binance Smart Chain, Ethereum, Polygon, and Terra.
The hackers pulled off the theft by using an earlier transaction to create a signatureset, which is a type of credential. With this, they created a VAA, or validator action approval, which is essentially a certificate needed for approving transactions.
“Once they had the fake ‘signatureset,’ it was trivial to use it to generate a valid VAA and trigger an unauthorized mint to their own account,” @samczsun, the Twitter handle for an employee at investment firm Paradigm, wrote. “The rest is history. tl;dr—Wormhole didn’t properly validate all input accounts, which allowed the attacker to spoof guardian signatures and mint 120,000 ETH on Solana, of which they bridged 93,750 back to Ethereum.”
tl;dr – Wormhole didn’t properly validate all input accounts, which allowed the attacker to spoof guardian signatures and mint 120,000 ETH on Solana, of which they bridged 93,750 back to Ethereum.
— samczsun (@samczsun) February 3, 2022
Another useful deepdive on the hack is here.
Statista
A nontrivial challenge
The Wormhole hack took few blockchain security experts by surprise. The challenge of writing software that interacts with multiple chains in a safe manner is nontrivial, and only a limited number of tools and techniques can test the soundness of the code.
“Building bridges inherits all the complexity of each blockchain,” Dan Guido, CEO of security firm Trail of Bits, said in a message. “They appear deceptively simple, but they’re among the most difficult code to write in reality.”
Compounding the difficulty, the new hack came shortly after a recent change was made in some of the software involved.
“The bridge didn’t expect that users could submit a signatureset, since the change to facilitate that was a recent one in the Solana runtime,” Guido explained. “By submitting their own signature data, an attacker short-circuited a signature check that allowed them to take ownership of a large amount of tokens.”
In an email, Dane Sherret, a solutions architect at bug-reporting service HackerOne, explained it this way:
There is a verify_signatures function that is supposed to take cryptographic signatures from the guardians and bundle them together. Despite its name, verify_signatures doesn’t actually verify itself—it uses the secp256k1 native program on Solana. The version of the solana-program Wormhole was using didn’t correctly verify the address, which allowed the hacker to create an account that could bypass all of the checks.
Through the above steps, the hacker was able to bypass the signature checks and pull the ETH over to Ethereum which meant that for a period of time some of the wETH [the wrapped ETH on Solana] was not actually backed by anything.
This hack is hard for me to wrap my head around because it was initiated on the Solana blockchain—which uses the Rust programming language for its smart contracts. As Ethereum uses the Solidity programming language for its smart contracts, it’s an example of how new networks, with different idiosyncrasies and different languages, are now talking to each other—which makes security all the more difficult.
Cross-chain applications pose other risks as well. In a post penned last month, Ethereum co-founder Vitalik Buterin warned that “fundamental security limits of bridges” made them vulnerable to a different class of blockchain exploit known as a 51% attack.
Also known as a majority attack, a 51% attack allows a malicious party that gains more than 50 percent of hashing power on a blockchain to reverse previously made transactions, block new transactions from being confirmed, and change the ordering of new transactions. That opens the door to something known as double spending, a hack that allows the attacker to make two or more payments with the same currency tokens. Buterin wrote:
I don’t expect these problems to show up immediately. 51% attacking even one chain is difficult and expensive. However, the more usage of cross-chain bridges and apps there is, the worse the problem becomes. No one will 51% attack Ethereum just to steal 100 Solana-WETH (or, for that matter, 51% attack Solana just to steal 100 Ethereum-WSOL). But if there’s 10 million ETH or SOL in the bridge, then the motivation to make an attack becomes much higher, and large pools may well coordinate to make the attack happen. So cross-chain activity has an anti-network effect: while there’s not much of it going on, it’s pretty safe, but the more of it is happening, the more the risks go up.
Meanwhile, demand for blockchain interoperability continues to grow, likely making the security challenges more vexing. Both Guido and Sherret advised bridge operators to take proactive steps to prevent similar hacks in the future. Such steps include completing multiple security audits and putting only limited functionality on network allowlists until developers are confident in a function’s maturity and safety.