FEG Token Flashloan Exploit Analysis

CertiK
4 min readMay 18, 2022

--

Summary

On May-15–2022 08:22:49 PM +UTC, the FEG token has experienced a flurry of flashloan attacks on both Ethereum and BNBChain, leading to approximately $1.3M worth of assets loss. This vulnerability is due to a flaw in the “swapToSwap()” function that directly takes user input “path” as a trusted party yet without any data validation. Furthermore, the function will approve the unprotected “path” parameter to spend the asset in the current address. Therefore, by repeatedly calling “depositInternal()” and “swapToSwap()”, the attacker is able to launch an attack that gains unlimited allowance and thus drains all the assets within the contract.

One of the affected contract address: https://bscscan.com/address/0x818e2013dd7d9bf4547aaabf6b617c1262578bc7

Exploit Transactions

Exploiter Address: https://bscscan.com/address/0x73b359d5da488eb2e97990619976f2f004e9ff7c

Sample exploit transaction:

https://bscscan.com/tx/0x77cf448ceaf8f66e06d1537ef83218725670d3a509583ea0d161533fda56c063

Attacker fund transfer tracing:

https://debank.com/profile/0x73b359d5da488eb2e97990619976f2f004e9ff7c/history

Related Addresses

Attacker Address: https://bscscan.com/address/0x73b359d5da488eb2e97990619976f2f004e9ff7c

Attacker Exploit Contract:

https://bscscan.com/address/0x9a843bb125a3c03f496cb44653741f2cef82f445

FEG Token Address: https://bscscan.com/token/0xacfc95585d80ab62f67a14c566c1b7a49fe91167

FEG Wrapped BNB (fBNB): https://bscscan.com/address/0x87b1acce6a1958e522233a737313c086551a5c76#code

Attack Flow

The following attack flow is based on this exploit transaction.

  1. The attacker borrowed 915 WBNB and deposited 116 BNB to the fBNB.
  2. The attacker created 10 addresses that will be used in the later attack.

3. The attacker called “depositInternal()” to deposit fBNB to the contract FEGexPRO LP token.

  • The record “_balances2[msg.sender]” was increased according to the balance of the current address.

4. The attacker called “swapToSwap()” with the path parameter as a FAKE address.

  • The function allows the “path” to spend 114 fBNB of the FEGexPRO. contract.

5. The attacker repeatedly called “depositInternal()” and “swapToSwap()” (Step 3 and 4) to allow multiple addresses (created in Step 2) to spend fBNB tokens. This is achievable because:

  • Every time “depositInternal()” was called, the _balance2[msg.sender] will increase approximately 114 fBNB.
  • Therefore, the attacker was able to approve 114 fBNB multiple times.

6. As the attacker controlled 10 addresses, and each of them was approved to spend 114 fBNB from the current address, the attacker was able to drain all the fBNB within the contract.

7. The attacker repeated steps 4~6 to drain the FEG token within the contract.

8. Finally, the attacker sold all the drained assets, repaid the flashloan, and gained the rest as profit.

Contracts Vulnerability Analysis

This vulnerability is due to a flaw in the “swapToSwap()” function that directly takes user input “path” as a trusted party yet without any sanitations. Furthermore, the function will approve the unprotected “path” parameter to spend the asset in the current address. Therefore, by repeatedly calling “depositInternal()” and “swapToSwap()”, the attacker is able to launch an attack that gains unlimited allowance and thus drains all the assets within the contract.

Profit and assets tracing

As of May-15–2022 10:43 PM , the funds lies in the attacker wallet(0x73b359d5da488eb2e97990619976f2f0014e9ff7c) on both Ethereum and BSC chain.

Original Funds were from Tornado cash on Ethereum and BSC: https://etherscan.io/tx/0x0ff1b86c9e8618a088f8818db7d09830eaec42b82974986c855b207d1771fdbe

https://bscscan.com/tx/0x5bbf7793f30d568c40aa86802d63154f837e781d0b0965386ed9ac69a16eb6ab

The attacker attacked 13 FEGexPRO contracts. Here is the summary:

Would we spot the issue during the audit?

In an audit, auditors would notice that the untrusted “path” parameter is passed to the protocol and approved for spending assets of the contract. This would is dangerous and would be flagegd as “Major’ severity. Furthermore, if the auditors explored deeper they would discover the exploit scenario and highlight it.

--

--

No responses yet