By: yudan@slow fog security team

secondary title

Analysis of attack details

BurgerSwap is a Uniswap-like AMM project, but it is different from Uniswap architecture. The BurgerSwap architecture is generally divided into [Delegate -> lpPlatForm -> Pair]. The Delegate layer manages all Pair information and is responsible for creating the lpPlatForm layer. Then the lpPlatForm layer goes down to create the corresponding Pair contract. Throughout the architecture, the lpPlatForm layer acts as a router in Uniswap, responsible for forwarding the calculated transaction data and tokens to be exchanged to the Pair contract to complete the exchange.

The root of this incident lies in the problem of this structure. By analyzing the attacker's transaction behavior step by step, we will restore the core of the entire attack process:

This attack started with Pancake's flash loan. The attacker borrowed a large amount of WBNB from Pancake, and then converted these WBNB into Burger tokens through BurgerSwap. After completing the above operations, the attacker uses the tokens he controls (the attack contract itself) and Burger tokens to create a transaction pair through the Delegate layer and add liquidity to prepare for subsequent attacks.

After completing the creation and preparation of tokens, the attacker immediately initiates the exchange through the swapExactTokensForTokens function of the PaltForm layer, and the exchange path is [token controlled by the attacker -> Burger -> WBNB]

Next came the most critical operation.

Since the attacker used the tokens controlled by himself when creating the transaction pair, during the token exchange process, the _innerTransferFrom function will call the token contract controlled by the attacker, so the attacker can re-enter the swapExactTokensForTokens function in the _innerTransferFrom function . Why would an attacker do this?

By analyzing the code of the swapExactTokensForTokens function of the PlatForm layer, it is not difficult to find that the contract first calculates the user's exchange data when calling the _innerTransferFrom function, and then uses the pre-calculated data to forward to the bottom layer after the operation of the _innerTransferFrom function. token exchange. From the perspective of this function, even if the attacker re-enters the swapExactTokensForTokens function, the swap function called by the underlying layer is also independent. At first glance, there is no problem, but a behavior on the chain has attracted the attention of the SlowMist security team:

We were surprised to find that during the redemption process, the number of exchanges did not decrease due to slippage. What is the reason? It seems that the key is the problem of the underlying Pair contract. We further analyzed the Pair contract called by the bottom layer, the code is as follows:

Summarize

Summarize

This attack is a problem in the BurgerSwap architecture. Since the Pair layer completely trusts the data in the PaltForm layer and does not perform another check by itself, the attack occurs. DeFi security incidents have occurred frequently recently. In view of the increasingly intensive DApp attacks, the SlowMist security team recommends that DApp developers need to fully understand the architecture of the transplant protocol when transplanting code from other protocols, and fully consider the porting protocol and their own projects. Compatibility, and it needs to pass the audit of a professional security audit organization before going online to prevent financial loss.

Attack transaction reference:

https://bscscan.com/tx/0xac8a739c1f668b13d065d56a03c37a686e0aa1c9339e79fcbc5a2d0a6311e333