The Anatomy of a Crypto Heist: Dissecting The Attack on Stars Arena

On October 7, 2023, the SocialFi application, Stars Arena was attacked. They announced on Twitter that the funds in the contract were drained by the attacker, resulting in a loss of approximately 2.9 million USD (https://twitter.com/starsarenacom/status/1710604987812708531).

A few hours later, Stars Arena tweeted that they have obtained funds to compensate for the losses caused by the vulnerability and invited white hat development teams to quickly review the platform’s security. The new contract will be relaunched after a comprehensive security audit (https://twitter.com/starsarenacom/status/1710666706262138953).

The essence of this attack lies in the presence of a reentrancy vulnerability in the project’s contract, allowing the attacker to steal a significant amount of AVAX tokens from the contract of the project. Below, we will provide a detailed analysis of the attack path.

Attack analysis

Background

About Stars Arena
Stars Arena is a SocialFi project similar to Friend.Tech, deployed on the Avalanche blockchain. On Stars Arena, users can log in with their own crypto wallets and directly purchase shares of accounts belonging to creators they are interested in. These shares can be likened to tickets or stocks issued by creators. By holding shares of a creator, users gain access to the exclusive groups established by the creators. Users can also create their own shares for others to purchase.
One of the reasons why SocialFi projects like Stars Arena have gained popularity is that the shares are tradable, and the value of these shares may appreciate over time. In other words, users have the opportunity to make profits by trading shares. Additionally, Stars Arena has received strong support from the Avalanche official team and its founder, Emin Gün Sirer. Both the official Avalanche account and Emin Gün Sirer himself have joined Stars Arena. Before the attack took place, the Total Value Locked (TVL) in the project was close to $3 million.

Profit sharing mechanism
In Stars Arena, a 10% transaction fee is charged for buying and selling shares. Out of this, 7% is allocated as the subject fee to creators, 2% is allocated as the protocol fee to the platform, and 1% is allocated as the referral fee to the referrer. However, during our decompilation and analysis of the project contract, we discovered that the referrer’s address can be left unset during the buying and selling process, in which case the referral fee will also be transferred to the platform.

Key Addresses Involved in the Attack

Attacker’s Address：

0xa2ebf3fcd757e9be1e58b643b6b5077d11b4ad7a

Attack Contract：

0xdd9afc0e3c43951659c8ebe7aef9ee40879863ea

Proxy Contract of Stars Arena：

0xa481b139a1a654ca19d2074f174f17d7534e8cec

Implementation Contract of Stars Arena (Vulnerable)：

0x8af92c23a169b58c2e5ac656d8d8a23fc725080f

Analysis of Attack Process

Attack Process

（https://explorer.phalcon.xyz/tx/avax/0x4f37ffecdad598f53b8d5a2d9df98e3c00fbda4328585eb9947a412b5fe17ac5）
Based on the decompilation of the Stars Arena contract and analysis of the attack transaction (https://snowtrace.io/tx/0x4f37ffecdad598f53b8d5a2d9df98e3c00fbda4328585eb9947a412b5fe17ac5), we have outlined the process and principles of this attack. The attack process can be divided into three main stages: attack preparation, reentrancy, and profiting, following a timeline. Detailed Analysis of Attack Process is as follows:

Attack Preparation

1. The attacker deployed the attack contract at the address 0xdd9afc.
2. The attacker purchased shares.

The attacker bought shares by invoking a function with the signature 0xe9ccf3a3 in the vulnerable contract of Stars Arena. Through decompilation, we have discovered that this function serves a similar purpose to buyShares in Stars Arena, as it is used to purchase shares for a specified address. The difference is that 0xe9ccf3a3 allows the setting of a referrer. The three parameters of the 0xe9ccf3a3 function represent the creator, the desired amount of shares to purchase and the referral address, respectively. The actual parameters passed by the attacker were the address of the attack contract 0xdd9afc, the desired amount of shares to purchase, and the address of the attack contract 0xdd9afc as the referral address. The workflow analysis is as follows:

• In the function 0xe9ccf3a3, the attacker passed the non-zero varg2 as the address of the attack contract. Therefore, it entered the function 0x326c to set the referrer (line 4 in Figure. 1). It passed the address of the attack contract and the caller’s address (i.e., the address of the attack contract) to the function 0x326c.

Figure. 1. Decompiled Function 0xe9ccf3a3

• In the function 0x326c (Figure. 2), varg0 corresponds to the referral address, and varg1 corresponds to the caller (the referred address). In Figure 2, the state variable owner_a2 is used to track the mapping between the referrer and the referred address. Firstly, in lines 2-3, the code checks if there is no existing referrer for the address of the attack contract. If there is no referrer, then in line 4, it checks if the referrer and the referred address are the same. Since both the referrer and the referred address were the address of the attack contract, v0 was set to 0. As a result, the condition in line 6 evaluated to true, and the code directly returned in line 7, bypassing the code in line 10 that would assign the referrer to the owner_a2 state variable. In summary, the setting of the referrer failed.

Figure. 2. Decompiled Function 0x326c

• After the execution of the 0x326c function, the execution flow returned to line 6 of the function 0xe9ccf3a3, where the function 0x2058 was called to execute the specific share purchase logic. The parameters passed to the function 0x2058 are the amount of shares to purchase (1 AVAX) and the address of the creator (the address of the attack contract).
• In the private function 0x2058，
  • In the 2nd line, the 0x1a9b function is called to calculate the value of the shares (v0).
  • In the 3rd, 4th, and 5th lines, the function calculates the protocolFee (fee transferred to the platform), subjectFee (fee transferred to the creator), and referralFee (fee transferred to the referrer) that the buyer needs to pay.
  • In line 6, the protocolFee (0.00012 AVAX) is transferred to the platform address.
  • In line 7, the subjectFee (0.00042 AVAX) is transferred to the creator (the attack contract). This triggered the fallback function of the attack contract. In the fallback function, the attacker re-entered the 0x5632b2e4 function of the Stars Arena’s vulnerable contract (without a reentrancy lock) to modify the weight coefficient (details will be explained later).
  • In line 14, a refund operation is performed. After deducting the fees for the purchased shares, subjectFee, protocolFee, and referralFee, any excess AVAX will be returned to the sender of the transaction.
  • In line 17, the 0x2f7b (shown in Figure. 4) is called, passing the parameters referralFee and the caller’s address (i.e., the address of the attack contract). In Figure 4, in the 2nd line, the code retrieves the referrer of the caller from the owner_a2 state variable. As mentioned before, the setting of the referrer failed, so v0 was set to 0 in this case. Therefore, it proceeded to the 5th line and transfers the referralFee (0.00006 AVAX) to the platform.
  • In line 21 of Figure 3, an accounting operation is performed, indicating that the shares have been issued.

Figure. 3. Decompiled Function 0x2058

Figure. 4. Decompiled Function 0x2f7b

Reentrancy and Modification of Weight Coefficients

In line 7 of function 0x2058 in Figure. 3, during the process of transferring subjectFee (0.00042 AVAX) to the creator (attacker contract), the fallback function of the attack contract was triggered. Due to the lack of reentrancy protection in the 0x5632b2e4 function of the Stars Arena vulnerable contract, the attacker was able to reenter the 0x5632b2e4 function in the fallback function and modify the weight coefficients, enabling them to obtain a large amount of AVAX when selling shares in the future. The attacker called the 0x5632b2e4 function with all four parameters set to 91000000000. A detailed process analysis is as follows:

• In line 3 of Figure. 5, the function 0x5632b2e4 first checks whether the shares have been issued. However, since the attacker has reentered this function, the code used for accounting in line 21 of Figure. 3 has not been executed yet. As a result, the shares purchased by the attacker are still considered to be in the “unissued” state, allowing the attacker to pass this check.
• In lines 4 to 6, the function checked the legality of the passed weight coefficients.
• In lines 7 to 9, the function set the three weight coefficients to the parameters passed by the attacker.

Figure. 5. Decompiled Function 0x5632b2e4

Sell Shares and Get Large Profits

After the reentrancy attack, the weight coefficients have been modified by the attacker to 91000000000. At this point, the attacker calls the sellShares function of the Stars Arena vulnerable contract in the attack contract. After selling shares, the attacker obtained 266103.97278 AVAX. The parameters passed to the sellShares function by the attack contract are as follows: the attack contract address and the amount of shares (1 AVAX). The detailed analysis process is as follows:

• In line 3 of Figure. 6, the function 0x1a9b is called to calculate the value of the shares, v1. This value has an approximately linear relationship with the weight coefficients set by the attacker. Therefore, the calculated value v1 is very large, exceeding 260,000 AVAX.
• In lines 4, 5, and 6, the function calculates the protocolFee (fee paid to the platform), subjectFee (fee paid to the creator), and referralFee (fee paid to the referrer) respectively for selling the shares.
• In lines 8 to 10, the function calculates the amount of AVAX that should be transferred to the seller after deducting the transaction fees.
• In line 11, the internal function 0x30ef is called to transfer 246899.6712 AVAX (calculated in line 10) to the seller (i.e., the attack contract).
• In line 12, the protocolFee (5486.65936 AVAX) is transferred to the platform address.
• In line 13, the subjectFee (19203.30776 AVAX) is transferred to the creator (attack contract).
• In line 15, the function 0x2f7b in Figure. 4 is called with parameters referralFee and the caller’s address (i.e., attack contract address). In Figure. 4, the referrer of the caller from the state variable owner_a2 was retrieved in line 2. As mentioned earlier, the referrer was not set successfully, so v0 is 0 in this case. Therefore, it proceeded to line 5, where the referralFee (2743.32968 AVAX) is transferred to the platform.

Figure. 6. Decompiled Function sellShares

Stolen Funds Tracing

Attacker’s address:

0xa2ebf3fcd757e9be1e58b643b6b5077d11b4ad7a

Attacker’s money laundering transaction:

https://snowtrace.io/tx/0x8f5b2e8869260d6854ce4c93f58dfcbf6e8fb18b96c3e76db1eeb6dce0ef9fb1

Attacker created contract 0xef606558483954e5ab40429210da3429d3d12978 to perform coin mixing operations, distributing the stolen 266,000 AVAX tokens evenly among 266 addresses, with each address receiving 1,000 AVAX. Currently, the 1,000 AVAX remains in these 266 addresses without any further activity.

Recommendations

1. During the contract development process, it is important to use reentrancy guards correctly and follow the “Transfer after Effect” pattern. This helps mitigate the risk of reentrancy attacks.
2. Prior to project deployment, it is strongly recommended to engage professional smart contract security experts for a thorough security audit.
3. We recommend that project teams release their source code to facilitate user understanding of contract security. Additionally, implementing a bug bounty program can incentivize the security community to help identify and address contract risks. It has been proven that closed-source contracts do not necessarily enhance project security; in fact, they can be detrimental.

---

• ← Previous Post
• Next Post →