Deep Dive: $110,000 OSN Token Exploit

Background

On May 6, 2024, the OSN token was exploited across a series of transactions on BNB chain, resulted in a loss of assets worth approximately $110,000. Let's see how attacker can do it.

OSN is a token on BNB chain, it uses ERC-20 standard but has some improvements like control liquidity, set buy/sell fees, swap token by using UniswapV2,...

The implementation of this token can be found at https://bscscan.com/address/0x810f4c6ae97bcc66da5ae6383cc31bd3670f6d13#code

Relevant Information

Attacker address: https://bscscan.com/address/0x835b45d38cbdccf99e609436ff38e31ac05bc502

Attack transaction: https://bscscan.com/tx/0xc7927a68464ebab1c0b1af58a5466da88f09ba9b30e6c255b46b1bc2e7d1bf09.

We will focus on one transaction. All attack transactions can be found at https://bscscan.com/address/0x835b45d38cbdccf99e609436ff38e31ac05bc502#tokentxns

Cause of the Attack

The root problem come from a logic flaw on reward mechanism which was implemented in contract `LpDividendTracker`. This contract didn't check the LP token hold time - which is used to calculate rewards, it also didn't check the receiver is contract or not. Attacker detected this problem and use multiple contract attack to get huge amount of rewards.

Exploit Analysis

The vulnerability originated from the `_transfer` function within the OSN token contract.

Specifically, if the destination address for the transfer was a liquidity pool address, the function would then invoke the `swapAndSendDividends` function. This function was responsible for selling the OSN tokens. Concurrently, during this process, BUSD tokens would be transferred to the `OSNLpDividendTracker` contract. This sequence of operations, triggered by the transfer to a liquidity pool address, revealed the underlying vulnerability in the contract's code.

When `OSNLpDividendTracker` contract receives BUSD as the liquidity pool (LP) token, it uses OSN tokens as rewards. The main problem here is that it didn't check LP token hold time, so the reward for each distribution is the same. As a result, an attacker could repeatedly buy and sell tokens to accumulate a substantial amount of rewards in the `OSNLpDividendTracker`. During the attack transactions, the attacker frequently called the methods `swapExactTokensForTokensSupportingFeeOnTransferTokens` and `swapTokensForExactTokens` numerous times to exploit the vulnerability.

Another problem in `OSNLpDividendTracker` contract is that it does not verify whether an address is an externally owned account (EOA) or a contract address. This oversight allows for potential exploitation: Attacker can create numerous contracts and use these to add liquidity to the pool. By combining this with the vulnerability in the `_transfer` function, the attacker can accumulate a significant amount of rewards.

To perform this strategy, attacker generated about 15 txs to attack, and stole approximately $110,000.

Exploit step by step:

1. Generate help contracts and send USDT to these contracts.

2. Use the contracts we created to add liquidity.

3. Repeatedly swap tokens to accumulate rewards.

4. Withdraw to receive rewards.

Conclusion

The main emphasis should be on the vulnerable functions essential for reward distribution. These functions need to be redesigned to prevent exploitation, where tokens can be sold in bulk, giving an unfair advantage to any single entity or group. This is especially important to avoid scenarios where rapid transactions can be orchestrated to manipulate reward results.

To avert future exploits, it's essential to add more checks and balances to the transfer and reward systems. For example, introducing a mechanism that restricts the number and total volume of transactions an individual address can initiate within a specified period could help prevent rapid exploitation cycles.