DeFi lending is relatively straightforward. Lenders deposit cryptocurrencies to the lending pool and earn interest on the assets they deposit. The borrower can provide collateral on the platform in exchange for the right to borrow other assets provided by the lender. Lending platform utilizes price oracle to determine the value of collateral to calculate the amount of assets that can be borrowed. When the value of the collateral drops below a certain threshold, liquidators can repay the debts of the borrower and receive the liquidation reward.

Mango Market Exploit

On October 11, 2022, Mango Market on Solana was attacked, causing $116m in bad debt. The attacker exploited a vulnerability that allowed projects to use low-liquidity tokens as collateral, and borrowed more assets on the platform than he was supposed to.

MNGO was only offered on a couple of centralized exchanges (CEXs) meaning there were very few markets with any meaningful liquidity. One of the oracle Switchboards uses Raydium as a price feed, and the following snapshot was taken on Radium. It describes the extremely poor liquidity in the MNGO/USDC pair on radium. Although Mango uses a price oracle and TWAP, a sophisticated and well-capitalized attacker would be able to spoof liquidity, especially if a token is only offered on a few exchanges.

The attacker used the first account to offer 483M units of MNGO perps (short) on the order book using over $5 million in tokens deposited into the protocol. Then the attacker used the second account to buy 483M units of MNGO perps (long), at a price of $0.0382 per unit, which raised the spot price. The market continued to raise the price, peaking at $0.91 per unit. The peak price resulted in the second account achieving a profit of approximately $423 million and allowed the second account to borrow many other valuable assets. The attacker then used the second account to take out a loan of $116 million, draining the liquidity from the protocol. The price then dropped to about $0.02 per unit, which put the first account also in profit and would have allowed another drain if any valuable assets were available.

After draining all liquidity, the attacker left the first account with a total value of $11,306,771.61 uncollectible debt and the second account with $115,182,674.43 bad debt.

For a full analysis of the Mango exploit, see here.

Deus Finance Exploit

On April 28, 2022, Deus Finance was exploited, leading to a loss of around $15.7M. The attacker manipulated the price of DEI and withdrew a large amount of DEI from the DeiLenderSolidex contract while only providing a small amount of collateral. It’s the second attack on Deus in 2022.

Above is the snapshot of the DeiLenderSolidex implementation, the on-chain price here is the price of a pairing pool, and the input price is the VWAP price coming from Muon oracle. The hacker needed to manipulate the off-chain oracle (Muon oracle) as well as the on-chain price feed. The Muon oracle monitors transactions within the Solidly USDC/DEI pool to calculate the Volume Weighted Average Price (VWAP). A series of flash-swaps inside the same pool outputs a manipulated price, which is read by the Muon oracle. The root cause of this exploit is that the muon oracle implementation only used Solidly as a price source. The swap used flashswap() that wasn’t filtered out properly by Muon, leading to a short-term VWAP price discrepancy.

Inverse Finance

On April 02, 2022, Inverse Finance was exploited, leading to ~$14.5M worth of asset loss. The root cause is the price manipulation in the external price oracle dependency. The attacker is able to manipulate the price and borrow assets at the tilted price.

Inverse used a Keep3r oracle, which relied entirely upon DEX price data. It relies upon a TWAP oracle generated from a single thinly traded DEX trading pair with a 30-min time window to mitigate market manipulation risks. The attacker is able to bypass this restriction by submitting two transactions in a very short time period (~15s) so that the current reserve is used to calculate the price.

The attacker first deploys a malicious contract to manipulate the price of INV / XINV in SushiSwap/Curve.fi SushiSwap:INV (INV-ETH Pair). They then deposited the INV above and minted 1746(374+1372) XINV tokens. Since the price of XINV was calculated based on the reserve in SushiSwap:INV (INV-ETH Pair), the price of INV was manipulated and thus each XINV worthed $20926(346*3444/57.7).

Therefore, with the price of XINV being tilted, the attacker was able to borrow assets as his profit with the minted XINV tokens. The borrowed assets include 1588 ETH, 94 WBTC, 3999_669 DOLA and 39 YFI; approximately $14.5M worth of assets was stolen and transferred to Tornado Cash.

We also performed a thorough analysis on this incident a few months ago.

Cashio Exploit

On March 23, 2022, the Solana-based Cashio stable coin CASH was exploited by the type of “infinite mint” vulnerability, leading to ~$50 M worth of asset loss. The root cause stems from the verification design. Lacking necessary validation for common.crate_collateral_tokens and depositor_source, the attacker is able to inject fake accounts to bypass the verifications and mint Cash tokens.

To mint new CASH tokens, a user needs to deposit collateral. The correctness of the minting process relies on the implicit validation that users need to first transfer “collateral” to the project. In the validation process for crate_collateral_tokens, the contract checked if the token type matched that of the saber_swap.arrow account.

However, there was no validation of the mint field, as shown in the following checks within the saber_swap.arrow account. The attacker could create a fake saber_swap.arrow account, which would further allow it to create a fake crate_collateral_tokens account and allow the deposit of fake collateral.

Another aspect of the attack involved a missing check for the depositor_source, which is supposed to ensure that the token type being deposited matches the collateral.

Users can set the collateral token type by owning a bank, which can be created using the crate_mint function without restriction, and the system failed to confirm that the token associated with the bank and the one being minted were the same.

Therefore, the attacker was able to create a fake bank and deposit worthless collateral, allowing him to mint real CASH tokens and drain the fund from the protocol. This resulted in a $52 million hack and the collapse of the stablecoin's value.

Fei Protocol Exploit

On April 30, 2022, Fei Protocol announced that they were aware of and looking into a reentrancy attack on various Rari Fuse pools. The total loss is about $80 Million. The attacker took advantage of the vulnerable borrow function. The exitMarket function verifies that a deposit is no longer used as collateral for a loan and then allows it to be withdrawn. However, the borrow() function does not follow the check-effect-interaction pattern and transfers ETH to the attacker’s contract before updating the attacker’s borrow records.

As the above code illustrates, the “doTransferOut()” is invoked before the borrow records are updated. The doTransferOut() function transfers ETH to the receiver via a low-level call. When the borrow function sends the loaned amount to the borrower, it has not yet updated its internal state to reflect the fact that the deposited asset is currently being used as collateral. With the attacker’s borrow record not updated, the attacker made a reentrant call to exitmarket() that allows the attacker to withdraw their collateral (150M USDC).

Full analysis here.

Fantasm Exploit

On March 09, 2022, Fantasm Finance's collateral reserve pool got exploited, leading to a loss of $2.7m. The attacker took advantage of a flaw in the error-checking code _minFtmIn of the protocol’s mint function.

The purpose of the error-checking code was to ensure that a user deposited FTM tokens into the contract when minting XFTM tokens. Based on the implementation, if only FSM is invested, the amount of xFTM coinage is calculated according to the proportion of FSM. The part beyond the proportion of FSM needs to be made up by FTM. However, the code actually compared with msg.value, which measures the amount of ETH sent along with a transaction, to the minimum amount of FTM tokens that would be accepted for minting. In the first red box, the important _minFtmIn parameter is ignored and the variable is not even declared, only the FSM is needed (the second red box). When only FSM is invested, there is no need to replenish FTM collateral. If FSM accounts for 10%, then 10u xFTM can be minted with 1u FSM.

As a result, the attacker was able to mint XFTM tokens when depositing only a fraction of their true value. The minted XFTM tokens were then sold back to the project, enabling the attacker to extract value from the protocol and buy more FSM tokens for follow-on attacks.

How to Protect Lending Protocols

Two thousand twenty-two was a dark year for the security of the global blockchain industry. Attacks on lending protocols have caused more than 300 million dollar loss in 2022, according to our statistical result. This leads to a greater and more pressing demand for security expectations in the following years.

Add Flashloan Protection

Flashloans allow anyone to take out large loans without collateral. They have been used in incidents that have resulted in significant losses. To mitigate this risk, developers should consider limiting the use of flashloans by only allowing non-contract addresses to interact with the contract, if possible. Another measure to prevent the abuse of flashloans is to prevent critical transactions from occurring within the same block. This can effectively eliminate the risk associated with flashloan attacks.

Add Reentrancy Protection

Reentrancy is a relatively common vulnerability in smart contracts. Reentrancy can lead to significant consequences such as draining the lending pool and manipulating borrow records, especially when combined with other vulnerabilities. To protect reentrancy, projects can use the reentrancy guard provided by OpenZeppelin and follow the check-effect-interaction pattern.

Select a Robust Oracle

Avoid using oracles that only depend on single pair price, as it only takes one pool to manipulate the price feed. The oracle should be able to filter out obscure swaps and to use multiple data sources. Recommended oracles such as Chainlink or Band Protocol can limit the impact of obviously inaccurate values from DEXs.

Be Cautious When Selecting Collateral Tokens

From an economic perspective, it is recommended to limit or not to offer leverage on illiquid tokens. Using highly volatile tokens to be collateral can increase the overall risk, since when the token price fluctuates significantly, the value of the collateral changes greatly. This increases the chances of an economic attack, like the case of Mango Market, and it also affects the overall health of the system. If the value of the overall collateral is too low, the system may not be able to operate normally.

Be Aware of Contract Configurations

Although auditing smart contracts can eliminate many human errors and ensure consistency, there are still sensitive parameters in lending protocols that require manual configuration. Improperly setting these parameters can result in severe consequences, like wrongly configured oracle contracts would feed wrong data. Developers and project operators should exercise an abundance of caution when configuring these parameters.