Full Report
ApolloX Finance is a decentralized derivatives (short, longs, etc.) exchange, with the token APX. The contract was using a signature system for various calls given from an off-chain variant of the service itself. The signature system was used when a user wanted to make a withdrawal. The off-chain system would send a signature to the user, which could be used to call claim to get their funds. During this, the signature is validated to originate from the backends signature. There is also a claim history to ensure this cannot be simply replayed. There were two other functions using the signing system as well. In particular, there is a separate contract with the same claim function. The only difference is an extra field being taken from the signed message. By complete luck, the deadline (date) in the second contract was the same field as the reservedAmount variable. Since the amount was large enough (and seen as the deadline date), this verification would pass. This means that the already expired signature of previously made transactions but the funds would not be sent to the author of the call. Instead, they can get the signed object themselves and perform this action three times instead of one; effectively tripling the amount of money that should be able to obtain from this. Overall, an interesting problem of reusing cryptographic keys across different areas. This could be have been solved by having different keys for different contracts or having a global system for keying track of signatures. Good find by the hacker on this one!
Analysis Summary
# Incident Report: ApolloX Finance Signature Reuse Vulnerability
## Executive Summary
ApolloX Finance, a decentralized derivatives exchange, suffered an exploit resulting in the unauthorized withdrawal of APX tokens. The attacker leveraged a signature reuse vulnerability where cryptographic signatures intended for one contract were valid for another due to a lack of domain separation. By crafting a malicious contract to automate these calls, the attacker successfully tripled their withdrawal amounts before the incident was contained.
## Incident Details
- **Discovery Date:** June 2022 (Based on community reports)
- **Incident Date:** June 08, 2022
- **Affected Organization:** ApolloX Finance
- **Sector:** Decentralized Finance (DeFi)
- **Geography:** Global / Distributed
## Timeline of Events
### Initial Access
- **Date/Time:** June 2022
- **Vector:** Smart Contract Logic Flaw
- **Details:** The attacker identified that the `claim` function in `ApolloxExchangeTreasury` reused a signing logic identical to another system contract, without sufficient replay protection across different function contexts.
### Lateral Movement
- **N/A:** In this DeFi context, the "movement" involved transitioning from a legitimate user state to an exploiter state by deploying a custom attack contract.
### Data Exfiltration/Impact
- **Details:** The attacker deployed a contract that called the `claim` function in a loop. By reusing valid signatures where a specific variable (`reservedAmount`) was misinterpreted by the contract as a `deadline` (expiry date), they bypassed temporal restrictions.
### Detection & Response
- **Detection:** On-chain monitoring services and community members (e.g., p0n1 on X) identified anomalous large-scale withdrawals of APX.
- **Response:** ApolloX Finance acknowledged the exploit, paused relevant contract interactions where possible, and moved to patch the signature verification logic.
## Attack Methodology
- **Initial Access:** Exploitation of logic flaw in signature verification.
- **Persistence:** Not applicable; the attack was an atomic transaction series.
- **Privilege Escalation:** Exploiting the mismatch between `reservedAmount` and `deadline` fields to gain unauthorized withdrawal authority.
- **Defense Evasion:** Use of a custom smart contract to automate the exploit within a single transaction blocks.
- **Discovery:** Identifying that the same cryptographic key was used across multiple contracts with overlapping data structures.
- **Collection:** Aggregating APX tokens into the attacker's wallet.
- **Impact:** Systematic depletion of the treasury's APX reserves.
## Impact Assessment
- **Financial:** Loss of approximately 53 million APX tokens (Estimated value at time of attack varied).
- **Data Breach:** None (Public blockchain data only).
- **Operational:** Temporary suspension of withdrawal services and emergency patching of smart contracts.
- **Reputational:** Significant community concern regarding the security of the exchange’s off-chain signing infrastructure.
## Indicators of Compromise
- **Attacker Address:** `0x4f...` (Truncated)
- **Attack Transaction:** `0x34b29a393b68ae0f2e417485fb57ea7510a253c1b01431d04a66ca61e4fbbc8c`
- **Target Contract:** `0xe2e912f0b1b5961be7cb0d6dbb4a920ace06cd99` (ApolloxExchangeTreasury)
- **Behavioral:** High-frequency loop calls to the `claim` function within a single transaction.
## Response Actions
- **Containment:** Community and developers identified the malicious transaction; treasury functions were analyzed for immediate risks.
- **Eradication:** The signature system was updated to ensure that signatures are unique to specific contracts and functions.
- **Recovery:** Resumption of services after confirming the fix and verifying the remaining treasury balance.
## Lessons Learned
- **Cryptographic Domain Separation:** Reusing the same signing key/method across different contracts or functions without a unique identifier (like a `DOMAIN_SEPARATOR`) creates high risk.
- **Field Overlap:** When different contracts interpret the same signed message differently, attackers can exploit "lucky" overlaps (e.g., an amount being read as a future timestamp).
- **Loop Prevention:** Lack of internal checks or rate limits on the `claim` function allowed for rapid depletion.
## Recommendations
- **Implement EIP-712:** Use the EIP-712 standard for typed structured data hashing and signing to ensure signatures cannot be reused across different domains.
- **Unique Nonces:** Ensure that every signature includes a unique nonce and the address of the specific contract intended to receive it.
- **Security Audits:** Conduct cross-contract logic reviews to ensure that updates to one contract do not inadvertently create vulnerabilities in others using the same backend infrastructure.