BTC$66,600.00 +0.91%
ETH$2,020.35 -1.24%
SOL$83.31 -2.15%
BNB$616.18 +0.43%
XRP$1.35 -0.87%
ADA$0.26 -1.52%
DOGE$0.0909 +0.91%
AVAX$9.12 -5.55%
BTC$66,600.00 +0.91%
ETH$2,020.35 -1.24%
SOL$83.31 -2.15%
BNB$616.18 +0.43%
XRP$1.35 -0.87%
ADA$0.26 -1.52%
DOGE$0.0909 +0.91%
AVAX$9.12 -5.55%
BTC$66,600.00 +0.91%
ETH$2,020.35 -1.24%
SOL$83.31 -2.15%
BNB$616.18 +0.43%
XRP$1.35 -0.87%
ADA$0.26 -1.52%
DOGE$0.0909 +0.91%
AVAX$9.12 -5.55%
BTC$66,600.00 +0.91%
ETH$2,020.35 -1.24%
SOL$83.31 -2.15%
BNB$616.18 +0.43%
XRP$1.35 -0.87%
ADA$0.26 -1.52%
DOGE$0.0909 +0.91%
AVAX$9.12 -5.55%
analysis2023/05/23· 5 min

SharkTeam: Analysis of Tornado.Cash Proposal Attack Mechanism

鸵鸟

鸵鸟区块链

Original source

On May 20, 2023 (Beijing time), Tornado.Cash suffered a proposal attack, with the attacker profiting approximately $680,000. SharkTeam conducted an immediate technical analysis of this incident and summarized security prevention measures, hoping future projects can learn from this case to build stronger security defenses for the blockchain industry.

## I. Event Analysis

**Attacker Addresses:**

- 0x092123663804f8801b9b086b03B98D706f77bD59

- 0x592340957eBC9e4Afb0E9Af221d06fDDDF789de9

**Attack Contracts:**

- 0xAF54612427d97489707332efe0b6290F129DbAcb

- 0x03ecf0d22f9ccd21144a7d492cf63b471916497a

- 0x7dc86183274b28e9f1a100a0152dac975361353d (deployment contract)

- 0xc503893b3e3c0c6b909222b45f2a3a259a52752d (fake proposal contract)

**Victim Contract:**

- 0x5efda50f22d34F262c29268506C5Fa42cB56A1Ce

**Proposal Submission Transaction:**

- 0x34605f1d6463a48b818157f7b26d040f8dd329273702a0618e9e74fe350e6e0d

**Attack Transaction:**

- 0x3274b6090685b842aca80b304a4dcee0f61ef8b6afee10b7c7533c32fb75486d

**Attack Flow:**

(1) First, the attacker (0x59234095) submitted a proposal to the victim contract (0x5efda50f), claiming it was a supplement to proposal #16.

(2) However, the proposal actually contained an additional self-destruct function.

(3) Unfortunately, the community failed to identify the issue in this proposal, and most members voted to approve it.

(4) The attacker created multiple contracts to execute token transfers.

(5) The attacker (0x59234095) destroyed the proposal contract (0xc503893b) and the deployment contract (0x7dc86183), then redeployed the attack contract at the same address (0xc503893b).

(6) After modifying the proposal contract, the attacker (0x59234095) executed the proposal and modified the locked token amounts for all controlled contract addresses to 10,000.

(7) After proposal execution, the attacker (0x09212366) transferred tokens to their own address and gained ownership of the victim contract.

**Vulnerability Analysis:**

The deployment contract (0x7dc86183) was deployed using CREATE2, while the fake proposal contract (0xc503893b) was deployed using CREATE. After both contracts were destroyed, since the deployment contract's (0x7dc86183) bytecode remained unchanged, redeploying with CREATE2 could deploy to the same address (0x7dc86183). The attack contract used the CREATE opcode for deployment. After the deployment contract (0x7dc86183) was destroyed, the nonce reset to its initial value, allowing the attack contract to deploy to the same address (0xc503893b) even with modified code. Since proposal execution uses delegatecall, the attack contract could arbitrarily modify values in the victim contract.

**Event Summary:**

This incident occurred because the community failed to identify risks in the proposal during review and did not thoroughly verify whether the proposal contract code contained security vulnerabilities.

## II. Security Recommendations

Based on this attack incident, we should follow these precautions during development:

(1) When designing proposal mechanisms, fully consider security and minimize the risk of centralized control. Consider combining approaches such as reducing attack value, increasing the cost of obtaining voting rights, and increasing attack execution costs.

(2) Before voting on proposals, the community should carefully examine contract code for backdoors.

(3) Before proposal approval, consider engaging third-party security audit firms to conduct security audits of contract logic code.

## About Us

SharkTeam's vision is to comprehensively protect the security of the Web3 world. The team consists of experienced security professionals and senior researchers from around the world, proficient in blockchain and smart contract fundamentals, providing services including smart contract audits, on-chain analysis, and emergency response. We have established long-term partnerships with key participants across various sectors of the blockchain ecosystem, including Polkadot, Moonbeam, Polygon, OKC, Huobi Global, imToken, and ChainIDE.

**Website:** https://www.sharkteam.org

**Twitter:** https://twitter.com/sharkteamorg

**Discord:** https://discord.gg/jGH9xXCjDZ

**Telegram:** https://t.me/sharkteamorg

tuoniaox.com content has been migrated to hashspring.com with editorial authorization. Future publishing will continue on hashspring.com.
Share:𝕏TG