Approval Error Vulnerability: Analyzing the HedgeyFinance Attack

On April 19, 2024, HedgeyFinance suffered an exploit resulting in an estimated loss of $45 million. A design error in the Campaign contract permitted an attacker to directly steal a substantial amount of assets.

In this blog, we will analyze the first attack on the Ethereum network to help users prevent similar vulnerabilities in their own projects.

Overview

Attacker:

https://etherscan.io/address/0xded2b1a426e1b7d415a40bcad44e98f47181dda2

Vulnerable Contract:

https://etherscan.io/address/0xbc452fdc8f851d7c5b72e1fe74dfb63bb793d511

Transaction attack:

https://etherscan.io/tx/0xa17fdb804728f226fcd10e78eae5247abd984e0f03301312315b89cae25aa517

https://etherscan.io/tx/0x2606d459a50ca4920722a111745c2eeced1d8a01ff25ee762e22d5d4b1595739

Exploit Analysis

Following the first transaction, the attack methodology was surprisingly straightforward. The attacker borrowed a large amount of USDC to create a locked campaign and then immediately canceled it.

In the second transaction, the attacker triggered the contract to transfer USDC directly from the HedgeyFinance contract to their own address.

The simplicity of the second transaction strongly suggests that the root cause of the exploit lies in the createLockedCampaign and cancel functions from step 1.

Investigate the createLockedCampaign function

During the creation of a locked campaign, the owner has the ability to designate a tokenLocker. This tokenLocker, upon receiving approval, can then transfer out all the tokens associated with the newly created campaign. This behavior appears to be a potential vulnerability.

While the function comment indicates an intent to prevent anyone from claiming additional tokens, it appears to only restrict access to reward tokens. Crucially, the function doesn't revoke approval granted in a previous step. This oversight allows the attacker to withdraw all staked tokens within the campaign while retaining the approval from the earlier step.

With this lingering approval, the attacker can easily transfer tokens out of the contract to any desired location.

By analyzing the createLockedCampaign function in reverse, it becomes clear that the approval logic is flawed. Granting the ability for a locked campaign to transfer tokens out at any time contradicts the expected behavior. This design flaw is the root cause of the HedgeyFinance exploit.

Lesson learned

The HedgeyFinance exploit highlights the severe consequences of failing to manage token approvals carefully within smart contracts. Here are key takeaways:

• Approval is Power: In DeFi systems, granting approval to a contract often means giving it the power to transfer your tokens. Treat approvals with the same caution as sending funds directly.

• Revoke When Done: When an interaction with a smart contract is complete, diligently revoke any approvals that are no longer required. This limits the potential attack surface.