How did I fool myself? — BurgerSwap Hacking Analysis

The Slow Fog security team suggests that when porting the code of other protocols, DApp developers should fully understand the architecture of the ported protocols and fully consider the compatibility between the ported protocols and their own projects, and should pass the audit of professional security auditors before going online to prevent the loss of funds.

By: yudan@Slow Fog Security Team

How did I fool myself? -- BurgerSwap Hacking Analysis

According to Slow Fog, on May 28th, 2021, BurgerSwap, a DeFi project of Coin Smart Chain (BSC), was hacked with a loss of $3.3 million. The Slow Fog security team first intervened to analyze and share the results as follows.

Analysis of the attack details

BurgerSwap is an imitation of Uniswap AMM project, but different from the Uniswap architecture, the BurgerSwap architecture is divided into [Delegate -> lpPlatForm -> Pair]. The Delegate layer manages all the information of the Pair and is responsible for creating the lpPlatForm layer. The lpPlatForm layer then creates the corresponding Pair contracts down the line. In the whole architecture, the lpPlatForm layer acts as a Router in Uniswap and is responsible for forwarding the calculated transaction data and the tokens to be exchanged to the Pair contract to complete the exchange.

How did I fool myself? -- BurgerSwap Hacking Analysis

The root of this incident lies precisely in the problem of this architecture. By analyzing the attacker’s transaction behavior step by step, let’s restore the core of the whole attack process.

How did I fool myself? -- BurgerSwap Hacking Analysis

The attack begins with a lightning loan from Pancake, where the attacker lends a large amount of WBNBs from Pancake and then converts these WBNBs into Burger tokens via BurgerSwap. After doing so, the attacker uses the tokens under his control (the attack contract itself) and the Burger tokens to create a transaction pair through the Delegate layer and add liquidity in preparation for the subsequent attack.

How did I fool myself? -- BurgerSwap Hacking Analysis

After completing the creation and preparation of the tokens, the attacker immediately initiates the exchange through the swapExactTokensForTokens function in the PaltForm layer, with the exchange path [Attacker-controlled tokens -> Burger -> WBNB].

How did I fool myself? -- BurgerSwap Hacking Analysis

Next, the most critical operation is performed.

Since the attacker previously used a token under his control when creating the transaction pair, the _innerTransferFrom function calls the token contract under the attacker’s control during the token exchange process, so the attacker can reinsert the swapExactTokensForTokens function into the _innerTransferFrom function. Why would an attacker want to do this?

How did I fool myself? -- BurgerSwap Hacking Analysis

By analyzing the code of the swapExactTokensForTokens function in the PlatForm layer, it is easy to see that the contract first calculates the user’s exchange data when calling the _innerTransferFrom function, and then uses the The pre-calculated data is then used to forward to the underlying layer for the real token exchange. From this function level, even if the attacker reentered the swapExactTokensForTokens function, the underlying swap function was called independently, which did not seem to be a problem at first glance, but one behavior in the chain caught the attention of the Slow Fog security team.

How did I fool myself? -- BurgerSwap Hacking Analysis

We were surprised to find that during the re-entry redemption process, the number of redemptions did not decrease due to slippage. What is the reason for this? It seems that the key is the underlying Pair contract. We further analyzed the underlying Pair contract call, and the code is as follows.

How did I fool myself? -- BurgerSwap Hacking Analysis

By analyzing Pair’s code, we are again surprised to find that during the swap process, the contract does not check the converted value against the constant product formula after the swap! In other words, the Pair contract completely relies on the data in the PlatForm layer to perform the swap, leading to this incident. Since the Pair layer itself does not check the constant product, the exchange data in the PlatForm layer is pre-calculated during the re-entry process, and the updated data of the Pair is not reflected in the PlatForm layer after the completion of the _innerTransferFrom function, the slippage generated by the exchange in the re-entry transaction does not affect the next exchange. The slippage in the reentrant transaction does not affect the next exchange, which results in a loss.

Summary

This attack is a problem of BurgerSwap architecture, because the Pair layer completely trusts the data of PaltForm layer and does not do another check by itself, which leads to the attack. Recently, DeFi security incidents are frequent, and in response to the increasingly intensive DApp attacks, Slow Fog security team suggests that DApp developers should fully understand the architecture of the ported protocol and fully consider the compatibility between the ported protocol and their own projects when porting the code of other protocols, and should pass the audit of professional security auditors before going online to prevent the occurrence of capital loss.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/how-did-i-fool-myself-burgerswap-hacking-analysis/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2021-05-28 12:21
Next 2021-05-28 12:31

Related articles