On May 6, 2023, Beijing time, a burn logic flaw was discovered in DEUS’s stablecoin DEI contract, resulting in an attacker gaining approximately $6.3 million in profits.
SharkTeam conducted a technical analysis of the incident and has summarized security measures as a precautionary lesson for future projects, aiming to strengthen the security defenses of the blockchain industry.
Analysis of the Incident
Attacker address:
0x08e80ecb146dc0b835cf3d6c48da97556998f599
Attack contract: 0x2b1a7a457a2c55ba1e03c087cc3e4e5b05b6360f
Vulnerable contract:
0xDE1E704dae0B4051e80DAbB26ab6ad6c12262DA0
Attack transactions:
0xde2c8718a9efd8db0eaf9d8141089a22a89bca7d1415d04c05ba107dc1a190c3
The execution flow of the attack transaction:
1. First, the attacker (0x08e80ecb) calls the attack function of the attack contract (0x2b1a7a45).
2. In the attack function, call the approve->burnFrom->transferFrom function of the vulnerable contract (0xDE1E704d)
3. In the transferFrom function, transfer 1.1 million DEI to your own account, and finally call the swap of the trading pair to exchange DEI for USD and transfer it to the attacker (0x08e80ecb).
Vulnerability analysis:
In the burnFrom function, the allowance of the sender to the account and the allowance of the account to the sender are copied directly.
The attacker first approves the maximum value of the vulnerable contract (0xDE1E704d), and then calls the burnFrom function to input amount=0, that is, directly makes the vulnerable contract (0xDE1E704d) approve the maximum value of the attack contract.
Then directly call the tranferFrom function to transfer 1.1 million DEI to your own address, and finally exchange it into USD through the pair transaction to complete the attack
Vulnerability Summary:
The root cause of this incident lies in a contract vulnerability (RouteProcessor2) related to the invocation permissions of the burnFrom function or a potential error in the _allowance parameter. It is necessary to make modifications based on the actual business requirements of the project. This can be addressed by setting appropriate administrative permissions for burnFrom or by adjusting the _allowance[_msgSender()][account] to _allowance[account][_msgSender()] or similar approaches for fixing the issue.
Security Recommendations:
In light of the recent attack incident, it is important to adhere to the following considerations during the development process:
1. Exercise caution and ensure the rigor of business logic when developing functions related to assets.
2. The vulnerable burnFrom function was introduced during a contract upgrade conducted by the project team on April 16. Therefore, before deploying or upgrading contracts, it is crucial for projects to undergo contract audits by professional third-party auditing teams.
About us
SharkTeam’s vision is to comprehensively protect the security of the Web3 world. The team is composed of experienced security professionals and senior researchers from all over the world. They are proficient in the underlying theory of blockchain and smart contracts, and provide services including smart contract auditing, on-chain analysis, and emergency response. It has established long-term cooperative relationships with key players in various fields of the blockchain ecosystem, such as Polkadot, Moonbeam, polygon, OKC, Huobi Global, imToken, ChainIDE, etc.Official
website: https://www.sharkteam.org/
Twitter: https://twitter.com/sharkteamorg
Discord: https://discord.gg/jGH9xXCjDZ
Telegram: https://t.me/sharkteamorg
All Comments