Full Report
Astrid Finance is a liquid staking protocol built on top of the EigenLayer. Users deposit tokens to receive back liquid staking tokens. The earnings are compounded and distributed back to the stakers. After depositing funds into the protocol, a user is able to call withdraw(). Sadly, the token contract was not validated for being used by the protocol. Instead, only the existence of this was checked. Since these were not validated, an attacker was able to send in their own set of tokens for this that had no value in them. By using these fake tokens, the protocol assumed they were getting a good deal between them. In reality, the withdraw stole all stETH, rETH and cbETH from the protocol about around 228K. With some drama, they blamed the auditor for recommending a bad fix to them. However, I didn't see the audit being public and this is so obvious the devs should know better. They offered the attacker a 20% bounty if they returned the rest of the funds. This actually happened. Is this the precedent we want to set though? Hey! If you hack us, we will give you some percentage of the money and no pursue legal action? Not a good move to me. More blackhats may come out of this.
Analysis Summary
# Incident Report: Astrid Finance Logic Vulnerability Exploitation
## Executive Summary
Astrid Finance, a liquid staking protocol on EigenLayer, suffered a smart contract exploitation due to a lack of token address validation in its withdrawal function. An attacker utilized worthless "fake" tokens to trick the protocol into releasing approximately $228,000 worth of legitimate assets (stETH, rETH, and cbETH). The incident concluded with the attacker returning 80% of the funds in exchange for a 20% "white hat" bounty and a promise of no legal action.
## Incident Details
- **Discovery Date:** Not explicitly stated (Immediate post-exploit)
- **Incident Date:** October 2023 (Estimated based on protocol context)
- **Affected Organization:** Astrid Finance
- **Sector:** Decentralized Finance (DeFi) / Liquid Staking
- **Geography:** Global / Distributed
## Timeline of Events
### Initial Access
- **Date/Time:** Immediate execution upon calling the vulnerable function.
- **Vector:** External malicious smart contract interaction.
- **Details:** The attacker exploited the `withdraw()` function, which failed to verify if the token being processed was an officially supported protocol asset.
### Lateral Movement
- **N/A:** As this was a smart contract exploit, the "movement" consisted of the attacker passing a malicious token address into the treasury's withdrawal logic to authorize the release of legitimate pool funds.
### Data Exfiltration/Impact
- **Details:** The attacker successfully drained the protocol’s secondary reserves, specifically targeting stETH, rETH, and cbETH.
- **Total Loss:** Approximately $228,000 USD.
### Detection & Response
- **Detection:** Discovered via on-chain monitoring and sudden liquidity depletion.
- **Response actions taken:** Protocol team engaged in public negotiations with the attacker via on-chain messaging, offering a 20% bounty in exchange for the return of the remaining 80% of funds.
## Attack Methodology
- **Initial Access:** Manipulation of the `withdraw()` function input parameters.
- **Persistence:** Not applicable; one-time atomic transaction/exploit.
- **Privilege Escalation:** Exploited logic flaw to gain unauthorized withdrawal authority over protocol-owned assets.
- **Defense Evasion:** Used "fake" tokens that satisfied basic existence checks (e.g., `extcodesize`) but held no economic value.
- **Discovery:** Identifying that the protocol only checked for the *existence* of a token contract, not its *identity* on a whitelist.
- **Collection:** Automated draining of staked assets from the protocol's vault.
- **Impact:** Financial theft resulting in the loss of $228,000 in liquidated staking tokens.
## Impact Assessment
- **Financial:** Initial loss of $228,000; permanent loss of ~45,600 (20% bounty).
- **Data Breach:** None (on-chain transaction data is public).
- **Operational:** Protocol functionality likely paused or severely hampered during the recovery phase.
- **Reputational:** Significant damage due to public "blame shifting" toward auditors and the controversial decision to pay a large bounty post-exploit.
## Indicators of Compromise
- **Behavioral indicators:** Unexpected calls to the `withdraw()` function involving unrecognized or "untracked" ERC-20 token addresses.
- **Network indicators:** Transactions interacting with the Astrid Finance withdrawal contract originating from an unverified/malicious contract address.
## Response Actions
- **Containment:** Public outreach to the attacker.
- **Eradication:** Negotiations led to the return of 80% of the stolen assets.
- **Recovery:** Funds were returned to the protocol treasury; developers blamed a "bad fix" recommended by auditors for the vulnerability.
## Lessons Learned
- **Validation is Paramount:** Simply checking if a contract exists is insufficient; protocols must strictly whitelist approved asset addresses.
- **Auditor Interaction:** Developers must critically evaluate auditor recommendations rather than implementing them blindly.
- **Bounty Precedents:** Granting a 20% bounty to a blackhat attacker may incentivize future attacks by signaling that theft is a viable path to a "legal" payout.
## Recommendations
- **Implement Strict Whitelisting:** Use a `mapping(address => bool)` to verify that any token passed to the `withdraw()` function is an authorized asset.
- **Comprehensive Audit Reviews:** Publicly release audit reports and ensure that "fixes" for found vulnerabilities are re-audited before mainnet deployment.
- **Circuit Breakers:** Implement value-based withdrawal limits or "emergency pause" functionality to mitigate damage during an ongoing exploit.