DAOrayaki: 0xhaveat Multisig が盗まれた分析
DAOrayaki DAOリサーチボーナスプール:
ファンディングアドレス: DAOrayaki.eth
DAOrayaki DAOリサーチボーナスプール:
ファンディングアドレス: DAOrayaki.eth
投票経過: DAO委員会/7が可決
合計賞金: 90 USDC
原作者: ルーカス・ショール
原題: The 0xhaveat Multisig Got Drained: An Analysis
副題
分析: 0xhaveat マルチシグが盗まれました
Gnosis Safe ユーザーが深刻かつ高度なフィッシング攻撃を受け、その結果、プロジェクトのマルチシグが枯渇しました。
重要: 現在の分析によれば、これは特定の Gnosis Safe ユーザーに対する標的型攻撃であり、この攻撃が他のユーザーに影響を与えたという兆候はありません。また、この攻撃ではスマート コントラクトの脆弱性は悪用されませんでしたが、代わりにフィッシング手法が使用され、マルチシグ所有者に悪意のあるトランザクションに署名させられました。
このブログ投稿は、0xhaveat 事件に光を当て、そこから学んだことを詳しく説明することを目的としています。このインシデントレポートを完全に客観的なものにするために、オンチェーンおよびバックエンド (トランザクションインデクサー) を通じて収集した直接のデータのみを含めました。 0xhaveat チームの見解はここで読むことができます。まず、何が起こったのかを分析することから始めましょう...
トロイの木馬
このインシデントの主な原因は、次の公式 Gnosis Safe スマート コントラクトを模倣する 2 つの悪意のあるコントラクトです。
安全なシングルトン: これはコア ロジック コントラクトです。各 Safe は、特定の Safe シングルトンを指すプロキシ コントラクトです。ユーザーは、機能を追加するなどの目的で、新しいシングルトンを指すように金庫をアップグレードできます。
Safe Multisend: これは、Safe が複数のトランザクションを 1 つに結合できるようにする中間スマート コントラクトです。
この記事では、悪意のあるコントラクトを Evil Singleton および Evil Multisend と呼びます。 Evil Multisend コントラクトは、11 月 23 日にこのアドレスに展開されました。このコントラクトの特別な点は、バッチ トランザクションを許可するだけでなく、同じトランザクション内で Safe のシングルトンも変更できることです。同じ日に、Evil Singleton がこの住所に配備されました。 Evil Singleton は、最初はすべてのインタラクションを元の Singleton に転送するトロイの木馬プログラムとして機能しますが、サードパーティが Safe にアクセスできるようにするバックドアを備えています。
それは罠だ！
0xhaveat の物語は、Evil Multisend 契約が展開されてから数時間後に始まります。 Evil Multisend コントラクトと対話する 0xhaveat Multisig でトランザクションが提案されました。関係者全員にとって、これはトランザクション ビルダー セーフ アプリを使用した通常の一括トランザクションのように見えます。ただし、これは手の込んだトランザクションで、一見すると通常の Multisend トランザクションのように見えますが、実は Safe の Singleton を Evil Singleton に更新することも行っています。
Evil Singleton のアクティブ化に関する技術的な詳細については、こちらをご覧ください。
転換点
Safe を Evil Singleton にアップグレードした後、7 日間何も起こりませんでした。その間、0xhaveat 保管庫は徐々に 100 万ドル相当のデジタル資産に成長しました。攻撃者が、バックドアが以前に発見されていないことを願い、実際の攻撃を実行する前にハニーポットを大きくしたいと考えていることは明らかです。 11月30日に攻撃が始まった。ハッカーは、Evil Singleton をアクティブにするトランザクションを作成し、サードパーティのアカウントが金庫内の資産を完全に制御できるようにしました。
資金が流出した
Evil Singleton がアクティブ化されてからわずか 30 分後に、攻撃者はすべての資金を自分の口座に引き出すことができました。その後、攻撃者は Uniswap と Sushiswap を介してすべての資産を ETH に変換しました。生成された ETH は複数のトランザクションで Tornado Cash コントラクトに送信され、これがパスの終端となります。
それで、いったい何が起こったのでしょうか？
これまでに収集した情報から、マルチシグの署名者キーの 1 つが侵害されたことは明らかです。これは、バックドアの実装につながる悪意のあるトランザクションが、バックエンド データに基づいて Multisig の署名者によって提案されたものであるためです。これがどのようにして起こったのかを正確に言うことは不可能ですが、おそらくその原因となった出来事には大きく分けて 2 つのカテゴリがあります。
フィッシング
所有者が誤解されて、0xhaveat Multisig のセキュリティを危険にさらすトランザクションを提案される可能性のある方法がいくつかあります。考えられるオプションは次のとおりです。
不正なブラウザ拡張機能: ブラウザ拡張機能は便利ですが、危険な場合もあります。拡張機能は Web アプリケーションのコンテンツを自由に変更できるためです。そのため、ユーザーをだまして悪意のあるトランザクションを実行させるために、不正なブラウザ拡張機能が Gnosis Safe Web インターフェイスの変更に使用された可能性があります。
悪意のあるインターフェイス: ここで述べたように、Gnosis Safe のセキュリティは、アカウントとの対話に使用されるインターフェイスの整合性に依存します。影響を受ける 0xhaveat ユーザーは、公式の Gnosis Safe インターフェイスを模倣したインターフェイスを操作した可能性がありますが、通常のトランザクションの宛先アドレスを Evil Multisend コントラクトに変更することで、実質的に悪意のあるトランザクションを作成しました。
サプライ チェーン攻撃/侵害された Web サイト: 問題の原因は公式 Gnosis Safe ソフトウェアの敵対的乗っ取りである可能性がありますが、現在の評価ではそうではないことが示されています (詳細)。すべての信号は、これが公式の Gnosis Safe インターフェイスに関する一般的な問題ではなく、0xhaveat Multisig に対する標的型攻撃であることを示しています。ただし、この地域の状況については引き続き調査と観察を続けます。
悪意のある所有者
2 番目の仮説オプションは、所有者がだまされて悪意のある取引を行ったのではなく、自発的に取引を行ったというものです。 Multisig の 2 人の署名者のうちの 1 人が、もう 1 人を騙して不正なトランザクションに署名させ、Multisig を中断させました。 0xhaveat チームの誠実さを疑う理由はありません。しかし、分析を徹底するには、これを出来事のもっともらしい説明として考慮する必要があります。
Gnosis Safe チームから学んだ教訓
マルチ送信アドレスを公開する
トランザクションでどのマルチ送信コントラクトが使用されたかを確認できるように、セーフ Web UI にはマルチ送信コントラクトのアドレスが明示的に表示されます。続きを読む。
画像の説明
トランザクションの詳細には、検証のために完全なマルチセンド コントラクト アドレスが表示されます
未知のマルチ送信トランザクションのデコードを防止する
予期しないデリゲート呼び出しにフラグを付ける
トランザクションがデリゲートを使用して不明なコントラクトを呼び出す場合の明示的な警告を追加しました。これは、トランザクションには特別な注意が必要であることをユーザーに知らせるもう 1 つの方法です。
画像の説明
Gnosis にとって未知のコントラクトを介して行われたデリゲート呼び出しにはフラグが立てられます
Gnosis Safe ユーザーへのアドバイス
私たちの目標は、将来そのような状況が起こらないよう安全メカニズムを導入することですが、Gnosis Safe を操作する際の運用上のセキュリティ慣行を Gnosis Safe ユーザーに思い出させることも重要です。
インターフェイスの整合性の検証: 悪意のあるインターフェイスは、共同署名者をだまして悪意のあるトランザクションに署名させることで、マルチシグのセキュリティ全体を危険にさらす可能性があります。 Gnosis Safe Web アプリケーションを使用する場合は、必ず公式アプリケーションへのリンクをブックマークし、URL とセキュリティ証明書を確認してください。あるいは、Gnosis Safe デスクトップ アプリの使用を開始することをお勧めします。
DelegateCall には注意してください。DelegateCall は強力なツールであり、たとえば、金庫がトランザクションをバッチ処理できるようになります。しかし、それには大きなリスクも伴います。したがって、Gnosis Safe ユーザーは、DelegateCall を使用してトランザクションを識別する際に特別な注意を払う必要があります。トランザクション データを検証するときは、正しいマルチ送信宛先アドレスが使用されていることを確認してください。 Gnosis で検証された Multisend 実装は、このリストにあります。
画像の説明
結論は
結論は
参考文献
https://etherscan.io/address/0x3cb0652856d7eabe51f1e3cceda99c93b05d7cea
https://etherscan.io/address/0x09afae029d38b76a330a1bdee84f6e03a4979359
https://bafybeiat2xp7cicrlpq3h57wdnz4pzaoby2cx62c3lprh3lzgrworcitly.ipfs.infura-ipfs.io/Exploit_Info.pdf
https://blog.gnosis.pm/the-impact-of-phishing-on-web-3-0-a62385c81310
https://github.com/gnosis/safe-react/issues/3091
https://github.com/gnosis/safe-react/issues/3090
