Full Report
Sushi Swap is a popular trading platform with the ability to take out loans, perform leverage trading and more. When a user wants to allow an address to spend money on their behalf, they use the approve ERC20 function. Since we trust Sushiswap and they need the approval to spend our money in the smart contract call, this is a pretty standard thing to do. A router contract allows for a high level call to be made and the smart contract will do the rest for you. For instance, if you wanted to trade USDC for wETH, you would need to find the pool to perform the trade. The router can be used as a lookup in order to find this pool. Additionally, it may be able to perform multiple operations in one transaction. The Sushiswap router was a little too generous with user provided data. The function processRoute took in a variable called route, which was generated off chain. This route is used for the path of tokens to be traded, with the first token being the sold and the final being the bought token. The route variable had no verification performed on it though. When using the swap command code with a UniswapV3 pool, the user can provide an arbitrary address. The attackers contract calls back to the uniswapV3SwapCallback function. There is validation that the sender is the pool, which is true since an attacker controls the contract address! Now, the smart contract thinks that the caller is a UniswapV3 pool. In the code, there is a safeTransferFrom call, where the attacker controls the from parameter. Since the router has approvals from other users to spend their money, an attacker can use this to send the money to themselves! Additionally, all of the funds of a token can be drained from the router itself, since it has a call to safeTransfer on itself. This is why large approvals are horrible... you must be careful, since a protocol may have a vulnerability that will allow them to drain the funds of its users. Overall, a super interesting and impactful bug in a popular trading platform. In practice, be careful on the external contract calls and privileges you allow.
Analysis Summary
# Incident Report: SushiSwap Router Contract Exploitation
## Executive Summary
In April 2023, the SushiSwap `RouteProcessor2` contract was exploited due to a lack of input validation in the `processRoute` function. An attacker leveraged a malicious "pool" address to trigger unauthorized `safeTransferFrom` calls, draining funds from users who had granted approval to the contract. The incident resulted in a loss of approximately $3.3 million in ETH, much of which was later recovered by white-hat security teams.
## Incident Details
- **Discovery Date:** April 9, 2023
- **Incident Date:** April 9, 2023
- **Affected Organization:** SushiSwap
- **Sector:** Decentralized Finance (DeFi)
- **Geography:** Global / Blockchain
## Timeline of Events
### Initial Access
- **Date/Time:** April 9, 2023 (Approx. 00:30 UTC)
- **Vector:** Smart Contract Vulnerability (Logic Error)
- **Details:** The attacker identified a vulnerability in the `processRoute` function of the newly deployed SushiSwap `RouteProcessor2` contract.
### Lateral Movement
- **N/A:** As a blockchain-based smart contract exploit, the attack did not involve internal network movement but rather targeted the global "Approval" mechanism of ERC20 tokens across multiple user addresses.
### Data Exfiltration/Impact
- **Details:** The attacker manipulated the `uniswapV3SwapCallback` to trick the contract into believing it was dealing with a legitimate Uniswap V3 pool. This allowed the attacker to call `safeTransferFrom` using the addresses of users who had previously approved the SushiSwap router, effectively stealing their tokens.
### Detection & Response
- **Detection:** Security monitoring tools and community members flagged a sudden drain of funds (notably from user "0xsifu").
- **Response Actions:** SushiSwap developers and security firms (such as PeckShield and BlockSec) issued urgent warnings for users to revoke approvals to the vulnerable contract address.
## Attack Methodology
- **Initial Access:** Exploitation of insufficient input validation in the `route` parameter.
- **Persistence:** None (Single-transaction exploit).
- **Privilege Escalation:** Logic flaw allowed the attacker to masquerade as a trusted UniswapV3 pool.
- **Defense Evasion:** Use of a malicious contract to intercept callbacks.
- **Credential Access:** Not applicable; leveraged existing blockchain "approvals."
- **Discovery:** Identification of the unverified `route` variable in the `processRoute` function.
- **Lateral Movement:** N/A.
- **Collection:** Automated draining of tokens from multiple user wallets to the attacker's address.
- **Exfiltration:** Transfer of assets (primarily ETH/WETH) to the attacker's wallet.
- **Impact:** Direct financial theft via unauthorized fund transfers.
## Impact Assessment
- **Financial:** Total loss estimated at approximately 1,800 ETH (~$3.3M USD at the time).
- **Data Breach:** Public transaction history revealed affected wallet addresses.
- **Operational:** SushiSwap was forced to deprecate the vulnerable router and instruct thousands of users to take manual action.
- **Reputational:** Significant community concern regarding the auditing process for new contract deployments.
## Indicators of Compromise
- **Contract Address:** `0x044b75f554b886A065b956cF15D9582b22ec01d9` (Vulnerable SushiSwap Router)
- **Attacker Address:** `0x9de69157b274666010fa28b5de399d763AD90C0B` (Defanged)
- **Behavioral:** Unexpected `safeTransferFrom` calls originating from the SushiSwap Router to an unknown third-party contract.
## Response Actions
- **Containment:** Community alerts to revoke approvals using tools like Revoke.cash.
- **Eradication:** Deployment of "White-hat" bots to front-run the attacker and secure remaining vulnerable funds.
- **Recovery:** Development of a claim portal for users whose funds were rescued by the security teams.
## Lessons Learned
- **Input Validation:** Complex variables generated "off-chain" must be strictly validated on-chain before execution.
- **Approval Risks:** The "Infinite Approval" model in DeFi remains a massive systemic risk; users should use "exact amount" approvals where possible.
- **Audit Gaps:** Vulnerabilities can exist even in "standard" router implementations if new logic (like multi-route processing) is introduced without exhaustive edge-case testing.
## Recommendations
- **Security:** Implement strict address whitelisting for external contract calls within routers.
- **User Safety:** For DeFi users, regularly audit and revoke unused token approvals.
- **Development:** Integrate formal verification for high-privilege functions that handle user-approved funds.