On May 20, 2023, Tornado.Cash experienced a proposal attack, resulting in the attacker profiting approximately $680,000.
SharkTeam conducted a technical analysis of the incident and summarized security measures to serve as a lesson for future projects, aiming to strengthen the security defenses in the blockchain industry.
1. Incident Analysis
Attacker Addresses:
· 0x092123663804f8801b9b086b03B98D706f77bD59
· 0x592340957eBC9e4Afb0E9Af221d06fDDDF789de9
Attacking Contracts:
· 0xAF54612427d97489707332efe0b6290F129DbAcb
· 0x03ecf0d22f9ccd21144a7d492cf63b471916497a
· 0x7dc86183274b28e9f1a100a0152dac975361353d(deployed contract)
· 0xc503893b3e3c0c6b909222b45f2a3a259a52752d (fake proposal contract)
Targeted Contract:
· 0x5efda50f22d34F262c29268506C5Fa42cB56A1Ce
Proposal Transaction:
· 0x34605f1d6463a48b818157f7b26d040f8dd329273702a0618e9e74fe350e6e0d
Attack Transaction:
· 0x3274b6090685b842aca80b304a4dcee0f61ef8b6afee10b7c7533c32fb75486d
Attack Process:
(1) The attacker (0x59234095） initiated a proposal to the targeted contract (0x5efda50f) and claimed that it was a supplement to Proposal 16.
(2) However, the proposal actually contained an additional self-destruct function.
(3) Unfortunately, the community did not identify the issue within the proposal, and most members voted in favor of it.
(4) The attacker created multiple contracts to execute token transfers.
(5) The attacker (0x59234095) destroyed the proposal contract (0xc503893b) and its creating contract (0x7dc86183). Subsequently, the attacker redeployed the attack contract (0xc503893b) at the same address.
(6) After modifying the proposal contract, the attacker (0x59234095) executed the proposal and changed the locked token balance of the contracts they controlled to 10,000.
(7) Once the proposal execution was complete, the attacker (0x09212366) transferred the tokens to their own address, gaining ownership of the targeted contract.
Vulnerability Analysis:
Since the deployment contract (0x7dc86183) is deployed through create2, the fake proposal contract (0xc503893b) is deployed through create. After the two contracts are destroyed, because the bytecode of the deployment contract (0x7dc86183) has not changed, so reusing create2 deployment can be deployed to the same address, which is 0x7dc86183, and the attack contract is deployed using the create opcode, in the deployment contract ( 0x7dc86183) is destroyed, the nonce restores the initial value, so that the attack contract can be deployed to the same address 0xc503893b even when the contract is modified. And the execution of the proposal is called in the form of delegatecall, and the attacking contract can arbitrarily modify the value in the attacked contract.
Summary of the Incident:
The root cause of this incident was the community’s failure to identify the risks within the proposal and to thoroughly verify the security of the proposal contract’s code.
2. Security Recommendations
In response to the recent attack incident, it is important to follow the following guidelines during the development process:
1. When designing proposals, fully consider the security of the proposal mechanism and strive to minimize the risk of centralized control. Practical measures such as reducing the value of potential attacks, increasing the cost of acquiring voting rights, and raising the cost of executing an attack should be taken into account to ensure a well-designed proposal mechanism.
2. Before voting on a proposal, the community should carefully review the contract code for any potential backdoors or security vulnerabilities.
3. Prior to proposal approval, it is advisable to engage a third-party security audit firm to conduct a thorough security audit of the contract logic code.