Copycat Attack on Balancer: Why DeFi Needs to Change

CertiK | Jul 2, 2020

Article's Poster

Following CertiK’s discovery of the Balancer attack at 6PM UTC (2PM EDT) on June 28th, 2020, the CertiK Skynet system once again detected two similar abnormalities in the Balancer DeFi contract at 12:00PM UTC (8AM EDT) and 3:21PM UTC (11:21AM EDT) on June 29th, 2020. The two instances occurred in block 10360609 and block 10361515, respectively.

Unlike the prior Balancer attack that we wrote about that simply used contract vulnerabilities, this time the attackers cleverly used the Compound financial model and spontaneously generated COMP tokens. Because these three attacks on Balancer occurred within a span of just two days, it certainly raises concerns about the future of DeFi.

Screencap of CertiK's Skynet platform

Summary of the Event

On June 29th, after the attacker borrowed tokens from the dYdX flash loan and minted coins, they obtained cWBTC and cBAT tokens through the Uniswap flash loan. Then the loaned tokens were traded in large amounts into the Balancer token pool, which triggered Compound protocol’s airdrop mechanism and, as a result, airdropped free COMP tokens.

The attacker then used the Balancer’s already-vulnerable gulp() function to update the number of token pools, drained all tokens, and returned the amount borrowed from the flash loan. In the whole process, the attacker leveraged the financial model of the Compound protocol, the functionalities of flash loans, and the code vulnerability of Balancer.

By triggering the airdrop, the attacker created COMP out of nothing and made off with 11.5 ETH—about $2,660 USD as of the time of writing.

CertiK Analysis: Are These Two Attacks Similar to the Previous $500K Attack?

GIF by BADCODEC via Giphy

GIF by BADCODEC

These two most recent attacks at 12:00PM UTC (8AM EDT) and 3:21PM UTC (11:21AM EDT) on June 29th used the same technique and payment address, meaning that it’s possible that they were executed by the same person or team; but they differ in method from the prior Balancer attack that happened at 6:03PM UTC (2:03PM EDT) on June 28th.

Although all of the attacks used the gulp() function of the Balancer contract, the two highlighted in this article used Compound financial model vulnerabilities rather than pure code vulnerabilities. In addition, the amount gained by the attacker from these last two attacks was much smaller than the first, so the hacker who carried out the first attack likely had no incentive to attack again.

Based on these findings, CertiK believes that these recent two attacks were copycat attacks performed by individual(s) inspired by the first $500K attack.

How the Attack Happened

We’ll take the second of the two Balancer attacks highlighted in this article as an example:

Step 1: Attacker borrows three tokens of WETH, DAI, and USDC from dYdX through a lightning loan. The amounts are 103067.20640667767, 5410318.972365872, and 5737595.813492 respectively.

Balancer attack: step 1

Step 2: Attacker uses the tokens obtained in Step 1 to mint three tokens (cETH, cDAI, and cUSDC).

Balancer attack: step 2

Step 3: Attacker uses Uniswap to borrow and mint cWBTC and cBAT tokens through flash loans.

Balancer attack: step 3

Step 4: The obtained cWBTC and cBAT are added into the token pool. At this time, the number of cWBTC and cBAT owned by the attacker are 4955.585562685 and 55144155.96523628 respectively.

Balancer attack: step 4

Step 5: Attacker uses cWBTC and cBAT to conduct a large number of transactions in their respective token pools, thereby triggering the airdrop operation and distributing the non-attributed COMP to the token pool.

Balancer attack: step 5, part 1

Balancer attack: step 5, part 2

Step 6: Attacker calls the gulp() function to synchronize the current number of COMP into the Balancer smart contract and takes out cWBTC, cBAT, and the additional COMP, adding them to the token pool.

When exiting the token pool, the number of cWBTC and cBAT owned by the attacker are 4955.855562685 and 55144155.96523628. However, due to the additional COMP generated by a large number of transactions in the token pool, the attacker obtains additional COMP tokens. Here the attacker can also choose to directly enter other token pools and reuse the attack methods from steps 1 to 6 to obtain additional COMP tokens.

Balancer attack: step 6, part 1

Balancer attack: step 6, part 2

Step 7: Attacker repays the flash loans from Uniswap & dYdX and leaves the market.

Step 8: The attacker can still use the same method (steps 1 to 7) to launch attacks against other token pools. The mechanism of the attack is similar, but the types of tokens borrowed through the lightning loan are slightly different from those used for the attack.

Are We Making It Too Easy for Copycat Attackers?

People have raised concerns on the effect of news coverage and analyses and how they may be encouraging these copycat attacks. The question stands: will security companies’ publicly shared analyses teach more people to find ways to attack these systems?

CertiK’s view is that these analyses serve as learning opportunities for the blockchain space; unlike traditional software systems, transactions and contract calls on public blockchains are viewable by anyone, so the transparent nature of blockchains is both a blessing and a curse.

After any of these attacks occur, the transactions are recorded on the blockchain, which makes it easy for hackers to learn from. As such, it’s the duty of any blockchain security company like ours to publish analyses and warnings of these attacks so organizations can act before a copycat attacker does.

However, the recent frequent attacks have once again proved that security warnings are far from sufficient; while helpful for reactive adjustments, these warnings alone won’t change the efficacy of security in DeFi and in the larger blockchain industry.

What’s Next for DeFi?

Traditional smart contracts vs DeFi smart contracts

This attack took advantage of vulnerabilities in the financial model design, rather than pure code vulnerabilities like with the previous Balancer attack and the notorious TheDAO hack. Typical code review that less diligent blockchain security companies provide as their basic service would be useless against this attack model; thankfully, CertiK’s security team works to identify the potential for these types of exploits when assessing a project’s security holistically, not just from a code level perspective.

However, what that means for DeFi is that there’s a strong, immediate need for protections at the financial model level and a commitment to higher standards for security internally, and making sure to get multiple audits externally. Without the extra effort, DeFi projects remain easy targets for attackers, resulting in slow adoption rates.

What Needs to Change in DeFi Security?

In order to fundamentally change security in DeFi, we must introduce new mechanisms to secure smart contracts. The security mechanisms must be able to carry out analysis at the financial model level, adapt to the development structure of new contracts, and proactively intercept attacks, rather than reactively flagging after an attack.

CertiK has recognized the need for a new and secure DeFi mechanism and has started developing one such solution based on the CertiK Chain: CeDeFi (Certified DeFi)—that is, trustworthy DeFi.

It’s our belief that this new framework will completely change the security capabilities of blockchain.

For the latest updates, follow us on Twitter (@certik.io) or subscribe to our mailing list.

References