Tornado Cash Governance Overtaken

Notice: This page is a freshly imported case study from the original repository. The original content was in a different format, and may not have relevant information for all sections. Please help restructure the content by moving information from the 'About' section to other sections, and add any missing information or sources you can find. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

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.

This is a global/international case not involving a specific country.

About Tornado Cash

TornadoCash is "[a] fully decentralized protocol for private transactions on Ethereum." and "in the crypto-space."

As a decentralized protocol, Tornado.Cash smart contracts have been implemented within the Ethereum blockchain, making them immutable. They can neither be changed nor tampered with. Therefore, nobody - including the original developers - can modify or shut them down. All governance and mining smart contracts are deployed by the community in a decentralized manner.

As a non-custodial protocol, users keep custody of their cryptocurrencies while operating Tornado.Cash. This means that at each deposit, they are provided with the private key enabling the access to the deposited funds, which gives users complete control over their assets."

"Tornado Cash improves transaction privacy by breaking the on-chain link between source and destination addresses. It uses a smart contract that accepts ETH & other tokens deposits from one address and enables their withdrawal from a different address."

"Since its inception in 2019, Tornado Cash has been operating on the Ethereum blockchain. The protocol has been offering diversified fixed amount pools for six tokens (ETH, DAI, cDAI, USDC, USDT & WBTC) handled by the Ethereum blockchain.

Since June 2021, in addition to the Ethereum blockchain, Tornado Cash smart contracts have also been deployed on other side-chains & blockchains. These deployments enabled the tool to either support new tokens or benefit from Layer-2 advantages, such as faster and cheaper 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"

"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."

This is a global/international case not involving a specific country.

The background of the exchange platform, service, or individuals involved, as it would have been seen or understood at the time of the events.

Include:

• Known history of when and how the service was started.
• What problems does the company or service claim to solve?
• What marketing materials were used by the firm or business?
• Audits performed, and excerpts that may have been included.
• Business registration documents shown (fake or legitimate).
• How were people recruited to participate?
• Public warnings and announcements prior to the event.

Don't Include:

• Any wording which directly states or implies that the business is/was illegitimate, or that a vulnerability existed.
• Anything that wasn't reasonably knowable at the time of the event.

There could be more than one section here. If the same platform is involved with multiple incidents, then it can be linked to a main article page.

The Reality

This sections is included if a case involved deception or information that was unknown at the time. Examples include:

• When the service was actually started (if different than the "official story").
• Who actually ran a service and their own personal history.
• How the service was structured behind the scenes. (For example, there was no "trading bot".)
• Details of what audits reported and how vulnerabilities were missed during auditing.

What Happened

The specific events of the loss and how it came about. What actually happened to cause the loss and some of the events leading up to it.

Key Event Timeline - Tornado Cash Governance Overtaken

Date	Event	Description
May 20th, 2023 1:25:11 AM MDT	Governance Exploit	Blockchain transaction.

Technical Details

This section includes specific detailed technical analysis of any security breaches which happened. What specific software vulnerabilities contributed to the problem and how were they exploited?

Total Amount Lost

The total amount at risk has been estimated at $275,000,000 USD. The total amount lost has been estimated at $59,000 USD.

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?

Ultimate Outcome

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

Total Amount Recovered

The total amount recovered is unknown.

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

Ongoing Developments

What parts of this case are still remaining to be concluded?

Individual Prevention Policies

No specific policies for individual prevention have yet been identified in this case.

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

Platform Prevention Policies

Policies for platforms to take to prevent this situation have not yet been selected in this case.

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

Regulatory Prevention Policies

No specific regulatory policies have yet been identified in this case.

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