According to a security alert from the SlowMist MistEye system, on October 7, 2023, the Stars Arena social protocol on the Avalanche blockchain suffered an attack, resulting in a loss of approximately $2.9 million. Our security team has conducted a brief analysis of this attack and these were our findings:
Cause of the Attack
The attacker exploited a reentrancy vulnerability to manipulate the price corresponding to their deposit amount. During the sell-off, this malicious price manipulation was carried forward due to the dependency on the manipulated price for calculations. By precisely calculating the updated share price during the reentrancy, the attacker managed to siphon off funds from the contract.
We can observe a reentrant call within the attack transaction. Through decompiling the code, we step-by-step analyze the calling method.
The attacker initially created attack contracts (0x7f283 and 0xdd9af), and through these contracts, invoked the method 0xe9ccf3a3 of the Stars Arena: Shares contract, subsequently depositing 1 AVAX token.
Based on the decompiled code traced step by step, the attacker initially used the method 0xe9ccf3a3, which functions similarly to a deposit function. Within this method, the methods 0x326c and 0x2058 are invoked. The method 0x326c serves merely as a call returning parameters, while the method 0x2058 operates similarly to a function processing a certain token purchase or exchange. This method utilizes the amount of AVAX tokens and address passed in by method 0xe9ccf3a3 for subsequent operations, as well as the calculation of shares and fees.
Following the call logic in line 92 of the method 0x2058, it can be discovered that the method 0x1a9b serves as a calculation function, deriving a result similar to a price value. The returned value is either the newly calculated v24 / 0xde0b6b3a7640000 or _initialPrice.
Subsequently, in lines 109, 110, and 116, the methods 0x307c and 0x30ef entail low-level call invocations. The call in method 0x30ef is an external call to varg1, which corresponds to the provided 0xdd9af attack contract address. The function lacks reentrancy lock constraints, and only after the execution of the external call does this method proceed to the subsequent if statement to update the field0.length and field0 parameters. Undoubtedly, the reentrancy occurs right here.
Let’s now look at the data constructed by the attacker during the reentrant call.
The external call during reentry is for method 0x5632b2e4, with four parameters constructed by the attacker, which are converted from hexadecimal 153005ce00 to decimal 91000000000.
As mentioned above, the external call to method 0x5632b2e4 is executed before the if (varg0 == _getMyShares[address(varg1)][msg.sender]) check. At this point, the value of field0.length is 0, and has not been updated yet. The attacker cleverly bypasses the check in method 0x5632b2e4 through this mechanism, modifying the four parameter states of the attack contract 0xdd9af (which is the msg.sender) to the data constructed during the external call.
Following the aforementioned operations, the attacker invoked the sellShares function to sell their shares, thereby acquiring 266,102.97278 AVAX tokens.
Delving into the sellShares function, it initially invokes the method 0x1a9b, which, as previously seen in method 0x2058, deals with some form of token purchase or exchange. It’s notable that within method 0x1a9b, the method 0x2329 updates owner_9f[varg0], a parameter which was altered to the attacker-constructed value of 91000000000 during the reentry.
Revisiting method 0x1a9b, the maliciously constructed value is recalculated (with the calculation details noted in the comments).
Through these calculations, the price corresponding to the newly computed shares is altered, resulting in a value of 274,333.061476814e18. After a series of fee deductions, the attacker, without modifying the share amount and utilizing the maliciously manipulated price, sells the shares and steals from this attack.
The main cause of this attack lies in the reentry-induced price calculation dependency update, which led to a form of malicious price manipulation. The SlowMist security team recommends that project teams should deploy contracts only after audits by multiple security firms have been conducted. Additionally, it’s advisable to adhere to the Checks-Effects-Interactions coding standard and incorporate reentrancy locks during coding to mitigate such vulnerabilities.
SlowMist is a blockchain security firm established in January 2018. The firm was started by a team with over ten years of network security experience to become a global force. Their goal is to make the blockchain ecosystem as secure as possible for everyone. They are now a renowned international blockchain security firm that has worked on various well-known projects such as Huobi, OKX, Binance, imToken, Crypto.com, Amber Group, Klaytn, EOS, 1inch, PancakeSwap, TUSD, Alpaca Finance, MultiChain, Cheers UP, etc.
SlowMist offers a variety of services that include by are not limited to security audits, threat information, defense deployment, security consultants, and other security-related services. They offer AML (Anti-money laundering) software, Vulpush (Vulnerability monitoring) , SlowMist Hacked (Crypto hack archives), FireWall.x (Smart contract firewall) , Safe Staking and other SaaS products. They have partnerships with domestic and international firms such as Akamai, BitDefender, FireEye, RC², TianJi Partners, IPIP, etc.
By delivering a comprehensive security solution customized to individual projects, they can identify risks and prevent them from occurring. Their team was able to find and publish several high-risk blockchain security flaws. By doing so, they could spread awareness and raise the security standards in the blockchain ecosystem.