Unfolding the Wormhole Exploit

TL;DR#

On February 3, 2022, Wormhole was exploited for 120,000 ETH, worth approximately $326 million, making it one of the top 5 largest cryptocurrency heists of all time.

Vulnerability Assessment#

The root cause of the vulnerability is a lack of proper validation of all input accounts, allowing the attacker to exploit it by spoofing the guardian signature and minting 120,000 ETH on Solana.

The Exploit#

Step 1:

We attempted to analyze the attack transaction executed by the exploiter.

Step 2:

The attacker called the `complete_wrapped` function of the contract, which requires a valid VAA account, which the bridge would accept. This requirement was satisfied when the attacker called the `post_vaa` function on the main Wormhole bridge as viewed from this transaction.

Step 3:

The attacker managed to bypass the signature checks that the "post_vaa` function performs by providing a `SignatureSet`, which ultimately called the `verify_signatures` function on the main bridge.

Step 4:

The `verify_signatures` function is meant to take a set of signatures provided by the guardians and pack it into a `SignatureSet`. However, it doesn't perform actual verification by itself but delegates that operation to the Secp256k1 program.

Step 5:

A `solana_program::sysvar::instructions` mod is meant to be used with a sort of precompile on Solana. However, the version of `solana_program` on Wormhole didn't verify the address being used.

Step 6:

This means that anyone could create an account that stored the same data that the instructions `sysvar` would have stored and substitute that account for the instruction `sysvar` in the call to `verify_signatures` in order to effectively bypass the entire signature validation.

Step 7:

The attacker created their account prior to conducting the attack, which contained a single serialized instruction corresponding to a call to the Secp256k1 contract.

Step 8:

The fake `SignatureSet` allowed them to generate a valid VAA and trigger an unauthorized mint of 120,000 ETH to their own account.

Step 9:

Out of the stolen funds, 93,750 ETH were bridged back to Ethereum over the course of 3 transactions, while the remaining assets worth approximately 36k whETH were liquidated on Solana into USDC and SOL.

Aftermath#

Following the exploit, an on-chain message was sent to the hacker by the team behind Wormhole Bridge, offering them a white-hat bounty of $10 million for returning the stolen funds.

Jump Crypto, a wing of Jump Trading involved in the development of the Wormhole protocol, tweeted that they replaced the 120k ETH to make community members whole and support Wormhole.

On February 16, 2023, the team was made aware of the possibility of the retrieval of the stolen assets after a group of white-hat hackers reached out to them with a proof of concept for the possible recovery.

The counter-exploit was successful mostly because the access design of the admin multisig had a flaw that no one had noticed earlier. According to the team, the design pattern was adopted solely to protect user assets in the event of a prospective attack, such as the referenced exploit, and would have allowed the team to respond quickly to patch any such vulnerability.

The Counter Exploit#

The Oasis team announced in a blog post on February 21, 2023, that they had been given permission by the High Court of England and Wales to pursue all required actions to recover the assets linked to the wallet address used in the Wormhole Exploit.

Jump Crypto, with the support of the Oasis team, was able to successfully counter-exploit the Wormhole exploiter by utilizing an upgradeable proxy contract on the Oasis protocol to secure approximately $140 million worth of the earlier stolen funds.

The exploiter had continuously shuffled the stolen funds through various dApps on Ethereum and held funds in two of the Oasis vaults: a wstETH vault opened on January 23, 2023, and a rETH vault opened on February 11, 2023. Both of these vaults used the automation services offered by Oasis.

In between the aforementioned time frames, the exploiter used these vaults to borrow DAI and long ETH staking derivatives and drew a total of $78 million worth of DAI debt against $220 million worth of collateral.

The wstETH vault, ID: 30100, held $219 million in wstET, while the other rETH vault, ID: 30179, held $6 million in rETH. The counter-exploit used was able to recover all of the funds from both of these vaults.

Following are the details of the wallets involved in the counter-exploit:

• Oasis Multisig: A 4 of 12 multisig that owns the Oasis proxy contracts
• Holder: Address that held the recovered funds
• Sender: Address responsible for executing the counter exploit
• Jump1: Address labeled as Wormhole Deployer 1 that funded the `Sender` with DAI to repay the debt and recover the collateral
• Jump2: Address labeled as Jump Trading that received the leftover DAI from the `Sender`

What Had Happened?#

The Exploiter added a stop-loss trigger to vault 30100, 9 minutes after opening the vault. This instantly led to a backdoor for the counter-exploit to be successful.

The AutomationBot contract is given access to the vault when a user adds an automation trigger to an Oasis vault, enabling it to purchase collateral or take on debt if and when the trigger is hit.

The first automated transaction was triggered on February 13, in which the vault owner took no additional action, while 14.41 million DAI debt and 7,547 wstETH collateral were automatically added to the vault.

The Automated vaults need the ability to act on behalf of the user. However, the Oasis automation contracts use an upgradeable proxy pattern, meaning the contract logic can be changed by the contract owner at any time. The owner of the Oasis automation contracts was a 4 of 12 Gnosis Safe, which we earlier referred to as Oasis Multisig.

The Holder made its first transaction on February 20, one day before the event of the counter-exploit.

On February 21, the Sender was added as an eligible signer to the Oasis Multisig for a total of 1 hour and 53 minutes. The Sender executed five transactions to facilitate the counter exploit, but was subsequently removed as a signer from the Oasis Multisig after the counter-exploit was successfully executed.

Each of these five transactions by the Sender played a key role in the counter-exploit, but the major recovery took place with the third transaction. In this transaction, the Sender upgraded the automation contract to a new proxy that allowed the Sender to move the collateral and debt from the vault with ID 30100 out of the exploiter's control.

A few of the below parameters enabled the counter-exploit to become successful:

1. The Sender first updated the change delay to 0 with the ServiceRegistry using its privileges on the MultiSig, allowing them to instantly upgrade the proxy contract address.
2. The Sender deployed two new contracts; let's refer to them as Authorizer, and Executor. These contracts tricked the protocol into acting as the Sender’s commands.
3. The Sender updated the Oasis ServiceRegistry to call the Authorizer and Executor contracts in place of two key Oasis contracts with the ability to bypass the time delay.
4. The AutomationExecutor proxy address was updated to Oasis Multisig, giving the Sender complete control of the vault with ID 30100.

In order for the counter-exploit to become successful, the Sender must close the vault with ID 30100 and migrate its position to a new vault that is controlled by the Multisig.

1. The Oasis Multisig is called in place of the AutomationExecutor, granting them full control of the vault with ID 30100.
2. The Authorizer is called, which tricks the protocol into thinking that the vault with ID 30100 can legally be closed by the Sender. The Authorizer successfully got the Sender past the verification steps.
3. The Executor is called to create a new vault with ID 30231, migrate the collateral and debt from 30100 to 30231, and transfer ownership of the vault with ID 30231 to the Oasis Multisig.
4. The result moved approximately 120,695.43 worth of wstETH collateral and 76.39 million of borrowed DAI from vault with ID 30100 to vault with ID 30231.
5. The Authorizer called again to verify that the vault with ID 30100 was closed, and finally the Sender restored the proxy contracts back to their original addresses.

The exploiter mistakenly gave access to the vault with ID 30100 to an upgradeable proxy contract controlled by a Multisig. The Authorizer and Executor played critical roles in the process, but the counter-exploit would not have been possible without the full control provided by upgrading the AutomationExecutor proxy. The final executions by the Sender delivered 120.7k wstETH and 3.2k rETH to the Holder.

As viewed from this transaction dated March 9, 2023, the Oasis team removed the ability to upgrade any of the contracts associated with Oasis Automation by setting the authorized address to 0x0 instead of the Oasis Multisig.

Reference Source Rekt, Blockworks