SharkTeam：Hedgey Finance ハッキング事件の分析
TechFlow厳選深潮セレクト
SharkTeam：Hedgey Finance ハッキング事件の分析
今回の事件の根本的な原因は、プロジェクト側のスマートコントラクトが実装ロジック上にトークン承認の脆弱性を有していたことにある。
Web3業界の深掘り報道に専念し潮流を洞察執筆：SharkTeam
2024年4月19日、Hedgey Financeは複数の攻撃トランザクションを受け、200万ドル以上の損失を被りました。
SharkTeamはこの事件について即座に技術分析を行い、セキュリティ対策をまとめました。今後同様のプロジェクトが教訓とし、ブロックチェーン業界全体で安全体制を築き上げていただきたいと考えます。
一、攻撃トランザクションの分析
Hedgey Financeは複数の攻撃者により繰り返し攻撃され、トークン承認の脆弱性を悪用して、ClaimCampaignsコントラクト内の大量のトークンが盗まれました。
被害額が最も大きかったトランザクションを例に挙げると、約130万ドルの損害がありました：
攻撃トランザクション：0x2606d459a50ca4920722a111745c2eeced1d8a01ff25ee762e22d5d4b1595739
攻撃者アドレス：0xded2b1a426e1b7d415a40bcad44e98f47181dda2
攻撃用コントラクト：0xc793113f1548b97e37c409f39244ee44241bf2b3
ターゲットコントラクト：0xbc452fdc8f851d7c5b72e1fe74dfb63bb793d511（ClaimCampaigns）
このトランザクションでは、ClaimCampaignsコントラクトから直接1,303,910.12 USDCが移転されました。トランザクションの詳細は以下の通りです：
実際に攻撃を実行したトランザクションは
0xa17fdb804728f226fcd10e78eae5247abd984e0f03301312315b89cae25aa517（以下、0xa17fと略記）
攻撃手順は以下の通りです：
1 Balancerから130.5万USDCのフラッシュローンを取得。
2 ClaimCampaignsコントラクトのcreateLockedCampaign関数を呼び出す。この関数内で、攻撃コントラクトは130.5万USDCをClaimCampaignsコントラクトに預け入れ、その後ClaimCampaignsコントラクトはその130.5万USDCを攻撃コントラクトに対して承認します。
3 ClaimCampaignsコントラクトのcancelCampaign関数を呼び出す。この関数内で、攻撃コントラクトは預け入れた130.5万USDCを引き出しますが、createLockedCampaign関数で設定されたUSDCの承認は解除されません。
4 攻撃コントラクトがBalancerのフラッシュローンを返済。
このトランザクションにおいて、攻撃コントラクトはClaimCampaignsコントラクトから130.5万USDCを引き出した後も、ClaimCampaignsコントラクトによる130.5万USDCの承認が維持されたままになっています。そのため、攻撃コントラクトはUSDCのtransferFrom関数を直接呼び出して、再度ClaimCampaignsコントラクトから130.5万USDCを移転することが可能になります。これがまさにトランザクション0xa17fdb804728f226fcd10e78eae5247abd984e0f03301312315b89cae25aa517で実現された内容です。
上記2つのトランザクションを通じて、攻撃者はClaimCampaignsコントラクトから130.5万USDCを盗み出しました。
USDC以外にも、攻撃者はこの脆弱性を利用してClaimCampaignsコントラクトから大量のNOBL Tokenも盗み取り、合計で200万ドル以上にのぼる損害となりました。
二、脆弱性の分析
今回の事件の根本的な原因は、プロジェクト側のスマートコントラクトの実装ロジックにトークン承認の脆弱性があり、攻撃者がターゲットコントラクトがmsg.senderに対して行ったトークン承認を繰り返し悪用できる点にあります。
スマートコントラクトClaimCampaignsのcreateLockedCampaign関数は、msg.senderのトークンをターゲットコントラクトに預け入れるとともに、それらのトークンをmsg.senderに対して承認しています。
一方、cancelCampaign関数は預け入れたトークンを引き出す機能を持ちますが、トークンの承認を取り消す処理が含まれていません。
攻撃者はこの脆弱性を悪用し、直接トークンのtransferFrom関数を呼び出して、ターゲットコントラクトから承認済みのトークンを再び移転させました。
三、セキュリティに関する提言
今回の攻撃事件を踏まえ、開発プロセスにおいて以下の点に注意すべきです：
（1）プロジェクトの設計・開発においては、ロジックの一貫性と厳密性を保つ必要があります。特に資産の移転に関わる処理では、トークンの移転と同時に承認数量も適切に管理し、トークンを移転した後も承認が残ってしまうような事態を回避しなければなりません。
（2）プロジェクトの本番展開前に、第三者の専門セキュリティ監査会社によるスマートコントラクトの監査を必ず実施する必要があります。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
