Partnered With:

Fairyproof analysis: A case of a sandwich trading bot being attacked.

Read this article in 10 Minutes

The suspected reason for the attack is insufficient function call permission verification.

The content to be translated is:

Source: Fairyproof

(Note: As per the instructions given, I have not translated the HTML tags and the English words mentioned in the text.)

Sandwich robot trading is a very common transaction behavior in the daily transactions of the blockchain ecosystem. Trading through robots can not only greatly improve transaction efficiency, but also quickly discover arbitrage opportunities in transactions.

Secure robot trading can certainly achieve the above goals, but insecure robot trading may "lose the rice instead of stealing the chicken." On August 29, 06:04:39 UTC, there was a case of a sandwich trading robot being attacked on the BNB Chain.

In this case, the attacked trading robot lost a total of 207 WBNB, 184900 BSC-USD, and 158900 BUSD, with a total asset value of approximately $390,000.

Fairyproof conducted an analysis of the incident at the earliest opportunity and found that the attack was suspected to be due to insufficient function call permission verification.

Usually in DEX (decentralized exchange) chain transactions, in order to save gas, trading robots will directly interact with the trading pairs instead of going through the DEX Router contract. In DEX based on Uniswap trading logic, the trading pairs are borrowed first and then returned, that is, the specific callback function of the trader (in this case, pancakeV3SwapCallback) is called to notify the trader that the token has been borrowed and the trader needs to take relevant actions to return the borrowed token.

Therefore, it is necessary to verify the caller (msg.sender) of the callback function pancakeV3SwapCallback in the trading contract as the true trading pair and initiator (tx.origin) of the transaction. Due to the relatively complex verification of msg.sender (sometimes considering compatibility with Uniswap V2 leading to complex verification logic), most contracts only verify tx.origin.

Usually this is not a problem. However, if a step in the transaction involves a malicious contract (in this case, attacking the token contract), there is a risk because tx.origin can be validated through permission when the malicious contract calls pancakeV3SwapCallback.

In this incident, the attacker directly called the pancakeV3SwapCallback function and forged transaction parameters by not verifying whether msg.sender was the pancakeV3 trading pool. As a result, they passed the tx.origin verification and stole assets.

During this attack, the relevant hash values for sandwich trading are as follows:

The contract address of the Sandwich Robot is as follows:

· Executing contract (with vulnerabilities): 0x5C936E535Bb591C979a7c8D36C48a6B31808Cef9

· Insurance Vault Contract: 0x6E47b1123ddcF74E853516F934f5296cEb17D404

The contract address for the attack token is: 0xb4864E14467B0D1a2AfB1F70b3f04D4aCd635e06.

Address attacking token trading pair: 0xf61F401041a1AF03875B0E0d4AAa9749a57AEB93

Attacker's address: 0x30BA49Ca659B70d3723E3cA6ed96EA4EF0249893.

The main internal transaction process of this attack is shown in the following figure:

Note that the above picture is taken from here.

From the above process, we can analyze the specific steps of attacking transactions as follows:

Step 1: The attacker deploys the attack token contract and prepares for the attack, initiating a purchase transaction exposed to the Sandwich trading bot.

Step 2: The Sandwich Robot calls the swap function of the PancakeV3 trading pool 0xf61F401041a1AF03875B0E0d4AAa9749a57AEB93 in FrontRun to obtain the attack token.

Step 3: Transfer the attack token to the Sandwich Bot (Uniswap's flash loan mechanism) in transaction pool 0xf61F401041a1AF03875B0E0d4AAa9749a57AEB93. This process will call the transfer function of the attack token.

Step 4: Attack the transfer function of the token and call the pancakeV3SwapCallback() function of the Sandwich Robot, along with forged request parameters.

Step 5: The pancakeV3SwapCallback() function of the sandwich robot passes the tx.origin verification, and then transfers assets from the insurance pool to the attacking token contract (because the pancakeV3SwapCallback function usually sends assets to msg.sender).

Step 6: The normal sandwich trading process follows. The Sandwich robot earns about 25 USDC in profit.

Step 7: The attacker extracts various assets stolen from the token contract. The stolen assets extracted include WBNB, BSC-USD, and BUSD as shown in the following figure:

Note that the above picture is taken from here.

This attack warns contract developers that it is necessary to verify the caller's permissions when calling the contract interface, that is, to verify msg.sender. It is not enough to only verify tx.origin.

In similar scenarios, Fairyproof suggests first verifying tx.origin, and then verifying one of the following two situations:

1. When calling the external interface of the contract to initiate a transaction, write the address of the transaction pair into the contract and verify it in the callback function. After the transaction is executed, reset the transaction pair parameter. Although this operation will consume additional gas, it can greatly improve security.

2. Fix the Factory address in the contract, calculate the corresponding transaction pair address in the callback function, and perform the corresponding verification.

In addition, auditing contracts is a necessary step to ensure project security. The security incidents mentioned in this example could have been discovered and avoided through security audits.

Fairyproof provides professional, comprehensive, and rigorous security services for the blockchain ecosystem, including contract auditing, security consulting, security solutions, real-time monitoring, and stolen asset tracking. We have always been committed to working hand in hand with partners in the ecosystem to build a secure ecological environment and protect users' encrypted assets.