Reentrancy attack + management vulnerability: analysis of 20 million OP theft incidents

On June 9, 2022, according to Optimism and cryptocurrency market maker Wintermute, 20 million Optimism tokens were stolen by hackers. On June 9th, the Optimism Foundation awarded Wintermute 20 million OP tokens.

Reentrancy attack + management vulnerability: analysis of 20 million OP theft incidents

After the transaction was sent, Wintermute found that the tokens were inaccessible because the addresses provided were their Ethereum/L1 multisig addresses that had not yet been deployed to Optimism/L2. The Optimism/L2 multi-signature address was deployed by hackers, and 2000 OP tokens were also stolen by hackers.

Reentrancy attack + management vulnerability: analysis of 20 million OP theft incidents

1. Event Analysis

On May 27th, the Optimism Foundation transferred 20 million OP tokens to Wintermute’s multi-signature contract address in two phases through a multi-signature contract, and transferred 1 OP token on the 26th. The three transactions are as follows:

Reentrancy attack + management vulnerability: analysis of 20 million OP theft incidents

According to the transaction time and the number of OP tokens in the transaction, we analyzed that on the 26th, the Optimism Foundation transferred 1 OP token to the Wintermute multi-signature contract address as a test. OP tokens are sent to the Wintermute multi-signature contract address in two consecutive transactions. The receiving address is the multi-signature contract address that Wintermute has deployed on Ethereum/L1, so Wintermute only verifies whether the token has been received, but does not verify the ownership of the address on Optimism/L2, which is not on Optimism/L2 at this time. There is no actual deployment of multi-signature contracts, which gives hackers an opportunity.

The relevant addresses in the above transfer transactions are as follows:

(1) Optimism Foundation’s multi-signature contract address on Optimism/L2:

0x2501c477d0a35545a387aa4a3eee4292a9a8b3f0 (abbreviated as 0x2501)

(2) Wintermute’s multi-signature contract address on Ethereum/L1 (Wintermute Exploiter Multisig):

0x4f3a120E72C76c22ae802D129F599BFDbc31cb81 (abbreviated as 0x4f3a)

At the same time, 0x4 f3 a on Optimism/L2 is also the address of the multi-signature contract deployed by hackers.

Next, we will analyze the hacker’s attack behavior and principles in detail from the perspective of on-chain transactions.

First, let’s look at the 0x4 f3 a contract deployment transaction on Optimism/L2:

txHash is 0x00a3da68f0f6a69cb067f09c3f7e741a01636cbc27a84c603b468f65271d415b

Reentrancy attack + management vulnerability: analysis of 20 million OP theft incidents

Note that the deployment time of the contract is June 5, and Wintermute/OP Exploiter is an address of the hacker, abbreviated as 0x60 b2.

How exactly does this transaction generate the 0x4 f3 a contract address?

The hacker replayed 3 transactions, especially the one created by the last Gnosis Safe: Proxy Factory 1.1.1 contract, as follows:

(1) Transactions on Ethereum/L1 are as follows:

Reentrancy attack + management vulnerability: analysis of 20 million OP theft incidents

(2) Transactions on Optimism/L2:

Reentrancy attack + management vulnerability: analysis of 20 million OP theft incidents

By replaying the transaction, the hacker created a Gnosis Safe: Proxy Factory 1.1.1 contract on Optimism/L2 that is identical to that on Ethereum/L1 (the address is the same as the contract code), and the function of creating the proxy contract is as follows:

Reentrancy attack + management vulnerability: analysis of 20 million OP theft incidents

Gnosis Safe: Proxy Factory 1.1.1 contracts use Solidity version 0.5, and use new to create contracts using the create command instead of create2. Use the create command to create a contract, and the contract address is calculated by msg.sender and nonce. On Ethereum/L1, the msg.sender that creates the multi-signature contract 0x4 f3 a is the address of Gnosis Safe: Proxy Factory 1.1.1. Hackers replay the transaction in Optimism/L2 to create Gnosis Safe: Proxy Factory 1.1.1 The main purpose of the contract is to ensure that the msg.sender of the contract 0x4f3 a created on Optimism/L2 is the same as on Ethereum/L1, then the hacker can easily call the createProxy function through the smart contract (contract 0 xe714) to create the address: 0x4 f3 a contract. The creation process in this transaction is as follows:

Reentrancy attack + management vulnerability: analysis of 20 million OP theft incidents

Additionally, the deployment of contract 0xe714 was completed on June 1 in the following transaction:

txHash: 0x69ee67800307ef7cb30ffa42d9f052290e81b3df6d3b7c29303007e33cd1c240

Reentrancy attack + management vulnerability: analysis of 20 million OP theft incidents

The originating transaction address is 0x8bcfe4f1358e50a1db10025d731c8b3b17f04dbb (abbreviated as 0x8bcf), which is also the address held by the hacker. At the same time, this transaction is also the first transaction initiated by 0x8bcf, and the funds come from Tornado:

Reentrancy attack + management vulnerability: analysis of 20 million OP theft incidents

The whole process in terms of time,

(1) On May 27th, the Optimism address 0x2501 transferred 20 million OP to the 0x4 f3 a address on Optimism/L2, and the 0x4 f3 a address on Ethereum/L1 was the multi-signature contract address of Wintermute, but at this time in There is no contract deployed on Optimism/L2;

(2) On June 1st, the hacker address 0x8 bcf deployed the contract 0xe714.

(3) On June 5th, the hacker created the Gnosis Safe: Proxy Factory 1.1.1 contract by replaying the transaction on Ethereum/L1 with the same address as on Ethereum/L1; then the address 0x60b2 deployed multi-signature through the contract 0xe714 The contract is 0 x4 f3 a, and the ownership of the contract belongs to the hacker, so the 20 million OP transferred in on May 27 was stolen by the hacker.

(4) On June 5, after the multi-signature contract 0x4 f3 a received 20 million OPs, it transferred 1 million OPs to the hacker address 0x60 b2, and then exchanged 1 million OPs for 720.7 Ether.

Reentrancy attack + management vulnerability: analysis of 20 million OP theft incidents

Reentrancy attack + management vulnerability: analysis of 20 million OP theft incidents

Reentrancy attack + management vulnerability: analysis of 20 million OP theft incidents

(5) On June 9, the contract 0x4f3a transferred 1 million OPs to the account address 0xd8da,

Reentrancy attack + management vulnerability: analysis of 20 million OP theft incidents

The other 18 million OPs are still in contract 0x4f3a.

Reentrancy attack + management vulnerability: analysis of 20 million OP theft incidents

2. Safety advice

The root cause of this security incident is a combination of factors such as transaction replay, vulnerabilities in the old version of Solidity, and transaction signature verification on the main chain and side chain, not because of loopholes in the contract code of the project party.

In addition, in response to this incident, the project party did not respond in a timely manner, and the contract management was not strict, etc., which also gave hackers an opportunity; from the perspective of the attack timeline and attack preparation, it is not ruled out that there is a possibility that there is collusion within the OP to commit crimes. .

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/reentrancy-attack-management-vulnerability-analysis-of-20-million-op-theft-incidents/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-06-10 11:45
Next 2022-06-10 23:47

Related articles