The Analysis of FEGtoken Security Incident: Devil’s in the Details
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
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
- Step 2: depositing the initial fund. By depositing 115 fBNB into FEGexPRO contract, the attacker increases his
balances2in the victim contract.
- Step 3: performing the arbitrary approval. The attacker then invokes the
swapToSwapfunction and passes a fake
pathas the first parameter, which leads to the FEGexPRO contract approving the
pathto spend 114 fBNB.
- Step 4: making another approval by invoking the
depositInternalfunction and the
swapToSwapfunction. The FEGexPRO contract approves another
pathto 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
HOWEVER, to fully understand this attack, there is one more issue to address: even if the FEGexPRO contract approves the fake
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
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.
depositInternal function modifies a user's
balances2 mainly based on the difference between
Main.balanceOf the contract and
_totalSupply2 (line 651 of 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
0x3 The Root Cause
Here we summarize the root cause of this attack:
- First, the arbitrary approval caused by the unverified parameter in the
- Second, the inconsistency between the actual value and the recorded one of the victim contract’s balance due to the fake swap in the
swapToSwapfunction. 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.
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.