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.
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.
The blockchain industry has been grappling with scalability issues, which have hindered widespread adoption due to its technical constraints. As the demand for blockchain, decentralized applications (dApps), and transactions increases, the limitations of existing networks become increasingly apparent. High transaction fees and network congestion have plagued platforms like Ethereum, hampering their ability to support large-scale
The experimental semi-fungible token standard, ERC-404, combines elements from ERC-20 and ERC-721 tokens. Despite rising popularity, it has yet to secure an official Ethereum Improvement Proposal (EIP) designation. However, its unique attributes, such as enabling fractional ownership of NFTs and enhancing liquidity, coupled with the potential for automated NFT minting and burning processes, suggest a
Decentralized applications (dApps) are software that run on a decentralized network, often using blockchain technology. These applications can serve various purposes for end users, such as brokers, art collectors, traders, investors, and documents of public trust. However, their functionality and value attract malicious groups aiming to exploit vulnerabilities for financial gain. This article explores real-world examples of dApp security breaches, their attack vectors, and the lessons learned.