DeFi or decentralized finance is a growing sector in the blockchain and cryptocurrency space that defines an ecosystem of decentralized applications providing financial services with no governing authority. is a DeFi app utilizing smart contracts in order to provide instant, decentralized lending. The platform suffered an attack causing the loss of $25m in cryptocurrency on the day of April 19, 2020. Lendf.me Thus, joining the list of other DeFi protocols exploited recently: — 37M sETH stolen Synthetix hack — $900k stolen bZx hack Lendf.me’s current vulnerability is a unique instance of the reentrancy bug. Reentrancy is a well-known issue in the field of computing, referring to the ability of a subroutine to be interrupted in the middle of its execution and (then safely) be called again. Other reentrancy bugs have been exploited in the past, causing massive damage, including: — $150m stolen The DAO hack — $30k stolen Spank Chain hack The Lendf.me attack took place on the Ethereum main-net smart contract named , which implements the core logic of the Lendf.me app. MoneyMarket Understanding the Lendf.me vulnerability In order to best understand the underlying cause of the vulnerability, we should consider the contents of the various functions in the MoneyMarket contract. First, we will consider the function (line 1508): MoneyMarket.supply() part 1 MoneyMarket.supply() part 2 MoneyMarket.supply() MoneyMarket.doTransferIn() The main purpose of the function is to handle token deposits. The function takes two arguments, the asset (the asset that the user wishes to deposit), and the amount (the number of tokens he wishes to deposit). MoneyMarket.supply() The main logic flow of the function is as follows: MoneyMarket.supply() First, we read the balance variable that represents the user’s deposited asset balance in storage (line 1514), then, function is invoked (line 1526). This function (externally) calls the asset contract in order to figure if the user has the number of tokens he wishes to deposit and that he approved the contract to withdraw this amount on his behalf. MoneyMarket MoneyMarket.checkTransferIn() MoneyMarket Later function is invoked (line 1583) which (externally) calls the asset contract’s function (line 405) that in turn transfers the amount from the user to the contract. After the return from the external call the function is updating the user’s deposited balance (lines 1599–1600). MoneyMarket.doTransferIn() transferFrom() MoneyMarket MoneyMarket.supply() Let’s go over the function’s logic briefly. In a simplified manner, this function gets the requested amount of tokens to withdraw, checks that the user holds at least this amount of tokens then transfers these tokens to the user by (externally) calling the token contract function. MoneyMarket.withdraw() transfer() Can you spot the vulnerability by now? The issue here is that function is actually updating the user’s asset balance the external call to (lines 1599–1600), but based on a value that was read the external call (line 1514), which means that the update potentially ignores any updates that were made within the external call. In many terms, we can consider this anomaly to be a “Lost Update”. MoneyMarket.supply() after asset.transferFrom() before But why is Lendf.me’s vulnerability exploitable? In order to understand this, we will have a look at the imBTC contract (or any other ERC-777 compliant contract) imBTC._transferFrom() imBTC._callTokensToSend() The attacker took advantage of the fact that some of the assets implement ERC-777 standard, which means that the function and thus, function are invoked (lines 866, 1056 respectively) before the actual transfer of value between the two parties. imBTC._callTokensToSend() attackerContract.tokensToSend() This way, the attacker’s contract gets a chance to call function the invocation of is finished! MoneyMarket.withdraw() before MoneyMarket.supply() Attack Strategy The only prerequisite for attempting the exploit is for an attacker to deploy an attacker contract that holds some amount of any asset that is ERC-777 compliant, let’s assume for example that the attacker holds 10 tokens of . imBTC Now, The attacker would place the first transaction that invokes . At this point, the attacker holds a supply of 9 imBTC in the contract, and a balance of 1 imBTC in the imBTC token contract.The attacker would place the second transaction that invokes , but now with an external call to inside the callback. MoneyMarket.supply ( asset = imBTCAddress , amount = 9) MoneyMarket MoneyMarket.supply (asset = imBTCAddress, amount = 1) MoneyMarket.withdraw (asset = imBTCAddress , requestedAmount = 9) attackerContract.tokensToSend() By the end of this transaction, the attacker’s imBTC balance in the imBTC token contract is 9, but the imBTC supply in the contract is 10! This unwanted state occurred as the function increases the supply for the attacker (lines 1599–1600) it uses stale data. MoneyMarket MoneyMarket.supply() Therefore, the function doesn’t “know” at this point, that the attacker has already withdrawn some of his supply.Now, the attacker holds a deposit on the contract, backed by nothing. MoneyMarket The attacker can use this to (falsely) borrow or withdraw assets deposited by other users. Furthermore, these two steps could be potentially performed, again and again, thus draining ’s liquidity. MoneyMarket Mitigation When writing the smart contract code, try not to update storage variables after an external call.If not possible, deploy some locking mechanism, like the commonly known instead. Make sure that any pair of code paths that have a possible read/write conflict for a variable will be “reentrancy guarded”. For example, in this case, deploying a reentrancy guard only for the function would not solve the problem, it should be deployed for the function as well. Valid network’s automated tools can help identify locations where these guards are missing, or incorrectly implemented. any ReentrancyGuard MoneyMarket.supply() MoneyMarket.withdraw() (Written by David Oz Kashi on Behalf of Valid Network)
![featured image - How Did Lendf.Me Lose $25 Million to A Reentrancy Attack? [An Analysis]](https://hackernoon.imgix.net/drafts/xg1o32c1.png?auto=format&fit=max&w=2048)
![Maliciously Manipulate Storage Variables in Solidity [A How-To Guide]](https://hackernoon.imgix.net/drafts/ld8532kf.png?auto=format&fit=max&w=3840)
