あるプロジェクトの契約の脆弱性により、大規模なトークンの増発が発生し、ハッカーがBNBを現金化して市場に動揺を引き起こした。

12月2日、オンチェーンデータの監視によると、あるプロジェクトがハッカー攻撃を受け、大量のトークンが不正に増発されました。攻撃者は増発されたトークンを使用してDEXで一部のBNBと交換し、残りはウォレットに保留しました。さらに、ハッカーはある匿名送金サービスを利用して資金移転を行いました。この事件により、当該トークンの流動性プールが枯渇し、通貨の価格が大幅に下落しました。同時に、攻撃者が増発されたトークンを利用して担保貸出を行ったため、貸出プラットフォームにも損失が生じました。

! Ankrのハッキング事件のオンチェーン分析:10兆aBNBcの追加発行はどこから来たのか?

複数の取引データを分析した結果、呼び出し元は異なるアドレスを使用していたが、すべてトークンの増発を引き起こしたことが判明した。さらに調査したところ、プロジェクトは攻撃を受ける前にコントラクトのアップグレードを行い、新しいロジックコントラクト内の増発関数は必要な権限検査が行われていなかった。

! Ankrのハッキング事件のオンチェーン分析:10兆aBNBcの追加発行はどこから来たのか?

攻撃者はプロキシコントラクトを通じてロジックコントラクト内の特定の関数を呼び出しましたが、その関数には権限チェックが欠如していたため、トークンの不正発行が発生しました。攻撃を受けた後、プロジェクトチームは迅速にロジックコントラクトを更新し、新しいバージョンでは発行関数に権限検証メカニズムを追加しました。

! Ankrのハッキング事件のオンチェーン分析:10兆aBNBcの追加発行はどこから来たのか?

現在、ハッカーは一部の増発されたトークンをBNBに交換して移転しましたが、依然として大量の違法に増発されたトークンがそのウォレットに残っています。

今回の攻撃の根本的な原因は、契約のアップグレード時に、新しい論理契約の中の増発関数に必要な権限検査が欠如していたことです。これは、安全監査やテストを受けていない契約コードを使用したためなのか、それともプライベートキーの漏洩によってハッカーが契約を独自にアップグレードしたためなのかは現在不明です。いずれにせよ、この事件は再びユーザーとプロジェクト側に対し、ウォレットのプライベートキーとリカバリーフレーズを適切に保管する重要性を思い出させ、契約のアップグレードを行う際には全面的なセキュリティテストを実施しなければならないことを強調しています。

! Ankrのハッキング事件のオンチェーン分析:10兆aBNBcの追加発行はどこから来たのか?