SharkTeam: Analysis of the Hedgey Finance Attack

avatar
SharkTeam
4 months ago
This article is approximately 659 words,and reading the entire article takes about 1 minutes
On April 19, 2024, Hedgey Finance suffered multiple attacks and suffered losses of more than $2 million. SharkTeam immediately conducted a technical analysis of the incident and summarized the security precautions. We hope that subsequent projects can learn from it and build a security line of defense for the blockchain industry.

On April 19, 2024, Hedgey Finance suffered multiple attack transactions, resulting in losses of more than $2 million.

SharkTeam: Analysis of the Hedgey Finance Attack

SharkTeam conducted a technical analysis of the incident and summarized security precautions at the first opportunity. We hope that subsequent projects can learn from this incident and jointly build a security line of defense for the blockchain industry.

1. Analysis of attack transactions

Hedgey Finance was attacked multiple times by an attacker who exploited a token approval vulnerability to steal a large number of tokens from the ClaimCampaigns contract.

Take the largest transaction as an example, involving approximately $1.3 million:

Attack transaction: 0x2606d459a50ca4920722a111745c2eeced1d8a01ff25ee762e22d5d4b1595739

Attacker: 0xded2b1a426e1b7d415a40bcad44e98f47181dda2

Attack contract: 0xc793113f1548b97e37c409f39244ee44241bf2b3

Target contract: 0xbc452fdc8f851d7c5b72e1fe74dfb63bb793d511 (ClaimCampaigns)

This transaction directly transferred 1,303,910.12 USDC from the ClaimCampaigns contract. The transaction details are as follows:

SharkTeam: Analysis of the Hedgey Finance Attack

The transaction that actually initiated the attack was

0xa17fdb804728f226fcd10e78eae5247abd984e0f03301312315b89cae25aa517 (abbreviated as 0x a 17 f)

The attack process is as follows:

SharkTeam: Analysis of the Hedgey Finance Attack

1 Flash loan 1.305M USDC from Balancer.

2 Call the createLockedCampaign function in the ClaimCampaigns contract. In this function, the attack contract will deposit 1.305M USDC into the ClaimCampaigns contract, and then the laimCampaigns contract will approve the transferred 1.305M USDC for the attack contract to use.

3 Call the cancelCampaign function in the ClaimCampaigns contract. In this function, the attack contract withdraws the 1.305M USDC deposited, but the USDC approved to the attack contract in the createLockedCampaign function is not canceled.

4 The attack contract repays Balancer’s flash loan.

In this transaction, after the attack contract withdraws the 1.305M USDC stored in the ClaimCampaigns contract, the 1.305M USDC approved by the ClaimCampaigns contract to the attack contract is not cancelled, so the attack contract can directly call the transferFrom function of USDC to transfer 1.305M USDC from the ClaimCampaigns contract again. This is also the function implemented by the transaction 0xa17fdb804728f226fcd10e78eae5247abd984e0f03301312315b89cae25aa517.

Through the above two transactions, the attacker stole 1.305M USDC from the ClaimCampaigns contract.

In addition to USDC, the attacker also exploited this vulnerability to steal a large amount of NOBL Tokens from the ClaimCampaigns contract, which together with USDC, had a total value of more than $2 million.

2. Vulnerability Analysis

The root cause of this incident is that there is a token approval vulnerability in the implementation logic of the projects smart contract, which allows the attacker to repeatedly transfer the target contract to approve the token in msg.sender.

The createLockedCamaign function of the ClaimCampaigns smart contract will deposit the tokens of msg.sender into the target contract and approve these tokens to msg.sender.

SharkTeam: Analysis of the Hedgey Finance Attack

The cancelCampaign function will withdraw the deposited Tokens, but it does not cancel the approval of the tokens.

SharkTeam: Analysis of the Hedgey Finance Attack

The attacker exploited this vulnerability and directly called the transferFrom function of Token to transfer the approved tokens from the target contract again.

3. Safety Recommendations

In response to this attack, we should follow the following precautions during development:

(1) During the design and development process of the project, the logical integrity and rigor must be maintained, especially when it comes to the transfer of assets. When transferring tokens, the number of token approvals must be synchronized to avoid the situation where tokens are transferred but the approval is not cancelled.

(2) Before the project goes online, a smart contract audit is required by a third-party professional auditing company.

About Us

SharkTeams vision is to protect the security of the Web3 world. The team is composed of experienced security professionals and senior researchers from all over the world, who are proficient in the underlying theories of blockchain and smart contracts. It provides services including risk identification and blocking, smart contract auditing, KYT/AML, on-chain analysis, and has created an on-chain intelligent risk identification and blocking platform ChainAegis, which can effectively combat the advanced persistent threats (APT) in the Web3 world. It has established long-term cooperative relationships with key players in various fields of the Web3 ecosystem, such as Polkadot, Moonbeam, polygon, Sui, OKX, imToken, Collab.Land, TinTinLand, etc.

Official website: https://www.sharkteam.org

Twitter: https://twitter.com/sharkteamorg

Telegram: https://t.me/sharkteamorg

Discord: https://discord.gg/jGH9xXCjDZ

Original article, author:SharkTeam。Reprint/Content Collaboration/For Reporting, Please Contact report@odaily.email;Illegal reprinting must be punished by law.

ODAILY reminds readers to establish correct monetary and investment concepts, rationally view blockchain, and effectively improve risk awareness; We can actively report and report any illegal or criminal clues discovered to relevant departments.

Recommended Reading
Editor’s Picks