On April 18th 9:00 PM EST, a hacker stole nearly 25 million USD worth of digital assets from Lendf.Me, a lending market similar to Compound created by dForce. The hacker exploited a reentrancy vulnerability in order to manipulate Lendf.Me’s internal record of the hacker's collateral. After the hacker created this false collateral record, the hacker withdrew nearly all stablecoins, synthetic BTC, and wETH from the platform.
imBTC, ERC777, and Reentrancy
The hack took place after dForce allowed imBTC, a synthetic Bitcoin asset following the ERC777 standard, to be used as collateral on Lendf.Me. The ERC777 token standard was created in order to extend the capabilities currently available in ERC20 tokens.
Aside from other features, ERC777 allows the token contract to notify senders and recipients when ERC777 tokens are sent or received from their accounts. This notification is in the form of a callback to the recipient. Therefore, if the recipient of the tokens is a smart contract, the smart contract can choose to react to such events. One possible reaction to such an event is reentering the ERC777 contract and calling another send (if the particular implementation of ERC777 allows). When Lendf.Me enabled the use of imBTC as collateral, the enabled ERC777 callback notification made Lendf.Me vulnerable to reentrancy attacks.
This vulnerability allowed the attacker to create a false record of imBTC collateral within the Lendf.Me system. The attacker first truthfully deposited a substantial amount of imBTC as collateral. Subsequently, they triggered another deposit of imBTC, but within the callback and before the actual transfer of imBTC, they withdrew their original imBTC deposit. The code of Lendf.Me did not account for such a transfer or execution to the callback being possible, and performed crucial state updates after the transfer completed based on data stored in local variables. Therefore, after properly decreasing the attacker’s collateral within the hooked withdrawal, the code overwrote the attacker’s collateral value when the execution returned to the deposit being performed. In consequence, both the operations together recorded net collateral increase.
By continuing to perform the same attack, from the perspective of the protocol, the attacker’s collateral balance inflated to well over 25 million USD: however, the imBTC that the attacker used while executing the attack was already in their personal account. This allowed the attacker to finalize their attack by “borrowing” all liquidity within each of the 12 lending markets with collateral that was not physically present inside of Lendf.Me.
dForce Foundation response
An hour following the exploit, the dForce Foundation paused Lendf.Me contracts, reached out to law enforcement, and contacted exchanges in order to blacklist transactions from the hacker (source). After the hacker initiated conversation with dForce by sending a message over an Ethereum transaction, dForce began responding via the same method and pressured the hacker to communicate with them via email. After realizing the hacker had used 1inch.exchange to trade stolen assets for other digital currencies, Singapore authorities contacted the exchange, who subsequently turned over the hacker’s IP address and other metadata.
Current status
After receiving pressure from the authorities and dForce, the hacker returned nearly all funds. dForce is creating an asset redistribution plan in order to return assets to affected users and providing updates to users and the community on their Medium channel. Mindao Yang, the founder of dForce, told users the following: “If you were harmed by this attack, we will make you whole again.”
Security Best Practice Takeaways
Since the beginning of the year, multiple security exploits have occurred that led to financial damage. Quantstamp security engineers offer the following best practices to Solidity developers in order to facilitate secure development:
Quantstamp Senior Research Engineer Sebastian Banescu:
Quantstamp Research Engineer Martinet Lee:
In addition, copy and pasting code (aka the clone-and-own approach) from other projects is very dangerous. When a developer copy and pastes code belonging to a different project, it often leads to incompatibilities that lead to exploits.