Analysis of Hedgey attack incident: loss of tens of millions of dollars in token authorization

On April 19, 2024, the Hedgey Token Claim contract was attacked on multiple chains such as Ethereum and Arbitrum, resulting in losses of tens of millions of dollars. The Hedgey project team immediately issued a security alert, reminding users who created token claiming activities to cancel the token claiming activities through official channels. (https://twitter.com/hedgeyfinance/status/1781257581488418862)

Attack Brief Description

Hedgey helps DAOs and on-chain organizations distribute tokens to their teams, contributors, investors and communities through on-chain, programmatic token issuance. The tool where the vulnerability occurred this time is its Token Claims product, which allows users to create a token claim page, add more than 100,000 recipients to the whitelist through CSV files, and control how to pass flows, time locks, Claimed tokens can be released through recycling or other methods.

The contract vulnerability exploited by this attack is that when the ClaimCampaigns contract in the Token Claims product creates a token claim activity, it authorizes its token to the address specified by the creator. When the creator cancels claiming the event, the token transferred by the creator during the event creation phase is returned to another address specified by the creator, but the token authorization is not revoked, resulting in the event creator's address still being able to use the information authorized by the ClaimCampaigns contract. token.

Key addresses involved in the attack

This attack involves multiple transactions. We only use the following transaction to steal NOBL tokens as an example to analyze the attack principle. analyze.

Attack transaction: https://etherscan.io/tx/0x017ce9593350cba65d506e1a87e52d2c20079fdfa80a350a89fe6fc875f2d9f9

Attack EOA:

##0xded2b1a426e1b 7d415a40bcad44e98f47181dda2

Attacker (Contract):

0xd818ff3d5cfc938014b270d0c8029ba04629b549

Vulnerability Contract (ClaimCampaigns):

##0xbc452fdc8f851d7c5b72e1fe74dfb63bb793d511

##Stolen Tokens (NobleBlocks: NOBL Token):

##0x88b9f5c66342ebaf661b3e2836b807c8cb 1b3195

Analysis of attack process

1.

Attack implementation

During the attack implementation phase, the attacker repeatedly called the "createLockedCampaign" function of the vulnerable contract Create a campaign and then call the "cancelCampaign" function to delete the campaign. When creating a campaign, the attacker transfers a specified number of NOBL tokens to the vulnerability contract and obtains the NOBL token usage limit authorized by the vulnerability contract. When the campaign is deleted, the vulnerability contract returns the NOBL tokens that the attacker transferred when creating the campaign. However, at this time, the vulnerability contract does not revoke the NOBL token usage limit authorized to the attacker. Therefore, by creating a campaign and then deleting the campaign, the attacker can obtain the power to spend the NOBL tokens held by the vulnerable contract out of thin air.

The specific attack steps are as follows:

The attacker calls the "createLockedCampaign" function of the vulnerable contract to create a campaign, and sets both "campaign.manager" and "claimLockup.tokenLocker" in the parameters. For the attacker himself, set "campaign.token" to the NOBL token, "campaign.amount" to "680000000000000000000000" (the decimal of the NOBL token is 18, so this represents 680,000 NOBL tokens), "donation. amount" is set to 0. As can be seen from the "createLockedCampaign" function code, the attacker first transfers NOBL tokens to the vulnerable contract, and then uses the "safeIncreaseAllowance" function to authorize the vulnerable contract to "claimLockup.tokenLocker" (attacker) to spend the funds held by the vulnerable contract. The power of NOBL tokens, here authorizes so much "campaign.amount" to the attacker.

1. The attacker calls the "cancelCampaign" function to delete the campaign created in step 1. As can be seen from the function code, the vulnerable contract deletes the data of the campaign. And call the "withdrawTokens" function of the TransferHelper library to return the NOBL tokens transferred by the attacker in step 1 to the "campaign.manager" (attacker). At this point, the campaign has been successfully canceled. However, the NOBL token usage quota authorized by the vulnerability contract to the attacker in step 1 has not been deleted simultaneously. Therefore, the attacker also has the power to spend the NOBL tokens of the vulnerable contract at this time.

   

   

2. The attacker repeated steps 1 and 2 25 times, and finally obtained 680000 * 25 from the vulnerable contract. = usage limit of 17,000,000 NOBL tokens.

2. Harvesting stolen money

In the stage of harvesting stolen money, the attacker directly calls the "transferFrom" function of the NOBL token to transfer the NOBL token from the vulnerable contract Turning to the attacker's EOA address, since the attacker has already obtained the right to spend the NOBL tokens held by the vulnerable contract during the attack implementation stage, the limit verification in the "transferFrom" function can pass smoothly, and ultimately the attacker successfully steals Withdrew the NOBL tokens in the vulnerable contract.

Please check the transaction for specific details: https://etherscan.io/tx/0x47da1ac72d488f746865891c9196c1632ae04f018b285b762b2b564ad1d3a9e5

Transactions involved in the attack

Through ZAN KYT data analysis, before the attacker took away the NOBL token from the vulnerable contract, he used the contract vulnerability to allow the vulnerable contract to give the attacker the transaction hash of approve token as follows (only transactions on Ethereum are listed):

Currently, the attacker has transferred part of the illegal gains to another address 0xd84f48b7D1AaFA7bd5905c95c5d1ffB2625AdA46. There is currently no other action. The developer of the claims contract (0x5a4bC2bdA1f6B9929b6efdCef4728246bEc4C635) contacted the attacker through Blockscan chat, admitted the vulnerability in the contract and assumed that their behavior was a white hat operation, hoping that the attacker would contact them within 24 hours. connect.

Security Suggestions

After analyzing this attack, we have the following suggestions:

1. Strictly review the operation of token authorization in the project . Project developers and contract auditors should clarify which business scenarios require token authorization and which business scenarios require recycled token authorization to avoid unrecovered token authorization or unexpected redundant authorizations from being used by attackers.

2. The project should set up an emergency suspension mechanism. It is recommended that projects involving capital circulation establish a complete suspension mechanism so that losses can be stopped in time when an attack occurs.

This article was co-written by ZAN Team’s Cara (X account @Cara6289) and XiG (X account @SHXiGi).

The above is the detailed content of Analysis of Hedgey attack incident: loss of tens of millions of dollars in token authorization. For more information, please follow other related articles on the PHP Chinese website!