Analysis of the Tsuru Exploit

TL;DR

On May 10, 2024, Tsuru was exploited on the Base chain due to a smart contract vulnerability, which resulted in a loss of 137.78 ETH, which was worth approximately $410,000.

Introduction to Tsuru

Tsuru is the original character created by a supposed Japanese illustrator, Tsurushima Tatsumi.

Vulnerability Assessment

The root cause of the exploit is a lack of regulated access control.

Steps

Step 1:

We attempt to analyse the attack transaction executed by the exploiter.

Step 2:

The exploited TSURUWrapper contract had a vulnerable onERC1155Received function that lacked proper authentication and enough access control.

function onERC1155Received(address, address from, uint256 id, uint256 amount, bytes calldata) external override nonReentrant returns (bytes4) {
  require(id == tokenID, "Token ID does not match");

  if (msg.sender == address(erc1155Contract)) {
    return this.onERC1155Received.selector;
  }

  _safeMint(from, amount * ERC1155_RATIO); // Adjust minting based on the ERC1155_RATIO
  return this.onERC1155Received.selector;
}

Step 3:

As long as the id or tokenID parameter in this function corresponds to the ID of the project, it would allow anyone to mint the TSURU token and later swap it for ETH in the Uniswap Liquidity pool.

Step 4:

This exploiter on the Base chain swapped the stolen 167 million Tsuru for 137.78 ETH, which were worth approximately $410,000, and then bridged it to this address on the Ethereum Mainnet. This address on the Ethereum Mainnet also received 40.95 ETH worth of assets from an old incident that traces back to the incident involving Perpy Finance.

Step 5:

The project was hacked roughly two hours after its deployment, and at the time of this writing, the address of the exploiter on the Ethereum Mainnet has a hold of 179.68 ETH, which is worth approximately $516,129.

Aftermath

The team acknowledged the occurrence of the exploit and has also shared a detailed post-mortem report regarding the incident.

Solution

To address the vulnerabilities exploited in the Tsuru smart contract, a multi-faceted approach focused on strengthening security protocols, improving contract design, and enhancing monitoring systems is essential. Firstly, introducing rigorous access control measures in smart contracts is critical. For the Tsuru case, specifically ensuring that the onERC1155Received function includes authentication checks to verify not only the contract addresses interacting but also the roles of the interacting accounts would prevent unauthorized access. This could be implemented by incorporating a modifier that checks if the caller is from a list of addresses pre-approved by the contract owner or holds a specific role defined within the contract’s governance framework.

Additionally, enhancing the contract’s logic to handle unexpected inputs more safely is necessary. For instance, implementing checks that validate the state changes within the contract before and after executing critical functions could help. This ensures that even if an unauthorized party were to call a function, they would not be able to cause state changes that could lead to asset theft or other undesired outcomes.

Improving the testing and deployment procedures is another crucial step. Before deployment, the contract should undergo thorough testing, including both automated tests and manual peer reviews. Utilizing testnets to simulate real-world usage and attacks can help uncover vulnerabilities that might not be evident in isolated tests. Furthermore, engaging external auditors to conduct security audits and offering bug bounty programs can incentivize the discovery and resolution of security flaws before they can be exploited maliciously.

This article was originally published by Pukar Acharya elsewhere.