Explained: The SIREN Protocol Hack (September 2021)

On September 3, 2021, the SIREN protocol was the victim of a hack.  The attacker took advantage of a reentrancy bug in the smart contract code to steal approximately $3.5 million in tokens from the protocol.

Inside the Attack

Like the recent CREAM finance hack, the SIREN protocol hack took advantage of a re-entrancy vulnerability in a smart contract.  Re-entrancy vulnerabilities can exist when a smart contract sends value to another contract (typically due to a withdrawal) and then updates its internal state (i.e. debiting that value from the user’s account).

When a smart contract receives a transaction, it is permitted to run a “fallback” function, which is designed to allow it to update its internal state or take action based on the transaction.  

Re-entrancy occurs when this function is used to call the vulnerable contract again to perform a withdrawal before the vulnerable function records the first withdrawal.

The SIREN protocol hack exploited re-entrancy vulnerabilities in the smart contracts implementing the project’s AMM pools.  The vulnerable contracts performed three operations in the following order:

1. Call to _sellOrWithdrawActive Tokens (the re-entrancy point)
2. Call to safeTransfer (sending the tokens to the malicious contract)
3. Update of internal state

The second step above would allow the malicious contract’s fallback function to re-enter the vulnerable code at step 1.  This allows the attacker to perform a second transfer (step 2) before step 3 is reached and the contract’s internal state is updated.

The attacker exploited this vulnerability across multiple contracts to drain the project’s KNC, SUSHI, USDC, WNI, WETH, and WMATIC pools before the team took action to freeze token movements.  In total, the stolen tokens were worth approximately $3.5 million.

Lessons Learned From the Attack

The SIREN Protocol was exploited via a re-entrancy vulnerability that has existed since the project code was originally released on Github on December 20, 2020.  The issue persisted across code modifications to v2 of the protocol.

A security audit performed prior to the December 2020 release references re-entrancy issues being detected by Slither but being considered false positives as they were to trusted contracts.  

This may or may not be the issue exploited in this hack since the attacker exploited the ability of the onERC1155Received function to call other contract’s functions to perform the re-entry.

The SIREN hack demonstrates the importance of performing security audits before each code release and ideally from multiple organizations.  Re-entrancy vulnerabilities are known threats with clear code patterns that can be detected during an audit.