TL;DR

On April 18 2022, the 2OMB team commissioned an audit of their new decentralized exchange project called Redemption. Later that day, the project suffered from a massive coordinated flash loan attack resulting in the loss of approximately 4 million 2OMB tokens, or $1,600,000 in equivalent, at the peak of the attack.

Event Summary

On April 18 2022, at 11:35:31 AM +UTC, the Redemption-LP experienced flashloan arbitrage attacks, causing approximately $1,600,000 loss. The incident stems from the vulnerability that no fee is charged before the flashloan is repaid, and corresponding token were directly transferred to the distributor from the Redemption-LP Pair, which leads to the price difference between ​Redemption-LP and other normal Pairs. During the attack, the price of its own tokens tripled due to malicious interference.

The project that utilized Redemption for FTM-based "yield farming" confirmed the attack on their social media accounts that same day and recommended its users to remove liquidity immediately but restrain from selling native assets 2OMB amd 3OMB.

Attack Technical Analysis

Transaction 0xb134f5d0609863aeaab8b8aeb77765a7a0f1e6a379c27455845e46d2261c46a9 is used as explanation.

Step 1:

The attacker repeatedly consumed 2OMB tokens in the 2omb-WFTM RedemptionPair to increase the price of 2OMB in the 2omb-WFTM RedemptionPair:

1. The attacker flashloaned multiple 2OMB and repaid the flashloan immediately
2. As there is no fee applied (feeAmount = 0), the attacker does not need to pay any fees before repay the flashloan. After the flashloan was repayed, a certain amount (3%) of 2OMB tokens will be taken out of the RedemptionPair and transferred to the 2OMB DistributiorV2.
3. Therefore, by repeating steps 1~2, the attacker can use flashloan to take 2OMB tokens out of the pool, thus increasing the price of 2OMB tokens in the RedemptionPair.

Step 2:

As the price of 2OMB in the RedemptionPair has been increased, the attacker can buy 2OMB in a normal pool (for example, Spooky LP Pair) with normal price. And then sell 2OMB in the RedemptionPair with higer price.

Exploited contracts

1. WFTM-2OMB Redemption LP: 0x5D5...
2. WFTM-2SHARE Redemption LP: 0x7F7...
3. 3OMB-WFTM Redemption LP: 0xf5f...
4. WFTM-3SHARE Redemption LP: 0xbA7...
5. DEVIL-WFTM Redemption LP: 0x0c2...

Contract Vulnerability Analysis

The root cause of this exploit is a design flaw of the swap function in the RedemptionPair contract. The modified swap function from the Uniswap V2 introduces two new features, one of which is the feeAmount is a variable(the default value is 0). The other is the caller of the swap function needs to pay the controller fee. __However, the controller fee is paid after the K invariant check and is directly transferred out from the pool to the controller fee address. __

Since the controller fee address has not been set as ZERO address, then the transferred amount from the current pool is nonzero, which will cause imbalance of prices in the Redemption pool. The attacker repeatedly calls the swap function to send the token to himself/herself to amplify the imbalance of the price in the Redemption pool. Eventually, the attacker utilizes the Uniswap V2 pair to buy the tokens (in fair price) and sells them in the Redemption pool to make profits.

The controller fee is sent from the pool to the controller fee address after the above swap.

Would we spot the issue during the audit?

Yes, we would probably find out this Uniswap pair contract is quite different from the original Uniswap/PancakeSwap V2 pair.