The Analysis of FEGtoken Security Incident: Devil’s in the Details

By BlockSec

On May 15th, 2022 at approximately 8:20 PM (UTC), our monitoring system detected that the FEGexPRO contract of the FEGtoken project was hacked. The attacker launched a series of attacks on both ETH and BSC mainnet and the total value involved accumulated to about $1.3m (according to the on-chain message sent by the project).

More information about this incident can be found on the official twitter of this project. In this report, we will delve into the details to reveal the root cause of this incident.

0x1 Vulnerability Analysis: At First Glance

The vulnerable FEGexPRO contract is deployed on both ETH and BSC, and the vulnerable function of the contract is swapToSwap, as follows:

As being pointed out on the social media, the first parameter named path of the swapToSwap function can be specified by the function caller. As such, the attacker could exploit it to make an arbitrary approval (see line 682 of the swapToSwap function).

Until now nothing is new, as it is yet another case of unverified parameter(s) again. However, the attack trace suggests that this attack could not be clearly illustrated by simply attributing to the arbitrary approval. As a matter of fact, there exists a subtle trick, and this is where things become interesting.

0x2 Attack Analysis

0x2.1 Preliminary Attack Analysis

We take one attack transaction on BSC as an example to illustrate the attack procedure, and the corresponding attack trace which targets the asset fBNB is briefly summarized as follows:

• Step 1: preparing funds and fake paths. The attacker borrows the flashloan about 915 BNB from DVM and swaps part of them into 116 fBNB. The attacker then creates a bunch of contracts which will be used as fake paths.
• Step 2: depositing the initial fund. By depositing 115 fBNB into FEGexPRO contract, the attacker increases his balances2 in the victim contract.
• Step 3: performing the arbitrary approval. The attacker then invokes the swapToSwap function and passes a fake path as the first parameter, which leads to the FEGexPRO contract approving the path to spend 114 fBNB.
• Step 4: making another approval by invoking the depositInternal function and the swapToSwap function. The FEGexPRO contract approves another path to spend 114 fBNB.

The attacker repeatedly launches Step 4 to make more approvals. Finally, the attacker uses the approved fake paths to drain all fBNB of FEGexPRO and swaps some to BNB to repay the flashloan.

Obviously, we can easily figure out that the contract absolutely should have checked the path parameter.

HOWEVER, to fully understand this attack, there is one more issue to address: even if the FEGexPRO contract approves the fake path, the approve operation is based on the fact that the balances2 of the user would be decreased immediately (line 684 of the swapToSwap function), i.e., the approved fund comes from exactly the amount deposited in Step 2. In other words, the attacker just approves the fund his/her own deposited fund to the fake path. After that, the attacker should not make approvals for other fake paths due to the decrease of the balances2.

As such, here raises the question: what’s the exact trick being played by the attacker to make other approvals to make extra profit?

0x2.2 Advanced Attack Analysis

To answer the question, we shall go back to the swapToSwap function. After carefully examining the code, we found that the trick played here is not only a fake path but also a fake swap, which leads to an inconsistency between the actual value and the recorded one of the victim contract's balance. As a result, the inconsistency can be used to repeatedly make the approval by invoking the depositInternal function to restore the deposit amount of the attacker.

Specifically, the depositInternal function modifies a user's balances2 mainly based on the difference between Main.balanceOf the contract and _totalSupply2 (line 651 of the depositInternal function).

Since the path address passed to the swapToSwap is a fake path controlled by the attacker, nothing is actually transferred out. As a consequence, the return value of Main.balanceOf remains the same as it is in Step 3. Note that _totalSupply2 has been decreased in the swapToSwap function, as long as the attacker deposits, the increased balance2 will inevitably be greater than the actual deposited amount.

Hence in Step 4, the attacker first restores the deposit amount by invoking the depositInternal function, and then performs the approval and fake swap by invoking the swapToSwap function. Note that the deposit amount used by the attacker is only almost 0 (i.e., 1 / 1e18) fBNB, so the depositInternal function would restore the attacker's balances2 to almost the same amount after Step 2 as explained above (which is also demonstrated by the trace of the next approval).

The attacker can enlarge the harvest by repeatedly executing Step 4.

Finally, it is worth noting that, the attack we described above is just one of the attack paths exploited by the attacker. Just in the same attack transaction, the attacker also targets the asset FEG:

0x3 The Root Cause

Here we summarize the root cause of this attack:

• First, the arbitrary approval caused by the unverified parameter in the swapToSwap function.
• Second, the inconsistency between the actual value and the recorded one of the victim contract’s balance due to the fake swap in the swapToSwap function. This is used to repeatedly make the approvals by restoring the deposit amount of the attacker.

By combining them together, the attacker successfully drained all funds from the victim contract.

0x4 Other Related Attacks

As of this writing, we also observed more related attacks launched by another attacker.

Again, contracts deployed on both Ethereum and BSC were attacked. Interestingly, the attack traces are different from the one we just discussed. Although the victim contracts are not open-sourced, we highly suspect that the attacker exploited the same vulnerability with a similar attack method.

About BlockSec

The BlockSec Team focuses on the security of the blockchain ecosystem, and collaborates with leading DeFi projects to secure their products. The team is founded by top-notch security researchers and experienced experts from both academia and industry. They have published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, and released detailed analysis reports of high-impact security incidents.

• Twitter: [BlockSecTeam]| [BlockSecAlert]
• Medium: https://blocksecteam.medium.com
• Website: https://www.blocksec.com