Full Report
FEG (Feed Every Gorilla) is a peer-to-peer trading protocol with its own governance token FEGToken on the Binance Smart Chain. It also supports NFT trading. The project allowed for user supplied addresses to approve the spending of their deposited funds. However, this approval was kept separately and didn't do bookkeeping on the amount of funds the user actually had at the time of spending. It manually increases the balance of the other user without actually subtracting from the user until the money was spent. An attacker could (and did) exploit this issue. This was done by approving multiple addresses to use the same funds. Then, double/triple/12uple spending the money. The allowance to themselves without checking the users underlying balance created a money duplication bug. This was done multiple times to drain the contract. To make matters worse, an attacker used a flashloan to get a ton of funds this performed this attack. Bad bookkeeping leads to a loss of funds. Very sad!
Analysis Summary
# Incident Report: FEG Token Protocol Flashloan Exploit
## Executive Summary
On May 15, 2022, the FEG (Feed Every Gorilla) token protocol was targeted by a series of flashloan exploits across the Binance Smart Chain (BSC) and Ethereum networks. The attacker exploited a vulnerability in the `swapToSwap()` function, which lacked proper input validation, allowing for unauthorized fund approvals and a "money duplication" effect via bad bookkeeping. The incident resulted in a total loss of approximately $1.3 million in digital assets.
## Incident Details
- **Discovery Date:** May 15, 2022
- **Incident Date:** May 15, 2022, 08:22:49 PM +UTC
- **Affected Organization:** FEG (Feed Every Gorilla)
- **Sector:** Decentralized Finance (DeFi) / Peer-to-Peer Trading
- **Geography:** Global / Decentralized
## Timeline of Events
### Initial Access
- **Date/Time:** May 15, 2022, approx. 08:22 PM +UTC
- **Vector:** Flashloan-funded Smart Contract Interaction
- **Details:** The attacker utilized a flashloan to acquire a massive amount of liquidity, which served as the capital needed to trigger the vulnerability within the FEG protocol’s smart contracts.
### Lateral Movement
- **N/A:** As this was a smart contract exploit, the "movement" involved calling specific functions (`depositInternal()` and `swapToSwap()`) repeatedly to escalate permissions within the protocol's liquidity pool environment rather than moving through a traditional IT network.
### Data Exfiltration/Impact
- **Details:** The attacker exploited a flaw where the protocol manually increased user balances without verifying underlying deposits or subtracting from the source during the approval process. By approving multiple malicious addresses to use the same underlying funds, the attacker "double-spent" the assets multiple times, effectively draining the contract's liquidity.
### Detection & Response
- **How it was discovered:** On-chain monitoring and security alerts (CertiK) identified the abnormal flashloan volume and subsequent drainage of the FEG contract.
- **Response actions taken:** Community alerts were issued; however, the immutable nature of the smart contract allowed the attacker to complete the drainage before the protocol could be paused or upgraded.
## Attack Methodology
- **Initial Access:** Flashloan acquisition of capital.
- **Persistence:** N/A (Atomic transaction exploit).
- **Privilege Escalation:** Exploitation of the `swapToSwap()` function to grant "unlimited allowance" to attacker-controlled addresses.
- **Defense Evasion:** Use of a smart contract "path" parameter that was not validated by the protocol, treating an attacker-controlled address as a "trusted party."
- **Credential Access:** N/A.
- **Discovery:** Identification of unvalidated user-supplied input in the `path` parameter of the `swapToSwap()` function.
- **Lateral Movement:** Repeated calls to `depositInternal()` to cycle funds and bypass bookkeeping checks.
- **Collection:** Accumulation of FEG and associated tokens within attacker-controlled contracts.
- **Exfiltration:** Transfer of stolen assets to the exploiter address [0x73b35...].
- **Impact:** Financial depletion of the liquidity pool.
## Impact Assessment
- **Financial:** Approximately $1.3 Million USD in assets across Ethereum and BNBChain.
- **Data Breach:** None (Public blockchain transaction data only).
- **Operational:** The P2P trading protocol functionality was compromised; loss of liquidity for FEG token holders.
- **Reputational:** High; the incident highlighted critical "bad bookkeeping" and lack of security audits on key contract functions.
## Indicators of Compromise
- **Exploiter Address:** `0x73b359d5da488eb2e97990619976f2f004e9ff7c`
- **Affected Contract Address:** `0x818e2013dd7d9bf4547aaabf6b617c1262578bc7`
- **Sample Exploit Transaction:** `0x77cf448ceaf8f66e06d1537ef83218725670d3a509583ea0d161533fda56c063`
- **Behavioral Indicators:** Multiple large-scale flashloan transactions followed by recursive calls to `swapToSwap()` and `depositInternal()`.
## Response Actions
- **Containment measures:** Post-incident analysis to identify the specific bug in the `swapToSwap()` function.
- **Eradication steps:** Warnings to the community to stop interacting with the compromised swap contracts.
- **Recovery actions:** Deployment of patched iterations of the protocol and tracking of stolen funds through platforms like DeBank.
## Lessons Learned
- **Input Validation:** User-supplied addresses (like the `path` parameter) must never be treated as trusted parties without rigorous validation.
- **Bookkeeping Integrity:** Systems must ensure that "approvals" and "balances" are linked. Increasing one side of a ledger without verifying or decreasing the other creates a money-printing vulnerability.
- **Flashloan Risks:** Protocols must be stress-tested against high-liquidity flashloan scenarios that can amplify a small bug into a total loss of funds.
## Recommendations
- **Rigorous Smart Contract Audits:** Conduct comprehensive professional audits focusing on logic flaws and input validation before deployment.
- **Implementation of Guardrails:** Use checks (such as `require` statements) to verify that a user’s underlying balance is sufficient to cover an allowance or transfer.
- **Pause Mechanism:** Implement a "Circuit Breaker" or emergency pause functionality to halt trading in the event of suspicious, high-volume activity.