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).
@FEGtoken The paramter `path` in your FEGexPRO contract (0x818E2013dD7D9bf4547AaabF6B617c1262578bc7) should be checked in advance ! Our monitor system just reports an attack against the FEGexPRO contract, which lost its fBNB and FEG. pic.twitter.com/A4obANAMhW
— BlockSec (@BlockSecTeam) May 16, 2022
More infromation 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 fakepaths
. - 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 fakepath
as the first parameter, which leads to the FEGexPRO contract approving thepath
to spend 114 fBNB. - Step 4: making another approval by invoking the
depositInternal
function and theswapToSwap
function. The FEGexPRO contract approves anotherpath
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 3. 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 in Step 3 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.
ROX(https://t.co/NWvSy5faY3) is not open-sourced, but something is wrong.
— BlockSec (@BlockSecTeam) May 17, 2022
Take a look at the following transaction:https://t.co/chPxcDoFOD@Mudit__Gupta
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.
0x5 Takeaway
Making a DeFi project secure is not an easy job. Besides the code audit, we think the community should take a proactive method to monitor the project status, and block the attack before it even takes place.
About BlockSec
BlockSec is a pioneering blockchain security company established in 2021 by a group of globally distinguished security experts. The company is committed to enhancing security and usability for the emerging Web3 world in order to facilitate its mass adoption. To this end, BlockSec provides smart contract and EVM chain security auditing services, the Phalcon platform for security development and blocking threats proactively, the MetaSleuth platform for fund tracking and investigation, and MetaDock extension for web3 builders surfing efficiently in the crypto world.
To date, the company has served over 300 esteemed clients such as MetaMask, Uniswap Foundation, Compound, Forta, and PancakeSwap, and received tens of millions of US dollars in two rounds of financing from preeminent investors, including Matrix Partners, Vitalbridge Capital, and Fenbushi Capital.
Official website: https://blocksec.com/
Official Twitter account: https://twitter.com/BlockSecTeam