DeFi lending is a relatively simple way of lending.
Lenders simply deposit digital currency into the lending pool and earn interest on the assets they deposit.
Borrowers can provide collateral on the platform in exchange for loan assets provided by lenders.
Lending platforms use price oracles to determine the value of collateral to calculate how much can be borrowed. When the value of the collateral is lower than a certain threshold, the liquidator (Liquidator) can liquidate by repaying the debt and obtain liquidation rewards.
This article will review lending protocol hacks in 2022 and analyze how lending protocols should be secured.
Mango Market Vulnerability
October 11, 2022 on SolanaMango MarketHacked, causing $116 million in damages. Attackers exploited a vulnerability that allowed projects to use low-liquidity tokens as collateral, manipulated the price of MNGO, and maliciously borrowed more assets than they should have.
MNGO is only listed on a few centralized exchanges (CEX), which means its market liquidity is low.
For example, one of the price oracles, Switchboard, uses Raydium as a price source.
The attacker provided 483 million units of MNGO perps (short) in the order book and provided 5 million USDC to the first account. The attacker then injected funds into the second account and then bought 483 million units of MNGO perps at $0.0382 per unit, thereby increasing the spot price.
The attacker profited on the second account by manipulating the price of MNGO on the price oracle (the market price in Mango Market) to raise it to $0.91. Since the price of MNGO/USD is $0.91 per unit (the market price in Mango Market), the second account can borrow other tokens on Mango Market.
The attacker also used the funds in the second account (original deposit + proceeds from selling the borrowed MNGO funds) to borrow other tokens on Mango Market.
The above borrowings resulted in a total bad debt of $11,306,771.61 on the first account, resulting in an asset loss of $115,182,674.43.
The picture below is an example of a screenshot on Radium. It can be seen that the liquidity of the MNGO/USDC pair is very low.
Although Mango uses price oracles and TWAP, attackers with strong "professionalism" and sufficient capital are enough to do some tricks on liquidity, especially when assets are only listed on a few exchanges, resulting in very low liquidity when.
For detailed analysis of Mango vulnerabilities, please check previous articlesMango Market Hacked, $116 Million Lost。
Deus Finance Vulnerability
April 28, 2022Deus FinanceIt was maliciously attacked, resulting in a loss of about $15.7 million in assets. The attacker manipulated the price of the DEI token, withdrawing a large amount of DEI from the DeiLenderSolidex contract, but only provided a small amount of collateral. This is also the second attack on Deus in 2022.
The picture above is the contract of DeiLenderSolidex. The price on the chain is the price of a matching pool, and the input price is the weighted average price (VWAP) from the Muon oracle. Hackers need to manipulate both on-chain Muon oracles and on-chain price inputs. The Muon oracle monitored transactions within the Solidly USDC/DEI pool to calculate the Volume Weighted Average Price (VWAP).
A series of flash-swaps in the same pool will output a manipulated price, which is read by the Muon oracle.
The root cause of this vulnerability is that the Muon oracle only uses Solidly as a price source. The flashswap() used by Swap was not properly filtered by Muon, thus causing inconsistencies in the short-term weighted average price.
Inverse Finance
April 2, 2022Inverse FinanceIt was exploited maliciously, resulting in the loss of assets worth approximately $14.5 million. The root cause of this incident is that the price of the third-party price oracle machine used was manipulated, so the attacker lent assets at the manipulated price.
Inverse uses the Keep 3 r oracle, which relies entirely on DEX price data.
It relies on a TWAP oracle from a low-volume DEX pair with a 30-minute time window to mitigate the risk of market manipulation.
An attacker is able to bypass this limitation by submitting two transactions in a very short period of time (less than 15 seconds) in order to calculate the price using the current number of tokens in the pool.
The attacker first deployed a malicious contract to manipulate the price of INV/XINV in SushiSwap/Curve.fi SushiSwap:INV (INV-ETH pair). They then deposited the above INV and minted 1746 ( 374+ 1372 ) XINV. Since the price of XINV is calculated based on the reserves in SushiSwap:INV (INV-ETH Pair), the price of INV rises sharply, and the value of each XINV at this time is 20926 USD ( 346* 3444/57.7).
With the XINV price being manipulated, the attacker is able to use the minted XINV to lend assets as their profit. Assets lent included 1,588 ETH, 94 WBTC, 3,999,669 DOLA, and 39 YFI; assets worth approximately $14.5 million were stolen and transferred to Tornado Cash.
We also conducted an in-depth analysis of this incident a few months ago, please check the previous article "Tears flowed, the stolen project was about to die... Analysis of Inverse Finance’s $14.5 million theft incident》。
Cashio
On March 23, 2022, the Solana-based Cashio stablecoin, CASH, was maliciously exploited with an "unlimited coinage" type vulnerability, resulting in a loss of approximately $50 million worth of it. The root cause of the incident was a lack of required validation of common.crate_collateral_tokens and depositor_source. Attackers are able to inject fake accounts to bypass verification and mint CASH.
In order to mint new CASH, users need to deposit collateral. The correctness of the minting process is verified when users transfer "collateral" into the project. During the verification of crate_collateral_tokens, the contract checks whether the token type matches the type of the saber_swap.arrow account.
However, the contract does not verify the mint field, as shown in the figure below saber_swap.arrow. An attacker could create a fake saber_swap.arrow account, which would further allow him to create a fake crate_collateral_tokens account and allow the deposit of fake collateral.
Another aspect of the attack is the lack of checks on the depositor_source, which is supposed to ensure that the type of token being deposited matches the collateral.
Users can set the token type of collateral by owning a bank.
Unlimited types of collateral tokens can be created using the crate_mint function, the system does not verify that the token associated with the bank is the same as the token being minted.
As a result, an attacker was able to create a fake bank and deposit worthless collateral, enabling it to mint real CASH and siphon funds from the protocol, resulting in a $52 million hack and a corresponding drop in the price of the stablecoin. collapse.
Fei Protocol
April 30, 2022Fei ProtocolAnnounced that they were investigating a vulnerability on the Rari Fuse pool.
The total reported damage so far is about $80 million. The attacker performed an attack on the borrow function.
The exitMarket function verifies that the deposit is no longer collateral for the loan, and then allows it to be withdrawn. However, the borrow() function does not follow the check-effect-interaction pattern, but transfers ETH to the attacker's contract before updating the attacker's borrowing record.
As shown in the above code, "doTransferOut()" is called before updating the loan record. The doTransferOut() function transfers ETH to the receiver through the underlying call. When the borrow function sends the loan amount to the borrower, it has not yet updated its internal state to reflect that the deposited asset has been used as collateral. Since the attacker's borrowing record was not updated in time, the attacker performed a reentrancy attack on exitmarket() and withdrew their collateral (150 million USDC).
For a detailed analysis of the Fei Protocol attack incident, please refer to the previous article "Reaper Attack: Analysis of Fei Protocol Vulnerability Leading to $79.35 Million Theft》。
Fantasm Finance
March 09, 2022Fantasm FinanceThe staking pool was maliciously attacked, resulting in a loss of about $2.7 million. The attacker exploited a flaw in the error checking code _minFtmIn of the protocol's mint function.
The purpose of the error checking code is to ensure that users deposit FTM into the contract when minting XFTM. According to its implementation, if only FSM is invested, the amount of XFTM needs to be calculated according to the proportion of FSM, and the part exceeding the proportion of FSM needs to be made up by FTM.
However, the code is actually comparing the msg.value (which measures the amount of ETH sent with the transaction) to calculate the minimum amount of FTM to accept minting.
In the first red box in the picture above, the important _minFtmIn parameter is ignored, and this variable is not even declared, but only the FSM is required (the second red box in the picture above).
When only depositing FSM, there is no need to replenish FTM collateral. If FSM is 10%, then 10 u xFTM can be cast with 1 u FSM.
As a result, an attacker is able to mint XFTM while only depositing a fraction of the true value. The minted XFTM is then sold back to the project, enabling the attacker to withdraw assets from the project and buy more FSM for subsequent attacks.
How to protect the lending agreement
2022 is a "dark" year for the security of the global Web3.0 industry. According to our statistics, attacks on lending protocols will cause more than $300 million in losses in 2022 - which means that in the next few years, we will face more urgent and higher security needs.
Next we discuss the lessons we learned from these attacks and summarize best practices on how to prevent and respond to them.
Added flash loan protection
Flash loans allow anyone to take out large loans without collateral. Therefore, it is often used by hackers and has become the attack vector of many large-scale attacks.
In order to avoid flash loan attacks, developers should consider limiting the use of flash loans as much as possible, and only allow non-contract addresses to interact with the contract. Another measure to prevent the abuse of flash loans is to prevent key transactions from happening in the same block. This can effectively reduce the security risks associated with flash loan attacks.
Added reentrancy protection
ReentrancyIt is a relatively common security problem in smart contracts. Such as depleting lending pools and manipulating borrowing records, especially when combined with other vulnerabilities, reentrancy issues can lead to very large losses.
To protect reentrancy, projects can use the reentrancy protection provided by OpenZeppelin and follow the check-effect-interaction pattern.
Choosing a Reliable Price Oracle
Oracles should be able to filter out ambiguous transactions and use multiple data sources. Avoid using an oracle that only relies on the price of a single trading pair, because an attacker only needs to manipulate the price of a pool to manipulate the price of this oracle.
Carefully choose the mortgage token
From an economic point of view, it is recommended to limit or not provide leverage for illiquid tokens. Using tokens with highly volatile prices as collateral increases the overall risk because when the token price fluctuates significantly, the value of the collateral also changes significantly. This increases the chances of attacking a project's economic model, as was the case with Mango Market. It also affects the overall state of the system. If the ratio of the overall collateral to the value of the token lent is too low, the system may not function properly.
Strengthen the security awareness of contract configuration
While auditing smart contracts can detect many human errors and ensure consistent design practices, there are still some sensitive parameters in lending protocols that require manual configuration. Incorrect settings of these parameters can have serious consequences, just as a misconfigured oracle contract can feed back wrong data. Developers and project operators should exercise caution when configuring these parameters.
