SushiSwap DEX Hack Explained

TL;DR

• SushiSwap suffered a reentrancy attack on April 9, 2023.
• The attackers stole $3.3 Million, but white hats gracefully recovered over 1,000 ETH.
• The hacker exploited a vulnerability in a new routing contract launched four days before the attack.

On April 9, 2023, unknown hackers managed to steal $3.3M, with one user @0xsifu losing 1,800 ETH. The main flaw? The hacker exploited an “approve-related bug” in the RouterProcessor2 smart contract, which caused a failure to validate access permissions halfway through a swap transaction.

Key points:

• The exploited contract was introduced four days before the hack. 
• All users who had approved the RouteProcessor2 contract were at risk.
• The risk spanned across 14 chains: Arbitrum Nova, Arbitrum, Avax, Boba, BSC, Ethereum, Fantom, Fuse, Gnosis, Moonbeam, Moonriver, Optimism, Polygon, Polygon ZkEVM.

Fortunately, the contract had relatively few approvers, which limited the breach’s scale, preventing it from being even more significant. The total losses accounted for $3.3 million.

Vulnerability & Root Cause

There was a sneaky flaw in the swap transaction involving permissions. But the main cause of the hack was – the RouteProcessor2 contract, which was barely four days old when the hackers struck.

Let’s dig deeper. 

What Made It Such An Easy Target?

Firstly, the contract failed to properly validate the route parameter that users were sending for the processRoute function. This gave attackers the keys, and they steered that route right to their malicious controlled pool.

Then, the hackers summoned the swapUniV3, which did a nifty trick – it changed the lastCalledPool variable to their pool’s address and quickly stopped at the swap function of the malicious pool.

Next, that swap function called uniswapV3SwapCallback to check if the sender was the lastCalledPool. And guess what? The callback was accepted since the attacker manipulated that value to point to their pool’s address.

Using it, the attacker constructed transactions with one goal – to drain tokens from the accounts of those unsuspecting users who had given the green light to the new RouteProcessor2 contract.

What Tools and Techniques Were Used By Hackers?

SushiSwap hacker employed the following methods:

• Etherscan – to monitor the activity of the RouterProcessor2 contract and identify potential victims.
• Approval exploit – to steal funds from SushiSwap’s RouterProcessor2 contract, bypassing the permission check by manipulating the storage slot.
• Flash loans – to obtain large amounts of ETH and USDC from protocols such as Aave and dYdX. The hacker then used these funds to interact with the RouterProcessor2 contract and trigger the exploit.
• Reentrancy attack – to repeatedly call the swap3callback function and drain funds from multiple victims in one transaction. This technique exploits a reentrancy vulnerability in some smart contracts that do not prevent recursive calls.

The Heroes: White Hats Save The Day

At first, a 3rd-party security firm identified the hacker’s initial transactions, blocking a loss of 100 ETH. But after this ‘yoink’ attack, the hacker made a second attempt and succeeded. Sushi was already on its toes, so quickly called on white hat hackers for rescue. 

On the day of the attack, the white hat community recovered over 1,000 ETH of the stolen funds:

• 300 ETH recovered by 0XCoffeBabe
• 700 ETH by Lido
• At least 4 ETH across 600 addresses by Anish Agnihotri

Jared Grey, Sushi’s Head Chef, acknowledged the error and advised users to revoke their approvals.

Sushi Reimbursement Plan

Just three days post-exploit, Sushi announced a reimbursement plan to calm its user base. They came up with a Merkle Claim contract that affected people could use to retrieve funds from the white hats’ addresses. 

Even better: SushiSwap developed a tool to check for exposure across various networks, including Ethereum, Polygon, Avalanche, Arbitrum, Gnosis, Optimism, and others.

Market Reactions & Consequences

The SUSHI token experienced a minor 6% drop in the 24 hours after the exploit. The damage, fortunately, wasn’t massive or widespread.

Users affected were either swiftly drained or had their permissions revoked, and the heroic white hat efforts played a significant role in minimizing the PR fallout. Nevertheless, this incident remains a significant source of embarrassment for SushiSwap, and it appears that the drama isn’t over yet.

Just a week before the hack, Jared Grey, SushiSwap’s key figure, highlighted a substantial surge in volume for the DEX’s cross-chain swap (xSwap). On top of that, Sushi’s DAO recently found itself in the crosshairs of the U.S. SEC. The legal case is yet to play out.

Lessons Learned

Let’s talk about the lessons learned from this SushiSwap hack. It underscores the critical importance of validating user-provided input. In this case, the failure to validate user-provided routes for RouteProcessor2 allowed the attacker to establish a malicious pool and take tokens from users who had granted approvals for RouteProcessor2.

Like many of the most significant DeFi hacks we’ve seen, this attack took advantage of vulnerabilities in unaudited code. Therefore, prioritizing smart contract audits and penetration testing should be the go-to approach for most projects in the DeFi space.

On top of that, the active involvement of white hat hackers proved invaluable post-exploit. Hence, this case also proves the importance of engaging a broader community, including through bug bounties, for your cybersecurity needs. Sushi provided a more modest bounty than the industry standard, but thankfully, passionate white hats quickly came to help.