bZx had been in the news for quite a while after it had been hacked twice in a gap of 4 days.The first attack occurred on Feb 14th, 2020 and another on Feb 18th, 2020. Both of these attacks led to loss of approximately $954k. Now, hacked for a third time ,incurring loss of $8.1 million, though the money was recovered later.
Recently, after seven months, a bug in bZx’s project has been exploited again leading to loss of $8.1 million, as per prices on the spot. Basically, the attack focused on the interest-earning iToken of the protocol that users obtain and redeem for crypto deposited into lending pools. As per the information, the hacker was able to take away 1.76 million USDT, 1.4 million USDC, 4507 ETH, 220k LINK tokens, and 670k DAI.
The co-founder of bZx said that they noticed something fishy when after one transaction, the total locked value dropped down by $1 million as mentioned here. After the attack, the team paused the bugged protocol so that bugs could be resolved.
Problem
Even after two audits by the security team, the bug remained undetected. Within 36 hours after extreme hard work, the team of security experts with Marc Thalen was able to diagnose and solve the bug, according to bzx Post. A bug bounty of $45k was paid to Marc Thalen for his help. The company was able to recover the lost money as they exposed the hacker by monitoring his on-chain activity.
Technical Analysis of the Hack
Each ERC20 token has a function for transferring tokens called transferFrom(). There was a bug in this function that it can be called to create and transfer iToken to yourself. Consequently, this will lead to an increase in your balance.
What exactly happened –
- Identical _from and _to address were passed as parameters to the function
- _internalTransferFrom() was called with the parameters passed as mentioned above.
- Faulty code :-
uint256 _balancesFrom = balances[_from];
uint256 _balancesTo = balances[_to];
The result of above code will be identical _balancesFrom and _balancesTo due to identical _from and _to address .
Below mentioned code resulted in decrease in balance of _balanceFrom and increase in balance of _balanceTo and storing the balance in _balancesFromNew and _balancesToNew.
uint256 _balancesFromNew = _balancesFrom.sub(_value, “16”);
_balances[_from] = _balancesFromNew;
uint256 _balancesToNew = _balancesTo.add(_value);
_balances[_to] = _balancesToNew;
The code that was sent for review –
uint256 _balancesFrom = _balances[_from];
uint256 _balancesFromNew = _balancesFrom.sub(_value, “16”);
_balances[_from] = _balancesFromNew;
_balances[_to] = _balancesToNew;
uint256 _balancesToNew = _balancesTo.add(_value);
_balances[_to] = _balancesToNew;
This code will enable the user not to increase their balance artificially.
Conclusion
Although DeFi developed strong new financial products, these attacks remind us of the ways these products can be exploited. These attacks clearly indicate that the programmable finance is still programmable so we can expect the bugs in them. We cannot hope for fully secured DeFi products but we should try to make them robust with increased security. Greater level of user protection is to be built up.