Hacking Incident Analysis for Safemoon

According to the information posted on the official Immunefi Twitter account, the SafeMoon contract on the BSC network environment was compromised. As a result, about $9 million from the SFM:BNB token pool was destroyed.

This article examines the hacking incident that occurred on the Fantom network.

Analysis

To begin, here is the attack transaction:

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

The attacker address and the attack contract address are the first things
we can quickly determine.

Attacker address: 0x286e09932b8d096cba3423d12965042736b8f850

Attack contract address: 0xa1fae685c8abf938eb706dedabbcffbff3b3d7da

There are two main operations under the attack contract.

The first runs a function with the signature information of 0x7d952ebb,
and the second, freeFromUpTo(), runs right after.

The process of the first transaction can be summarized as follows.

There is a peculiar aspect if you carefully look at the callback process that takes place within the swap() in the first transaction.

SafeMoon’s contract performs the burn() function internally, and the adverse aspect may be detected by inspecting the burn() function’s source code.

The internal implementation of the burn() function accepts two parameters, from and amount, and returns that value from the from address to the bridgeBurnAddress. The issue, however, is that the function is defined as a public function, making it possible for any malicious actor to send a transaction in which they use a different address as the “from” value of the burn() function’s from parameter.

The released on-the-market LP token is burned when the burn() function is used. The quantity of tokens kept in the contract’s pool is forcibly burned and deleted, nevertheless, because the from parameter passed points to the SafeMoon contract itself.

You can tell that the path starts at SafeMoon SFM and finishes at WBNB by looking at the parameters of the called swapExactTokensForTokensWithFeeAmount() function

Additionally, the attacker used the burn() procedure to remove SFM tokens from the SFM/WBNB pair pool that SafeSwap was holding, which eventually increased the token’s value.

The attacker then switched the tokens over from SFM to WBNB. As a result, the attacker makes a profit by exchanging tokens whose value has increased because of a vulnerability.

The attacker then used the withdraw() function to withdraw the WBNB and profited illegally from the exploit.

To summarize the token’s flow, consider the following:

• First, the attacker uses PancakeSwap’s flashswap to borrow WBNB funds for the attack.
• WBNB SFM tokens are purchased with some of these borrowed funds.
  Using the token pool vulnerability in SafeMoon, the SFM tokens in the pool are forcibly burnt.
• After that, the attacker exchanges the inflated SFM token for WBNB and earns a profit.
• The borrowed funds are paid back to PancakeSwap with interest, and the remaining funds are declared as unjustified gains.

The following steps were taken, as evidenced by the hacked transaction analysis:

In order to borrow money from PancakeSwap, the attacker created an exploit contract. To communicate with PancakeSwap, the attacker used a callback defined in the exploit contract.

Initially, the funds that were borrowed are used to switch tokens from WBNB to SFM, and then, immediately following the inflation, the vast quantity of gained tokens is used to convert back to WBNB.

How to avoid it

The creator of this contract must add some logic to check the recipient address supplied to the burn() function’s access authorization logic.

If the administrator or contract owner wants to access it, one strategy might be to handle that situation as an exception exclusively.