Background
According to the SlowMist MistEye system security alert, on October 7, 2023, the Avalanche chain social protocol Stars Arena was attacked, resulting in a loss of approximately 2.9 million US dollars. The SlowMist security team has analyzed the attack event and shared the results as follows.
Relevant Information
Attacker's address:
Attack contracts:
Attack transaction:
Core of the Attack
The attacker exploited a reentrancy vulnerability to manipulate the price corresponding to their own deposit shares. Subsequently, when selling, the maliciously manipulated price calculation dependency led to similar price manipulation. By accurately calculating the updated share price during reentrancy, the attacker stole funds from the contract.
Transaction Analysis
We can observe a reentrancy call in the attack transaction, and we analyze the calling method step by step through decompiled code.
The attacker first created attack contracts (0x7f283 and 0xdd9af), and then called the 0xe9ccf3a3 method of the Stars Arena: Shares contract through the attack contract, and deposited 1 AVAX token.
According to the decompiled code, the 0xe9ccf3a3 method used by the attacker is a function similar to a deposit, which calls the 0x326c and 0x2058 methods. The 0x326c method is only called as a parameter return, while the 0x2058 method is similar to a function for processing the purchase or exchange of a certain token, and this method uses the AVAX token amount and address passed in by 0xe9ccf3a3 for the next operation and share and fee calculation.
Following the call logic of the 0x2058 method on line 92, we find that the 0x1a9b method is a calculation function, which calculates a value similar to a price, with the return value being the newly calculated v24 / 0xde0b6b3a7640000 or _initialPrice.
In the subsequent 109th, 110th, and 116th lines of the 0x307c and 0x30ef methods, there are low-level call calls, and the call of 0x30ef is an external call to varg1, which is the address of the 0xdd9af attack contract passed in. The function does not have constraints for reentrancy locks, and after executing the external call, this method will then proceed to execute the subsequent if judgment to update field0.length and field0 parameters. Undoubtedly, the reentrancy occurs at this point.
Let's take a look at the data constructed by the attacker in the reentrancy call.
The reentrancy external call is the 0x5632b2e4 method, and the attacker passes in 4 parameters constructed by them, with these parameters being converted from 153005ce00 to 91000000000.
As mentioned earlier, the external call to the 0x5632b2e4 method is executed before the if (varg0 == _getMyShares[address(varg1)][msg.sender]) judgment. At this time, the value of field0.length is 0 and has not been updated. The attacker precisely bypasses the judgment in the 0x5632b2e4 method through this method, modifying the status of the following 4 parameters of the msg.sender, which is the attack contract 0xdd9af, to the data constructed at the time of the external call.
After the above operation, the attacker called sellShares to sell their shares and obtained 266,102.97278 AVAX tokens.
Delving into the sellShares function, the function initially calls the 0x1a9b method, and there was a previous call in the 0x2058 method, which is a function for processing the purchase or exchange of a certain token. We can see that in the 0x1a9b method, the 0x2329 method will update owner_9f[varg0], and this parameter was already modified by the attacker to 91000000000 during reentrancy.
Returning to the 0x1a9b method, the value is recalculated based on the maliciously constructed value (see comments for the calculation amount).
After the above calculation, the price corresponding to the newly calculated shares has changed, with the calculated result being 274,333.061476814e18. After a series of fee collections, the attacker successfully profited from selling shares without modifying the shares.
Conclusion
The core of this attack lies in the price calculation dependency update caused by the reentrancy attack, which in turn led to malicious price manipulation. The SlowMist security team recommends that project parties should deploy contracts after being audited by multiple security companies as much as possible, and should strive to satisfy the Checks-Effects-Interactions coding specification and add reentrancy locks when coding.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
