Cascaded Fallacy: DeFi Bank Drain Analysis
This lab focuses on tracing a multi-stage decentralized finance (DeFi) hack on the Ethereum Sepolia testnet. To understand this exploit, you don't need to be a blockchain wizard. We will break down exactly how the attacker tricked the bank, starting with a simple analogy before diving into the hard technical evidence.
Stage 1: GenesisVault & Reentrancy
Vulnerability: Checks-Effects-Interactions Violation
GenesisVault executed an external ETH transfer before decrementing the user's internal ledger balance. A malicious fallback function can repeatedly call into the withdrawal function during the execution frame before the state update occurs, draining the vault liquidity.
Q: How was the GenesisVault initially drained?
A: Reentrancy Attack
The attacker exploited a classic state-update flaw. The smart contract sent ETH to the attacker using a low-level call.value() before deducting the user's internal balance. This violates the strict "Checks-Effects-Interactions" pattern.
[ SHOW METHODOLOGY: Blockscout Trace & Opcodes ]▼
- Query the Sepolia Blockscout API for the attacker's main transaction.
- Analyze the Internal Transactions trace.
- You will notice a highly nested execution trace where the
CALLopcode transferring ETH is fired multiple times sequentially within a single transaction frame. - The
Withdrawnevent is only emitted at the very end of the execution tree, confirming the state update was deferred until after the malicious fallback function finished executing.
Stage 2: PatchedVault & Broken Access Control
Vulnerability: Missing Caller Ownership Validation
PatchedVault checked whether the provided GhostShare NFT token ID possessed liquidation rights, but failed to verify whether msg.sender actually owned or had approval for that specific token ID. Any caller could supply a valid token ID held by an external user and trigger unauthorized liquidations.
The liquidate() function was protected by an Access Control mechanism that required a specific GhostShare NFT. However, the contract failed to properly verify if the person calling the function (msg.sender) actually owned the NFT token ID passed in the parameters. The attacker simply passed the token ID of a legitimate admin, spoofing their authorization.
Stage 3: SignedVault & Signature Replay
Vulnerability: EIP-712 Signature Replay (Missing Nonce)
SignedVault verified off-chain admin signatures using EIP-712 typed structured data. Because the hash schema lacked a per-user nonce or deadline timestamp, an intercepted signature remained valid indefinitely and was replayed to drain additional funds.
Q: Why was the attacker able to reuse the admin's withdrawal signature?
A: Missing Nonce in EIP-712
Cryptographic signatures in Web3 must be unique to prevent replay attacks. The developers implemented EIP-712A standard for hashing and signing typed structured data in Ethereum. but omitted a nonce mapping in the signed struct. The attacker extracted the raw v, r, s ECDSA signature components from the blockchain history and submitted them again to siphon funds.
Stage 4: OracleVault & Price Manipulation
Vulnerability: Spot AMM Price Oracle Manipulation
OracleVault queried instantaneous token reserves from a low-liquidity AMM pool rather than a Time-Weighted Average Price (TWAP) or decentralized oracle feed. By leveraging a flash loan to swap against the pool, the attacker manipulated the spot price within a single transaction block to force bad-debt liquidations.
The final vault relied on a shallow SpotPool Automated Market Maker (AMM) as a price oracle. The attacker used a massive Flash Loan to temporarily dump tokens into the AMM, drastically crashing the spot price inside a single transaction block.
Because the vault did not use a TWAPTime-Weighted Average Price. Taking an average price over time prevents instant flash-crash manipulation., it instantly calculated that all user collateral was worthless and permitted the attacker to trigger liquidations.
Constructing the Final Flag
To solve the challenge, we had to piece together the entire kill-chain and identify the final destination of the stolen funds. The challenge required us to concatenate the specific vulnerability categories from each of the four stages, followed by the final laundering address.
Stage 1: reentrancy
Stage 2: accesscontrol
Stage 3: signaturereplay
Stage 4: oraclemanipulation
Attacker Wallet (Funder): 0x0461c310002234a6a82B24136BB8323D08bc81c1
Main Operation Wallet: 0x2bbd3717E662a46CD1A15bab9767C386b72bed68
Exploit Contract (Weapon): 0x2B23F8d55Ff39A6C273B2Bd869D666FB4f160df7
Final Destination (Launder): 0x071a8E8c5c0484B7A2fFA06530518DC9209e627f
Final Submitted Flag:
ASCWG{reentrancy_accesscontrol_signaturereplay_oraclemanipulation_0x071a8E8c5c0484B7A2fFA06530518DC9209e627f}