Analysis of technical details
Analysis of technical details
The following analysis:
https://etherscan.io/tx/0x3503253131644dd9f52802d071de74e456570374d586ddd640159cf6fb9b8ad8As an example, the transaction flow chart is as follows:
In this transaction, the attacker first borrowed 15 million DAI through the Flash Loan service in Uniswap, and then purchased all EMN tokens, purchasing a total of about 1,383,650,487 EMN tokens.
Half of the EMN, a total of about 691,825,243 EMN tokens, was used to purchase eAAVE tokens through the OP0 step, and a total of about 572,431 eAAVE tokens were obtained.
To date, the attacker holds a total of 1,383,650,487-691,825,243 = 691,825,244 EMN and 572,431 eAAVE tokens.
Next, the attacker's script continued to execute 5 internal transactions (Internal Transactions) including OP0, OP1, OP2, OP3, and OP4. The impact of these 5 internal transactions is as follows:
text
However, in the definition of the _burn function in the figure below, we can see that only the number of EMN tokens is burned, while the corresponding number of DAI has not changed. This creates a problem: the ratio of EMN to DAI reduces the relative price of DAI due to the reduction in the number of EMN. Therefore, if you use the same amount of EMN to buy DAI, you can get more DAI.
Therefore, when OP0 is completed, the ratio of the number of EMN to the number of DAI decreases. The attacker converts the remaining general EMN into DAI through OP1. Since the relative price of DAI is low at this time, the amount of DAI purchased is more than normal.
After completing OP1, the attacker converts the eAAVE held back to EMN through OP2 and OP3, and then converts it to DAI. Finally, before OP4, the amount of DAI held by the attacker will be higher than the amount borrowed from Uniswap.
So far, the attacker has completed a profit through the vulnerability.
The attacker exploited the vulnerability three times in the same transaction. Every time OP4 is reached, the total DAI after profit will be used again to carry out attacks. After completing all three times, the attacker repaid the Uniswap loan, and sent the transaction profit to its address:
0x223034edbe95823c1160c16f26e3000315171ca9
The attacker executed a total of 3 transactions, and the transaction address is as follows:
first:
0x3503253131644dd9f52802d071de74e456570374d586ddd640159cf6fb9b8ad8
the second time:
0x045b60411af18114f1986957a41296ba2a97ccff75a9b38af818800ea9da0b2a
secondary title
0x4f0f495dbcb58b452f268b9149a418524e43b13b55e780673c10b3b755340317
analysis Summary
This incident is a typical case of a security breach caused by the inconsistency between the logic design and the actual smart contract code implementation. And before the project goes online, it has not yet passed the security audit. For this type of vulnerability, traditional testing methods and testing tools cannot detect this kind of logic vulnerability.
Therefore, CertiK proposes the following:
The current boom in DeFi projects continues unabated. In order to seize hot spots and opportunities, many projects have rushed online without rigorous testing and auditing. In these projects, most of the vulnerabilities cannot be found by common testing methods and tools. Only by looking for professional audit experts to conduct rigorous mathematical model proofs can this vulnerability be discovered.
Security audits are now standard for high-quality DeFi projects. If the project has not been audited, for users, the investment behavior must be extra cautious; for the project party, it is necessary to find a professional and reputable auditing company for auditing. If the project has been audited, it is necessary to try to understand the background of the audit company and the indicators in its audit report, including but not limited to:
Scope, method, and conclusion of security audit
Are there any loopholes or security risks in the contract? If so, need to understand the severity of these problems and their possible impact
Overall code quality of the contract
Professionalism and independence of the audit firm
