PeckShield: Analysis of hard-core technology, the whole story of bZx protocol being attacked by hackersPeckShield: Analysis of hard-core technology, the whole story of bZx protocol being attacked by hackers"In the analysis, bZx was attacked by hackers on a liquidity attack on portfolio assets on February 15, which was caused by the imperfect judgment of the collateral status by the bZx contract.
On February 18th, bZx encountered a similar attack again. The technical principle of this attack was different from the previous one. This time, the hacker "deceived" the bZx contract by manipulating the Oracle price.
From the perspective of the attack process, this time is just the opposite of the last time, but the overall arbitrage method is still the same. The root cause is mainly due to the small sharing liquidity between platforms and the design flaws in the price mechanism.
Figure: Five Exploitation Steps With Oracle Manipulation
The original intention of this article is to analyze some attack details of this vulnerability so that everyone can have a more intuitive understanding of the attack, and hope it can lead to more in-depth discussions. We believe that these discussions will be very beneficial to the improvement and development of the DeFi community, especially when the project party is developing the next generation of DeFi products, it can help design a safer and more reliable liquidity sharing model.
The attack details of the vulnerability are as follows:
first level title
Step 1: Flash loan to obtain available assets
The bZx contract has a flashBorrowToken() interface, which allows the caller to borrow assets from the bZx platform to participate in DeFi activities at "zero cost", and then repay this part of the assets when the transaction is completed. And the caller can specify the recipient address of the asset while lending the asset.
Figure1: Flashloan Borrowing From bZx
This time, the attacker lent 7,500 ETH to the bZx platform, and designated the attacker's contract (which had been deployed before) as the address of the asset receiver. This part is the basic lending function and will not be further explained here.
first level title
Step 2: Raise sUSD
First of all, let’s introduce the best supporting role of today’s attackers: sUSD, sUSD is a stable currency issued by the Synthetix project party. Its currency price is normally equal to 1 US dollar, and the total circulation is 5,563,037 pieces (statistics in February 2020 18).
After obtaining ETH through the first flash loan, the attacker divided a total of 900 ETH into sUSD through KyberNetwork DEX in two batches. Among them, 540 ETH was exchanged for the first time, (the price of KyberUniswap obtained by KyberNetwork’s internal query is the best) the attacker got 92,419 sUSD; the second batch was divided into 18 times, each exchanged for 20 ETH, (Kyber-sUSD was confirmed after KyberNetwork query The price is the most suitable), the attacker obtained 63,584 sUSD, and obtained a total of 156,003 sUSD.
Figure2: Pumping With Kyber (and Uniswap)
These two steps are also a normal DEX exchange process. After these two batches of operations, the price of sUSD to ETH skyrocketed to 0.00899, which is 2.5 times the market price.
first level title
The third step: absorb more chips
The attacker hopes to exchange all the 6,000 ETH in his hand into sUSD through the Synthetix exchangeEtherForSynths() interface. And Synthetix did not have enough sUSD to facilitate this transaction, only exchanged 3,518 ETH, and returned the remaining 2,482 ETH to the attacker, and the attacker obtained 943,837 sUSD.
Figure3：Hoarding From Synthetix
So far, the attacker has a total of 1,099,841 sUSD, accounting for 19.7% of the total circulation.
first level title
Step Four: Mortgage Borrowing
The attacker mortgaged all 1,099,841 sUSD in his hand into the bZx contract through the borrowTokenFromDeposit() interface of bZx. According to the normal price of sUSD/ETH, bZx should lend 3,928 ETH to the attacker, but bZx obtained it from Oracle Kyber The price of is too high, so that 6,796 ETHs were lent, and 2,868 ETHs were borrowed more.
Figure4: Collateralized Borrowing From bZx
first level title
Step 5: Flash loan repayment
The attacker used the 6,796 ETH borrowed from bZx and the remaining assets in his hand to return the 7,500 ETH previously borrowed from bZx, and then left to complete the flash loan operation.
Figure5: Repay The Flashloan To bZx
After completing the entire flash loan process, the current asset situation:
1) The bZx platform lent 6,796 ETH to the attacker;
2) The bZx platform holds 1,099,841 sUSD;
3) The attacker still holds 2,378 ETH.
In the end, the 2,378 ETH held by the attacker made a profit for him, totaling $665,840Summarize
Summarize
In this attack, we can see several obvious problems in the design process of DeFi products:
1) When introducing a third-party Token, it is necessary to examine the security of the third-party Token, whether it is possible to be unilaterally manipulated by the market, thereby causing price fluctuations;
2) The DeFi platform itself should have a price tolerance and inspection mechanism. When using a third-party Oracle to obtain prices, there should be as much verification as possible of other parties' data;
3) The platform itself should also set up a water stop valve mechanism for the price.
The loss of 1,271 ETHs from the first bZx attack, and the loss of 2,378 ETHs this time, and the difference between the two attacks is only 3 days, shows that the security problems of DeFi special projects are very serious.
Since each project is developed by different teams, and they have limited understanding of the design and implementation of their respective products, the integrated products are likely to have security problems in the process of interacting with third-party platforms, and then suffer from enemies. PeckShield hereby suggests that before the DeFi project goes online, it should try its best to find a team with in-depth research on the product design of each link of DeFi to do a complete security audit to avoid potential security risks.
