Analysis of the Flash Loan Attack Incident on Cellframe Network

On June 1, 2023, at 10:07:55 (UTC+8), Cellframe Network was hacked on a certain smart chain due to a token quantity calculation issue during the liquidity migration process. It is reported that the hacker profited $76,112 from this attack.

Analysis of Attack Process

The attacker first obtained 1000 native tokens of a certain smart chain and 500,000 New Cell tokens through Flash Loans. Subsequently, the attacker exchanged all New Cell tokens for native tokens, causing the amount of native tokens in the trading pool to approach zero. Finally, the attacker exchanged 900 native tokens for Old Cell tokens.

It is worth noting that the attacker first added liquidity of the Old Cell and native tokens before launching the attack, obtaining the Old lp tokens.

Next, the attacker invoked the liquidity migration function. At this point, there are almost no native tokens in the new pool, and almost no Old Cell tokens in the old pool. The migration process includes the following steps:

1. Remove old liquidity and return the corresponding amount of tokens to the user.
2. Add new liquidity according to the proportion of the new pool.

Due to the lack of Old Cell tokens in the old pool, the amount of native tokens obtained when removing liquidity increases, while the number of Old Cell tokens decreases. This causes users to only need to add a small amount of native tokens and New Cell tokens to obtain liquidity, while the excess native tokens and Old Cell tokens are returned to the users.

Finally, the attacker removes the liquidity from the new pool and exchanges the Old Cell tokens returned from the migration for native tokens. At this point, there are a large number of Old Cell tokens in the old pool but no native tokens, and the attacker exchanges the Old Cell tokens back into native tokens, thereby completing the profit. The attacker then repeats the migration operation to further expand the earnings.

Root Cause of the Attack

The root cause of this attack lies in the calculation issues during the liquidity migration process. When migrating liquidity, the project party directly calculates based on the quantities of the two tokens in the trading pair, which makes this method susceptible to manipulation by attackers.

Security Advice

1. When migrating liquidity, one should comprehensively consider the changes in the quantities of the two tokens in the old and new pools as well as the current token prices, rather than simply calculating the number of tokens.

2. A comprehensive security audit should be conducted before the code goes live to identify and fix potential vulnerabilities.

This incident reminds us once again that when designing and implementing complex financial operations, special attention needs to be paid to security and robustness to prevent potential attacks and vulnerabilities from being exploited.