The Seneca Protocol is a decentralized finance (DeFi) platform that provides a collateralized debt position (CDP) system for borrowing senUSD, a stablecoin pegged to $1. By using yield-generating assets as collateral, users can borrow funds while continuing to earn a fixed yield on their collateral. This dual functionality aims to offer both liquidity and yield generation in one system.
Impact of the Exploit Â
On February 28, 2024, a critical vulnerability in the Seneca Protocol’s Chamber contract led to the theft of approximately $6.4 million, mainly in Ether (ETH). The breach not only inflicted significant financial damage but also severely impacted the protocol’s reputation, resulting in decreased liquidity, plummeting token prices, and diminished user confidence. The exploit was exacerbated by the inability to pause the contracts due to a missing pause/unpause function. The attacker stole over 1,900 ETH and 50,000 senUSD from a team wallet through various swaps involving Liquidity Staked Tokens (LSTs), distributing the stolen funds across three addresses.
Seneca Protocol Hack Explained
Step 1: Exploiting Vulnerability in the Chamber Contract
The attack exploited a vulnerability in the Chamber contract’s performOperations function, which allowed callers to specify various parameters for external calls:
- actions: An int8 array to define the target function(s) to call.
- values: A uint256 array to specify the amount of ETH to send with the function call.
- data: A bytes array to provide the arguments for the function(s).
In this case, the attacker set the actions[0] value to 30, which triggered the internal _call function in the Chamber contract. This allowed the attacker to make arbitrary external calls to any contract with crafted input data.
By setting callData to invoke the transferFrom() function on a token, the attacker specified the from address as a user’s address and the to address as their own externally owned account (EOA). Since msg.sender was the Chamber contract, the attacker was able to transfer funds to themselves due to the Chamber contract’s approval amount exceeding the total collateral deposited. This manipulation enabled the attacker to siphon over $6 million from users’ funds.
Step 2: Abuse of Token Approvals
The attacker capitalized on the fact that users had pre-approved the Chamber contract to manage their tokens. By utilizing the performOperations function, the attacker crafted calldata to trigger a transferFrom() function, specifying users’ addresses as the source and the attacker’s own address as the destination. Due to the inadequate validation in the Chamber contract, this external call was allowed, and tokens were siphoned directly from users’ wallets. Over $6 million worth of assets were stolen before the attacker returned 80% of the funds following a whitehat request from Seneca.
Simulate the Attack
To gain a deeper understanding of the Seneca Protocol exploit, you can replicate the attack by following the proof of concept (PoC) available in this GitHub repository. The PoC includes detailed, step-by-step instructions on how the vulnerability in the Chamber contract was exploited. By simulating the attack, you can observe the exploit process and gain insights into the attack dynamics and its impact.
Transaction Analysis
The attack on the Seneca Protocol led to the theft of over 1,900 ETH, involving various Liquidity Staked Tokens (LSTs) that were swapped for ETH. The stolen ETH is currently held across three addresses:
- Exploiter Address 1: 0x94641c01a4937f2c8ef930580cf396142a2942dc – This address executed the attack.
- Exploiter Address 2: 0x5217c6923a4efc5bcf53d9a30ec4b0089f080ed0
- Exploiter Address 3: 0xe83b072433f025ef06b73e0caa3095133e7c5bd0
Each of the second and third exploiter addresses holds approximately 500 ETH, totaling nearly 1,000 ETH, which is about 80% of the stolen funds. The remaining 20% of the funds have been handled differently:
- Attack Transaction: 0xee02781eda4108f8fb3cca8355218 – This transaction contains details of the hack, initiated by the executor address.
Upon realizing the breach, Seneca took immediate action by instructing users to revoke their token approvals. Despite this, the damage had already been done. Subsequently, Seneca issued an on-chain message on X, offering a 20% bounty for the return of the stolen funds.
The hacker responded by returning 1,537 ETH to the Gnosis Safe address and transferring 300 ETH to two new addresses:
- Bounty Address 1: 0x0C77350C4BDe539FfCee261A149dbc6e6afDA517 – Received 150 ETH.
- Bounty Address 2: 0xa07c64E55F52AAf5c361321CF01b316eCbddB5A9 – Received 150 ETH.
Funds Flow
The attacker began by funding their address with 0.0992 ETH. Shortly after, through a series of transactions, the exploiter utilized platforms like AirSwap and various liquidity pools to steal significant amounts of ETH and other tokens. They transferred approximately 1,907.31 ETH and additional smaller sums, moving funds across multiple wallets and using bridges like CBridge and MetaMask Meta Bridge. The total stolen funds reached 500 ETH in a single transaction, all routed to various addresses for obfuscation.
Recommendation for Enhanced Security
To prevent future exploits, the Seneca Protocol should implement the following security measures:
- Â Implement Comprehensive Input Validation: Ensure all external calls and input parameters are rigorously validated to prevent unauthorized operations. This includes validating function arguments and using access controls to restrict sensitive operations.
- Enhance Access Controls: Introduce strict access control mechanisms, including role-based permissions and multi-signature approvals for critical functions, to minimize the risk of unauthorized access.
- Audit and Test Smart Contracts: Conduct regular security audits and extensive testing of smart contracts, including code reviews and penetration testing, to identify and address vulnerabilities before deployment.
- Utilize Pausing Mechanisms: Implement robust pausing mechanisms that can be swiftly activated to halt all operations in case of detected anomalies or potential exploits.
Conclusion
The Seneca Protocol hack underscores the critical need for stringent security measures and thorough audits in DeFi platforms. Although the protocol was designed to facilitate complex transactions, its vulnerabilities were exploited with significant financial consequences. This incident demonstrates that even well-intentioned systems are susceptible to risks if security isn’t prioritized.
As the DeFi landscape continues to advance, safeguarding smart contracts must remain a top priority. Implementing rigorous security practices, conducting regular and comprehensive audits, and fostering transparent communication with users are essential steps in protecting assets and maintaining trust within the ecosystem.
Organizations like BlockApex, with their specialized expertise in smart contract auditing, are instrumental in identifying and addressing vulnerabilities before they can be exploited. The Seneca Protocol incident serves as a stark reminder of the necessity for continuous vigilance and robust security protocols to build trust and support the sustained growth of DeFi platforms.
