Deep Dive into High-Profile Crypto Exploits — Part I: Beanstalk Farms

In this series of blog posts, we will explore and analyze popular and high profile attacks on blockchain protocols, including the Ronin bridge hack, the polynetwork exploit and more.

In this first installment, we are going to analyze the most recent example — How an attacker managed to drain more than 100,000,000$ of funds from the Beanstalk Farms protocol without any exploit or a bug in the code.

TLDR — on April 17th, 2022 an attacker exploited the characteristics of the Beanstalk governance protocol to approve his malicious proposal, stealing more than 180M$ in assets and dropping the price of the $BEAN stablecoin token by nearly 80%.

Background

This attack is unique in the sense that there were no compromised keys, privilege escalation or a bug in the contract that was exploited. The attacker simply leveraged a design flaw in the governance protocol implementation and managed to accrue enough governance votes using a flash loan to achieve a majority and pass his malicious proposal.

In order to understand this exploit, we will try to provide a quick explanation of the relevant terms:

• Flash loan — a flash loan is a powerful DeFi tool that allows you to borrow funds (in the current attack, 1B$ were borrowed) from platforms like Aave & Compound. It is mainly used to amplify arbitrage gains. The catch is that all borrowed funds must be returned in the same transaction that they were borrowed.
• Governance — a governance is a system for managing and implementing changes to a protocol. Users can submit proposals for changing parts of the system, such as moving funds from treasury, changing fees and more. Token holders can vote on whether or not to implement the change. This allows for a decentralized mechanism to reach an agreement on the future and growth of a protocol.
  Proposals are usually proposed by creating a smart contract that contains the proposal’s logic, and sending its address to the governance protocol.

The attack — A High-Level overview (For Dummies)

For those who are not interested in more detailed technical overview, here is an overview of the attack in layman terms:

1. On April 16th the attacker proposed 2 malicious proposals to the Beanstalk governance protocol — The first one is meant to drain the liquidity and funds from Beanstalk, and the second one was made public and is meant to donate 250k$ to Ukraine.
   This second proposal’s code was made public and was specifically named with the ID of the first proposal, to mislead the community and hide the first, malicious, proposal.
   It is interesting to note that the attacker hid the malicious proposal’s logic until the block of the attack (more info on that can be found in the Deeper Dive section below).
2. Almost exactly 24 hours later, on April 17th, the attacker borrowed 1 Billion USD using flash loans from Aave protocol, and purchased a large number of special BEAN protocol tokens called BEAN3CRV-f and BEANLUSD-f. These tokens can be used to vote on Governance proposals, and this is exactly what the attacker did.
3. The attacker used the voting tokens mentioned above to call the emergencyCommit() function of the Beanstalk governance protocol to immediately approve both of his proposals.
   This was possible because using the 1B$ from the flash loan to purchase more than 70% of the voting tokens.
4. The attacker paid the loan back with the profits from the drained liquidity, and was ultimately left with more than 23,000 ETH and more than 60,000,000 BEAN tokens
5. Like most of the attacks, the attacker quickly moved all funds to Tornado.cash.

The attack — A Deeper Dive

Following is a more detailed chronological step-by-step analysis of the attack, including the relevant transactions and an explanation of some of the tricks the attacker used to hide his activity:

1. The first step of the attack was deploying the contract of the public proposal to donate 250,000$ to Ukraine (which will be proposed in step 3 below)

a. The proposal was deployed in the following tx: https://etherscan.io/tx/0xd09b72275962b03dd96205f8077fdc08bec87c0ebd07e431aadc760f31f34b01

b. The proposal’s contract address is https://etherscan.io/address/0x259a2795624b8a17bc7eb312a94504ad0f615d1e

c. The proposal’s code is

d. The proposal’s contract name is InitBip18.sol as can be seen above.

e. Note: This transaction only deployed the proposal’s code. This proposal will be proposed in step 3 below.

2. Then, the attacker interacted with the Beanstalk governance protocol and proposed the malicious proposal that wasn’t even deployed yet.

a. The proposal was made in this tx — https://etherscan.io/tx/0x68cdec0ac76454c3b0f7af0b8a3895db00adf6daaf3b50a99716858c4fa54c6f

b. The Beanstalk governance protocol gave this proposal the ID 18.

c. NOTE: As mentioned in the background section, in order to propose a proposal, only a contract address is needed. Therefore, the attacker pre- calculated the address on which he will later deploy the malicious proposal’s contract, which enabled him to propose the malicious contract without deploying its code yet.

3. Then, the attacker interacted with the Beanstalk governance protocol again, and proposed the Ukraine proposal he deployed at step 1

a. This proposal was made in this tx — https://etherscan.io/tx/0x9575e478d7c542558ecca52b27072fa1f1ec70679106bdbd62f3bb4d6c87a80d

b. The Beanstalk governance protocol gave this proposal the ID 19

c. It is interesting to note that the attacker named this proposal’s contract InitBip18.sol, in order to mislead users to believe that the malicious proposal with ID 18 he proposed in step 2 was in fact an innocent donation to Ukraine proposal.

4. After that, the attacker sent 0.25 ETH to the address where the first malicious proposal will be deployed to

a. TX — https://etherscan.io/tx/0x3cb358d40647e178ee5be25c2e16726b90ff2c17d34b64e013d8cf1c2c358967

Steps 1–4 were done on April 16th, and the contract of the first malicious proposal was still not deployed. The attacker had to wait for 24 hours, until April 17th, because the governance protocol enforced a 24 hour limit between proposing a proposal and accepting it.

5. On April 17th, the attacker sent two transactions at the same block — The first one finally deployed the malicious proposal to the address the hacker had proposed a day before, and the second one started the actual attack

a. The TX of the malicious contract deployment — https://etherscan.io/tx/0x677660ce489935b94bf5ac32c494669a71ee76913ffabe623e82a7de8226b460

b. The malicious proposal contract address — https://etherscan.io/address/0xe5ecf73603d98a0128f05ed30506ac7a663dbb69

7. As mentioned above, in the attack the attacker borrowed 1 Billion USD from the Aave in a flash loan and used them to purchase enough voting tokens in the Beanstalk governance protocol to have an absolute majority (over 67%). This then meant he could call the emergencyCommit() function in the Beanstalk governance protocol to immediately approve his malicious proposal, and drain all the liquidity.

a. The attack’s TX — https://etherscan.io/tx/0xcd314668aaa9bbfebaf1a0bd2b6553d01dd58899c508d4729fa7311dc5d33ad7/advanced

b. More than 24,800 ETH, currently worth more than 80,000,000$ were moved to the attacker’s address — https://etherscan.io/address/0x1c5dcdd006ea78a7e4783f9e6021c32935a10fb4 and from there to Tornado.cash.

The Attacker’s Tricks

The attacker used several methods to hide the attack in the 24 hour period he had to wait until he could execute it:

1. The malicious contract’s proposal was never live, until the block of the attack — The attacker calculated the address the contract will have using the create2 opcode, and used it in the proposal on April 16th, even though the malicious contract was deployed only on April 17th
2. The attacker deployed the malicious contract and executed the attack on the same block, so no one had the chance to review the code of the proposal
3. The attacker precalculated the ID of the malicious proposal and deployed a seemingly innocent second proposal to donate to Ukraine, and named it with an incorrect ID to mislead investors and make them believe the malicious proposal was in fact the donation to Ukraine.

This shows the attacker had a deep understanding of multiple aspects of the blockchain including create2, ordering transactions in a block, flash loans and more, and that he had crafted this elaborate plan for quite some time.

Like many high-profile blockchains attacks lately, all this might lead to a state-backed entity that is behind this exploit, but it is still too early to tell.

Mitigation

As sophisticated as the attack was, it didn’t rely on social engineering or a complex exploit.
Instead, it used a fatal flaw in the design of the Beanstalk governance protocol — the emergencyCommit function allowed any proposal to be accepted in a single transaction if an absolute majority of over 67% was reached.

When dealing with governance, developers must keep in mind that flash loans allow users to hold practically an infinite amount of any token for a single transaction.

This attack could have been prevented by enforcing that proposals must wait for a certain amount of time before being approved.

In addition to that, we believe projects should make more extensive use of off-chain detection tools that alert them of anomalies such as undeployed proposals, or a large withdraw from a bridge (in the case of the Ronin attack).

Summary

As in most of the blockchain attacks, this attack could have also been avoided with a small change to the design of the protocol, or with better analytical and intrusion detection systems in place.

At Solid Group, we always aim to audit the code not only for correctness and for known exploits, but also to go over the design decisions with our clients and provide our recommendations and feedback that are based on the years of cybersecurity experience of our auditing team.

About Solid Group

Solid Group is a blockchain consulting and auditing service provider founded by cybersecurity experts with a great passion for the cryptocurrency world. We are known for our exceptional out of the box thinking, experience, and our credibility among the community. Throughout our work, our team was able to discover many high severity issues & vulnerabilities. We work with leading companies in the field, helping them increase their resilience through tailored services and solutions.

‌Solid Group provides ALL IN ONE ICO SOLUTION -‌

• audited token generator ( Generate your own token with NO CODING KNOWLEDGE)
• sniper bot protection tool
• Smart contract auditing service‌

🌍 solidgrp.io | 🐦 Twitter | 📣 Telegram Group | ✉️ info@solidgrp.io