Tornado Cash Governance Overtaken

Notice: This page is a new case study and some aspects have not been fully researched. Some sections may be incomplete or reflect inaccuracies present in initial sources. Please check the References at the bottom for further information and perform your own additional assessment. Please feel free to contribute by adding any missing information or sources you come across. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Tornado Cash

TornadoCash fell victim to a malicious governance proposal, putting control of various aspects of the smart contract in the hands of a single address. This was accomplished through a clever "bait and switch" with a smart contract that delegated calls to another. The original smart contract was self destructed and a new smart contract was deployed to the same address. The financial damage seems minimal, and there is reports that the attacker may be reverting the damage and relinquishing control.

About Tornado Cash

TornadoCash is "[a] fully decentralized protocol for private transactions on Ethereum." that has been enhancing transaction privacy by breaking the link between source and destination addresses since it's inception in 2019. Users deposit Ether or ERC20 tokens along with a randomly generated key, and a hash of the key is submitted to the Tornado Cash smart contract. Tornado Cash initially operated on the Ethereum blockchain, supporting six tokens: ETH, DAI, cDAI, USDC, USDT, and WBTC. However, since June 2021, the protocol has expanded to other side-chains and blockchains, allowing support for new tokens and benefiting from faster and cheaper transactions on Layer-2 solutions.

Tornado Cash is a decentralized protocol designed to enhance privacy and anonymity in cryptocurrency transactions. Deposits are made to one address and withdrawals can be made from a different address, enhancing privacy. It disrupts the on-chain link between sender and recipient addresses, ensuring that transactions are private and untraceable. To maintain privacy, users are advised to wait before withdrawing. When withdrawing, users provide a proof of the valid key, and the contract transfers the funds to a specified recipient. Fixed-amount pools are available for each supported token, enabling transactions of specific fixed amounts. For example, there are four different pools for ETH, each supporting a specific amount (0.1, 1, 10, and 100 ETH). Tornado Cash utilizes a cryptographic method called MPC to destroy their admin keys, making the protocol trustless and unstoppable. Additional steps, such as using a relayer for gas payments, can further maximize privacy.

The protocol is built on the Ethereum network and is completely permissionless, meaning the developers have no control or oversight over the transactions that occur on the platform. The protocol achieves decentralization by being community-owned, with the initial developers having no control or ownership. It operates through smart contracts deployed on the Ethereum blockchain, ensuring immutability and preventing any modifications or shutdowns. The protocol is secured by zero-knowledge proofs and has undergone audits by professional audit companies. Users retain custody of their cryptocurrencies and have full control over their assets while using Tornado Cash. The user interface is hosted on IPFS and accessible as long as at least one user hosts it. Governance and mining smart contracts are deployed in a decentralized manner, and protocol parameters and token distribution are controlled by the community through governance.

Tornado Cash offers additional products such as governance participation through TORN tokens, anonymity mining, compliance tools for proving transaction history, and a trusted setup ceremony for zkSNARKs. The protocol has undergone multiple audits, ensuring its security and reliability. Relayers are also part of the system, enabling withdrawals to accounts with no balance and contributing to user anonymity. The protocol utilizes the TORN token for governance, allowing users to actively participate in shaping the future of Tornado Cash. The community has control over protocol parameters and token distribution. TORN is the native token of Tornado Cash, with a circulating supply of approximately 1.1 million coins. TORN trading began in February 2021, and it has experienced significant price fluctuations. TORN can be purchased on various centralized and decentralized exchanges.

The Tornado Cash project does not collect user data, and participants are encouraged to follow best practices to maintain their privacy. The code is open source and was accessible on GitHub. Users can prove their source of funds using the compliance tool, and the TORN contract address is provided for reference. Staking instructions and information about relayers are also available for those interested in running their own relayer.

Tornado Cash Nova

Tornado Cash introduced a new pool called Tornado Cash Nova in December 2021, which offers unique features and removes the constraint of fixed-amount transactions. This pool operates on the Gnosis Chain (formerly xDai Chain) as a Layer 2 solution, optimizing speed and cost for users. It allows for deposits and withdrawals of arbitrary amounts in ETH, providing flexibility and customization. Additionally, Tornado Cash Nova enables shielded transfers, allowing users to transfer token custody while remaining in the pool. The beta version of Tornado Cash Nova can be accessed on the Tornado Cash website, and further information on its functionality can be found in the dedicated section of their documentation.

The Reality

Concerns Over Money Laundering

The anonymity provided by Tornado Cash has raised concerns about its potential use for illicit activities such as money laundering. In August 2022, Tornado Cash was officially sanctioned by the U.S. Treasury Department due to allegations of money laundering, leading to a price drop and legal repercussions, including the arrest of a software developer associated with the project.

Controversy of Developer Payments

I hope someone can outshine the work and efforts, I undertook for this organisation. I emplore other contributors to come forward, although I do not recommend it.

What Happened

The TornadoCash governance mechanism was overtaken by a trojan horse proposal. After the community voted to pass the proposal, the contract was self destructed and replaced with a version which granted the attacker complete control over the TornadoCash governance (although governance granted them no ability to withdraw funds). The attacker eventually published a proposal to revert their control back to the community.

Key Event Timeline - Tornado Cash Governance Overtaken

Date	Event	Description
May 20th, 2023 1:25:11 AM MDT	Governance Exploit	Blockchain transaction.
May 20th, 2023 2:01:00 PM MDT	Samczsun Technical Analysis	Samczsun publishes a technical analysis of the exploit.
May 20th, 2023 4:00:00 PM MDT	Correction With Nova At Risk	"@CellierLael correctly pointed out that Tornado Cash Nova, deployed to Gnosis Chain, is a proxy that is administered by governance. Therefore, the attacker is also able to drain all of the ETH in that pool by upgrading the contract".
May 21st, 2023 3:23:00 AM MDT	BlockSec Team Analysis	The BlockSec team publishes an analysis of the attack exploit, including a slide with a diagram detailing how the attack worked.
May 21st, 2023 5:54:00 AM MDT	SlowMist Technical Analysis	SlowMist publishes a technical analysis of the exploit.
May 21st, 2023 6:43:00 AM MDT	Ameen Soleimani Warning Tweet	Twitter user Ameen Soleimani warns about the risk to funds in the Tornado Nova contract, and recommends all users to immediately withdraw. Though as he points out, it would take 7 days to execute a rug pull proposal.
May 21st, 2023 12:43:00 PM MDT	Apporv Lathey Technical Deep Dive	NTFX protocol developer Apoorv Lathey published a deep technical dive into what happened on Twitter.
May 22nd, 2023 7:18:00 AM MDT	Revert Transaction Proposed	This news is shared on Twitter.
May 23rd, 2023 8:39:00 AM MDT	Rekt Article Published	Rekt publishes an article on the situation.

Technical Details

The exploit consisted of three stages:

1. Preparing the smart contract.
2. Getting the smart contract approved through governance.
3. Switching to enable the smart contract.

Smart Contract Preparation

The address of a smart contract is generated based on a combination of two things:

• A nonce, which is incremented each time a transaction happens in the given address, such as deploying a smart contract.
• The smart contract bytecode, which represents the instructions to execute and does not include the values of any variables.

The above two inputs are hashed (passed through a one-way encryption function). As a key property of the hash, the output is predictable. So, if the first transaction on an address has a given set of bytecode, it will always get the same smart contract address.

Smart contracts can delegate functionality to other smart contracts. They can do this dynamically by invoking the call on a smart contract in a stored address. These types of calls are commonly used in decentralized finance, as they allow for future upgradeability.

As such, if the same smart contract is deployed twice by a wallet with the same nonce, it receives the same address. Even though the smart contract has the same byte code, through the powers of delegation to other smart contracts, the actual functionality can be adjusted.

Getting Approval For Smart Contract

TornadoCash was open source and used a decentralized governance mechanism. While anyone can propose a modification, community support is required. The TORN token is widely held, and there isn't a large honey-pot which is accessible from governance, so that budget of an attacker is likely to be limited. Attempting to buy a majority of tokens also requires those tokens to be available and sold in the market, and this is likely to arouse suspicion.

Instead, the attacker used clever social engineering. They gained approval for their smart contract by claiming to have used the exact same logic as in an earlier proposal. To improve their success against an open source community, they copied most aspects of the code from that contract with only minor additions. They named the new function "emergencyStop" so it would look like it had a legitimate purpose of being used in emergencies.

This was a novel attack which most developers hadn't seen before, so in this particular case no one from the community was able to come forward and warn about the risks.

The Final Bait And Switch

Exploiter Addresses:

Malicious Proposal:

Related transactions:

"In a whirlwind of events, Tornado Cash's governance has been taken hostage via a trojan horse proposal, effectively granting control of the DAO to a single address."

"On 2023/05/20 at 07:25:11 UTC, Tornado Cash governance effectively ceased to exist. Through a malicious proposal, an attacker granted themselves 1,200,000 votes. As this is more than the ~700,000 legitimate votes, they now have full control."

"when the attacker created their malicious proposal, they claimed to have used the same logic as an earlier proposal which had passed. However, that wasn't exactly the truth, because they added an extra function"

"Once the proposal was passed by voters, the attacker simply used the emergencyStop function to update the proposal logic to grant themselves the fake votes"

"a proposal contract can be updated through a well-designed trick -- create and create2."

"2/ The attack is a sophisticatedly designed one. 1) The attacker used the name emergencyStop to hide the intent; 2) the attacker used a trick of combining CREATE/CREATE2 to create a contract with the same address with different bytecode."

"Proposal Contract was deployed via CREATE. The address for such contracts is derived by hashing deployer address and deployer nonce.

Note: Smart contracts start with nonce = 1

So, Proposal addr: 0xc50 = hash(0x7dc, 1)"

"After governance approved this Proposal Contract, the attacker called its emergencyStop function (which they added maliciously).

This resulted in the contract calling selfdestruct

Then the Deployer contract was self-destructed as well! (re-setting its nonce to 0)"

"The attacker used CREATE2 to deploy the exact same deployer bytecode.

Because of the same bytecode, the contract was deployed at the same address as before: 0x7dc

The nonce then became 1 (as address now had smart contract code)"

"The attacker then called "create(bytes)" function on the Deployer contract, but this time passing a completely new bytecode for their Malicious contract

As the nonce & deployer address were same as before, this resulted in the Malicious contract at the same address as Proposal"

"While the contracts do not allow for draining of the ~$275M in the privacy pools themselves, the exploiter gained control of the TORN governance token, the power to modify the router to reroute deposits/withdrawals, and admin status over Nova, the Gnosis chain deployment."

"Through governance control, the attacker can: - withdraw all of the locked votes - drain all of the tokens in the governance contract - brick the router

However, the attacker still can't: - drain individual pools"

"In this case, they simply withdrew 10,000 votes as TORN and sold it all"

Samczsun Technical Analysis

An analysis of the exploit was put together by samczsun.

On 2023/05/20 at 07:25:11 UTC, Tornado Cash governance effectively ceased to exist. Through a malicious proposal, an attacker granted themselves 1,200,000 votes. As this is more than the ~700,000 legitimate votes, they now have full control.

First, what does this mean for Tornado Cash? Through governance control, the attacker can: - withdraw all of the locked votes - drain all of the tokens in the governance contract - brick the router

However, the attacker still can't: - drain individual pools

Next, how did this happen?

Well, when the attacker created their malicious proposal, they claimed to have used the same logic as an earlier proposal which had passed. However, that wasn't exactly the truth, because they added an extra function

Once the proposal was passed by voters, the attacker simply used the emergencyStop function to update the proposal logic to grant themselves the fake votes

Now that they have all the votes, they can do whatever they want. In this case, they simply withdrew 10,000 votes as TORN and sold it all

Finally, what can we learn from this?

Be careful what you vote for! While we all know that proposal descriptions can lie, proposal logic can lie too! If you're depending on the verified source code to stay the same, make sure the contract doesn't have the ability to selfdestruct

BlockSec Technical Analysis

The BlockSec team put together a technical analysis of the exploit attack. The overall attack was detailed on a Google Sheets.

1/ The key to the success of the Tornado Cash DAO attack is that 1) blindly vote -- vote without knowing the consequence; 2) a proposal contract can be updated through a well-designed trick -- create and create2.

2/ The attack is a sophisticatedly designed one. 1) The attacker used the name emergencyStop to hide the intent; 2) the attacker used a trick of combining CREATE/CREATE2 to create a contract with the same address with different bytecode.

3/ In summary, how to defend the DAO attack is still an open question. We will provide some open tools in the future to solve this issue. Stay tuned.

SlowMist Technical Analysis

The SlowMist Team published a technical analysis of the exploit.

Brief Analysis of TornadoCash Governance Exploit

On May 20, 2023, @TornadoCash suffered a governance attack, in which exploiters took control of the governance of TornadoCash by executing a malicious proposal.

Exploiters first created the proposal contract 0xC503893b3e3c0C6b909222b45f2a3a259a52752D through the 0xAF54612427d97489707332efe0b6290F129DbAcb contract on 2023-05-13 7:07 (UTC).

On 2023-05-13 at 7:22 (UTC), exploiters initiated the #20 proposal and explained in the proposal that the #20 proposal is a supplement to the #16 proposal and has the same execution logic.

But in fact, the proposal contract has an extra self-destruct logic, and its creator, 0x7dC86183274b28E9f1a100a0152DAc975361353d, was created through create2 and has a self-destruct function, so after it self-destructed with the proposal contract, the exploiters could still deploy different bytecodes to the same address in the same way as before.

Unfortunately, the community did not see the foul play in the proposed contract and many users voted for this proposal.

On 2023-05-18, 8:49 - 9:01 (UTC), exploiters repeatedly locked 0 tokens in governance by creating new addresses with multiple transactions.

Now you may be wondering how exploiters ended up taking out so many tokens for these addresses when they locked 0 tokens. The answer lies in the execution of the proposal.

By exploiting the feature that the proposal contract can be destroyed and redeployed with new logic, exploiters destroyed the proposal execution contract at 2023-05-20 7:18 (UTC) and deployed a malicious contract at the same address, whose logic was to modify the amount of tokens locked by the users in governance.

After the exploiters finished modifying the proposal contract, they executed the malicious proposal contract at 2023-05-20 7:25 (UTC). The execution of the proposal was performed via Delegatecall, and as a result, the execution of this proposal resulted in the token lock amount being modified to 10,000 for the addresses controlled by the exploiters in the governance contract.

After the execution of the proposal was complete, the exploiters unlocked the TORN tokens from the Governance Vault.

The TORN tokens reserve in the Vault was depleted and the exploiters took control of the governance at the same time. @samczsun enumerated the possible consequences of this.

Meanwhile, our @MistTrack_io team analyzed the addresses of the proposal voters and made some interesting discoveries

Lucas Martin Calderon Technical Overview

A brief technical overview was published by Lucas Martin Calderon.

@TornadoCash has been hacked in a way I’ve never seen before When was the last time you saw the attack below, using SELFDESTRUCT and metamorphic contracts?

High-level attack exploit: attacker gains 1.2M votes from the Tornado Cash governance vault worth millions of USD by using a malicious governance proposal contract.

The attacker was able to change the bytecode of the smart contract using metamorphic contracts and SELFDESTRUCT

It seems that they pulled it off using a fork of CREATE3 and CREATE2 library from solmate.

On May 21st, the attacker submitted another proposal to revert the hack and return the tokens. That is, the ones that he has not sold… The smart contract seems simple enough to be malicious, we will see how it plays out.

Apoorv Lathey Technical Deep Dive

NTFX protocol developer Apoorv Lathey published a deep technical dive into what happened:

Technical Deep Dive: How Tornado Cash governance exploiter was able to deploy a new malicious contract at the same address

TLDR of the attack: Governance approved innocent-looking Proposal contract. Attacker replaced the contract logic with a malicious one at the SAME address after selfdestruct.

The deployment flow of the Proposal contract involved a separate deployer contract to achieve this:

Proposal Contract was deployed via CREATE.

The address for such contracts is derived by hashing deployer address and deployer nonce.

Note: Smart contracts start with nonce = 1

So, Proposal addr: 0xc50 = hash(0x7dc, 1)

After governance approved this Proposal Contract, the attacker called its emergencyStop function (which they added maliciously).

This resulted in the contract calling selfdestruct

Then the Deployer contract was self-destructed as well! (re-setting its nonce to 0)

The attacker used CREATE2 to deploy the exact same deployer bytecode.

Because of the same bytecode, the contract was deployed at the same address as before: 0x7dc

The nonce then became 1 (as address now had smart contract code)

The attacker then called "create(bytes)" function on the Deployer contract, but this time passing a completely new bytecode for their Malicious contract

As the nonce & deployer address were same as before, this resulted in the Malicious contract at the same address as Proposal

Total Amount Lost

The total amount lost has been estimated at $59,000 USD. TBD NOVA pool at risk?

How much was lost and how was it calculated? If there are conflicting reports, which are accurate and where does the discrepancy lie?

Immediate Reactions

How did the various parties involved (firm, platform, management, and/or affected individual(s)) deal with the events? Were services shut down? Were announcements made? Were groups formed?

Ameen Soleimani Warning Tweet

RIP @TornadoCash governance

IF YOU HAVE FUNDS IN TORNADO NOVA

GTFO ASAP

there is about $1m in the nova contract, that the governance attacker can rugpull via proposal

fortunately the proposal would take 7 days to execute

best not wait!

Check out this great thread by @mesquka about the details of the hack!

tl;dr

the attacker took over the DAO, meaning they control everything the DAO owned:

- $TORN treasury

- relayer registry

- fee registry

- router contract

- tornadocash.eth ENS

The http://tornadocash.eth.link is controlled by the ENS, which means the attacker can point it to whatever they want...

Unfortunately, this also breaks the QR code on our tornado cash t-shirts from @TheMetaFactory, because those point to the .eth.link URL

RIP

The deployed UI also still points to the DAO controlled relayer registry, fee registry, and router contracts, which can now all be rugged.

Do not use the deployed UI.

Inevitably, anons will redeploy the UI and point it to new, immutable versions of the above contracts...

Tell your (non-US) friends to withdraw from Tornado Nova!

Also pull out your TORN LP tokens so the attacker stops dumping on you, silly goose.

Funds in Tornado Cash proper (not Nova) are safu

More from @MicahZoltu on how best (non-US) persons can interact with Tornado Cash

Ultimate Outcome

What was the end result? Was any investigation done? Were any individuals prosecuted? Was there a lawsuit? Was any tracing done?

"However, it seems not all is lost.

Yesterday, just before midday UTC, the exploiter published another proposal to revert the changes.

As long as there are no nasty surprises this time, this could be a bullet dodged for the Tornado Cash community."

Total Amount Recovered

The total amount recovered is unknown.

What funds were recovered? What funds were reimbursed for those affected users?

Ongoing Developments

While the possibility of a future governance exploit is definitely possible, it seems probable that the community will exercise increased care on future proposals.

Individual Prevention Policies

Avoid the use of smart contracts unless necessary. Minimize the level of exposure by removing or withdrawing assets whenever possible. Aim to choose smart contracts which have obtained third party security audits, preferably having been audited by at least three separate reputable firms. Pay attention to the audit reports, which smart contracts are covered, and whether the smart contract has been upgraded or modified since the report. Ensure that any administrative functions with the ability to remove funds from the smart contract are under the authority of a multi-signature wallet which is controlled by at least three separate and reputable entities.

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

All aspects of any platform should undergo a regular validation/inspection by experts. This validation should include a security audit of any smart contracts, reporting any risks to the backing (of any customer assets, ensuring treasuries or minting functions are properly secured under the control of a multi-signature wallet, and finding any inadequacies in the level of training or integrity of the team. The recommended interval is twice prior to launch or significant system upgrade, once after 3 months, and every 6 months thereafter. It is recommended that the third party performing the inspection not be repeated within a 14 month period.

It could be enforced at the community or platform level to ensure that all TornadoCash protocol upgrades have at least two separate third-party expert opinions.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

All platforms should undergo published security and risk assessments by independent third parties. Two assessments are required at founding or major upgrade, one after 3 months, and one every 6 months thereafter. The third parties must not repeat within the past 14 months. A risk assessment needs to include what assets back customer deposits and the risk of default from any third parties being lent to. The security assessment must include ensuring a proper multi-signature wallet, and that all signatories are properly trained. Assessments must be performed on social media, databases, and DNS security.

It could be community-enforced to ensure that all TornadoCash protocol upgrades have at least two separate third-party expert opinions.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.