The DeFi protocol—Lendf.Me was attacked, attackers use the re-entry bugs to cover their own fund balance and make the number of withdrawable funds doubled. Now its development team has used red letters in the user interface of Lendf.Me to remind users not to deposit into the contracts accounts.

According the analysis from Beosin, one of China’s top blockchain security companies, now the loss of Lendf.Me has exceeded $25 million. The complete attack process is traced as follows:

The attacker’s address is 0xA9BF70A420d364e923C74448D9D817d3F2A77822; the attacked contracts is 0x538359785a8D5AB1A741A0bA94f26a800759D91D. The attacker first conducted multiple attacking tests (as shown in the figure below):

In the third transaction (0xe49304cd3ed) after contracts deployment, the attacker made the first attack attempt:

At the beginning of the attack, there is a problem in the attacker’s initial transaction sending script, which results in that only the first attack in the block can succeed, and all subsequent transactions throw exceptions.

Later, the attacker made changes to the attack script, and only one attack transaction was sent in one block. First of all, by analyzing the three successful transactions, we can see that the attacker ‘s fund basically presents a double relationship, and the attack has begun to profit:

At that time, the attacker has completed the confirmation of the attack process, and the subsequent successive transactions are that the attacker has registered multiple token addresses for token exchange:

Taking ‘0xc906fc184c6f’ transaction as an example, ‘0x06af07097c9eeb7fd685c692751d5c66db49c215’ is the contracts address of token CHAI. The block height of 9899740 ~ 9899741 is basically all registered tokens.

After that, the attacker continues to attack. It can be seen that after each attack, the number of funds (imBTC) held by the attacker will almost double. Through this process of constantly doubling, when 0xced7ca81308 is traded, it has basically reached the maximum stock of imBTC.

Analysis of hacker attacking methods:

Take the transaction ‘0x111aef012df47efb97202d0a60780ec082125639936dcbd56b27551ce05c4214’ as an example:

Lendf.me contracts address: 0x0ee3e3828a45f7601d5f54bf49b01d1a9df5ea

ImBTC contracts address: 0x3212b29e33587a00fb1c83346f5dbfa69a458923

Step 1: Executing the supply function normally, and save 113.21475453 imBTC. No reentry is performed here.

Step 2: Adopting the supply function again and store in 0.00000001 imBTC. In this transaction, as in step 3, the attacker triggers the feature that the sender will be notified when using the transferFrom function to transfer tokens in the supply function. In the sender’s code, call back the withdraw function of Lendf.me and take out 113.21475453 stored in supply and 113.21475516 imBTC in the last reentry transaction, totaling 226.42950969 imBTC. After reentry, return to the remaining code of transferFrom again, and continue to transfer 0.00000001 imBTC into Lendf.me.

Suggestions for defense

1. Add lock mechanism to key business operation methods, such as OpenZeppelin and ReentrancyGuard

2. When developing a contract, we adopt the writing style of first changing the variables of the contracts, and then making external calls

3. Before the project goes online, the excellent third-party safety team should conduct a comprehensive safety audit to find potential safety problems as much as possible

4. When multiple contracts are connected, it is necessary to check the code security and business security of multiple contracts, and comprehensively consider the security issues under the combination of various business scenarios

5. The contract should be set the pause switch as much as possible to detect and stop the loss in time in case of “black swan” event

6. Security is dynamic, and each project party should timely capture threat intelligence that may be related to its own project, and timely check potential security risks