背景

Blast は、Blur の創設者である Pacman (Tieshun Roquerre、別名 Tieshun) によって立ち上げられたイーサリアム レイヤー 2 ネットワークであり、2 月 29 日にメインネットを立ち上げました。

攻撃されたプロジェクト Munchables は、Blast が開催した Bigbang コンペティションで優勝した高品質なプロジェクトでした。

Blast 担当者は、Blast メインネット上で ETH を約束したユーザーに通常のポイントを発行します。

ユーザーがBlastエコシステム上のDeFiプロジェクトに参加することを奨励するために、Blast担当者は推奨する高品質のプロジェクトを選択し、ユーザーがより迅速なポイント増加とゴールドポイントを取得するためにDeFiに2回目のETHを約束することを奨励します。数人のユーザーが、Blast メインネットワーク上で約束された ETH を、新しく作成された DeFi プロジェクトに約束しました。

これらの DeFi プロジェクトの成熟度とセキュリティはまだ調査されておらず、これらの契約にユーザーの数千万ドル、さらには数億ドルを保護するのに十分なセキュリティ上の考慮事項があるかどうかも検討されていません。

イベント概要

Blast メインネットがオンラインになってから 1 か月も経たないうちに、2024 年 3 月 21 日に SSS トークン (Super Sushi Samurai) に対する攻撃が発生しました。トークン コントラクトに転送ロジック エラーがあり、攻撃者がその SSS トークンを増やすことができました。指定口座の残高がゼロになったため、プロジェクトは最終的に 1,310 ETH (約 460 万ドル) 以上を失いました。

SSS トークン攻撃から 1 週間も経たないうちに、Blast に対してさらに大規模な攻撃が発生し、Munchables プロジェクトは攻撃者によって 17413.96 ETH (総額約 6,250 万米ドル) とともに一掃されました。

攻撃トランザクションが発生してから 30 分後、プロジェクト契約の 73.49 WETH もハッキングされた別のアドレスによって盗まれました。

現時点では、プロジェクト当事者の契約アドレスにはまだ 7,276 WETH、7,758,267 USDB、および 4 ETH が保管されており、これらはいつハッカーの手に渡る可能性があり、ハッカーはすべての資金を奪う権限を持っています。プロジェクト全体の費用は約 9,700 万ドルに達し、リスクにさらされています。

事件直後、X（Twitter）の著名なオンチェーン探偵であるZachXBT氏は、今回の攻撃の根本原因は某国からのハッカーの雇用にあると指摘した。

「某国のハッカー」がどのようにして1億ドル近い価値の攻撃を完了させたのかを詳しく見てみましょう。

現場復旧

[UTC+0] 2024 年 3 月 26 日 21:37 (攻撃の 5 分後)、マンチャブルは X (Twitter) に攻撃を受けていると公式に投稿しました。

オンチェーン探偵ザックの調査によると、攻撃者はゲーム開発の仕事をしに来たということです。彼は非常に乱暴で、本当に中国のハッカーのようでした。私たちは一ヶ月以内に彼を解雇しました。彼はまた、私たちに自分のチームの一人を雇わせようとしました友人たち、彼もおそらくハッカーだったでしょう。ハッカーでした。」

この攻撃によりコミュニティユーザーに多大な損害が発生したため、直ちにオンチェーン調査を開始しましたが、今回は「某国のハッカー」による攻撃内容を詳しく見ていきましょう。

[UTC+0] 2024 年 3 月 26 日 21:32、17413.96 ETH に関わる攻撃が発生しました。

この攻撃トランザクションは Blastscan を通じて確認できます: https://blastscan.io/tx/0x9a7e4d16ed15b0367b8ad677eaf1db6a2a54663610696d69e1b4aa1a08f55c95

破損したコントラクト (0x29..1F) は、ユーザーがプレッジした資金を保管するプロキシ コントラクトであり、攻撃者がプレッジ コントラクトのロック解除機能を呼び出し、すべての権限チェックを通過し、コントラクト内の資金を転送したことがわかります。すべての ETH は攻撃者アドレス 1 (0x6E..c5) に送信されます。

攻撃者は引き出し動作と同様のロック解除関数を呼び出し、破損したコントラクト (0x29..1F) の ETH の大部分を奪い取ったようです。

プロジェクトの当事者は金庫の鍵を閉め忘れましたか?

破損したコントラクト (0x29..1F) には、ロック解除に関連する 2 つのチェックがあります。1 つずつ見てみましょう。

まず、権限の検証プロセス中に、現在の msg.sender、つまりハッカー アドレス 1 (0x6E..c5) が登録されているかどうかを確認するために、コントラクトの isRegistered メソッド (0x16..A0) が呼び出されたことがわかりました。 :

答えは「検証に合格しました」です。

これには、コントラクト (0x16..A0) とそれに対応する最新の論理コントラクト (0xe7..f1) が含まれます。

[UTC+0] 2024 年 3 月 24 日 08:39 (攻撃の 2 日前) に、コントラクト (0x16..A0) に対応する論理コントラクトがアップグレードされました。

論理契約アップグレード トランザクション:

https://blastscan.io/tx/0x9c431e09a80d2942319853ccfdaae24c5de23cedfcef0022815fdae42a7e2ab6

ロジック コントラクトは 0xe7..f1 に更新されます。

元の論理コントラクト アドレスは、0x9e..CD です。

https://blastscan.io/tx/0x7ad050d84c89833aa1398fb8e5d179ddfae6d48e8ce964f6d5b71484cc06d003

現時点では、ハッカーがエージェント契約のロジック実装契約を更新し、0x9e..CD を悪意のある 0xe7..f1 に変更し、検証権限のバイパスを完了したと考えられます。

本当か？

Web3.0 では、推測したり他人の意見を聞いたりする必要はなく、自分自身で答えを得るテクノロジーを習得するだけで済みます。

2 つのコントラクト (オープンソース コントラクトではない) を比較すると、元の 0x9e..CD コントラクトと更新された 0xe7..f1 コントラクトの間には明らかな違いがいくつかあることがわかりました。

0xe7..f1 の初期化関数部分は次のように実装されます。

0x9e..CD の初期化関数部分は次のように実装されます。

攻撃者が元の論理コントラクト (0x9e..CD) のレジスタとして攻撃者アドレス (0x6e..c5) を設定し、他に 2 つの攻撃者アドレス 0xc5..0d と 0xbf. も存在することがわかります。87 はまた、フィールド 0 は初期化時にブロック時刻に設定されますが、フィールド 0 の使い方については後述します。

実際、私たちの予想に反して、バックドアによる実際のロジック コントラクトは最初から存在しており、その後の更新は正常でした。

待ってください。このアップデートは 2024 年 3 月 24 日 [UTC+0] 08:39 (攻撃の 2 日前) に表示されました。つまり、このインシデントの前に、ロジック コントラクトはバックドアのないコントラクトになっていました。なぜですか? 攻撃者は完了できますか?攻撃は後ですか？

これはデリゲートコールのため、実際の状態ストレージの更新はコントラクト (0x16..A0) 内にあり、その結果、ロジック コントラクトが後でバックドアなしでロジック コントラクト 0xe7..f1 に更新されたとしても、コントラクト (0x16. .A0) はまだ復元されません。

確認してみましょう:

コントラクト内の対応するスロット (0x16....A0) に数値があることがわかります。

これにより、攻撃者は isRegistered メソッドのチェックに合格できます。

その後、攻撃者はバックドアがすでに仕掛けられているという事実を隠すために、バックドア コントラクトを通常のコントラクトに変更します。

さらに、ロック解除プロセスには 2 番目の検証も含まれます。

ロック時間チェックに関しては、ロックされた資産が期限切れになる前に転送されないことを確認する部分です。

攻撃者は、ロック解除が呼び出されたときのブロック時間が、必要なロック有効期限 (フィールド 3) よりも長いことを確認する必要があります。

検証のこの部分には、破損したコントラクト (0x29..1F) と、対応する論理コントラクト 0xf5..cd が含まれます。

2024 年 3 月 21 日 [UTC+0] 11:54 (攻撃の 5 日前) のトランザクションでは、

https://blastscan.io/tx/0x3d08f2fcfe51cf5758f4e9ba057c51543b0ff386ba53e0b4f267850871b88170

破損したコントラクト (0x29..1F) コントラクトの元の論理コントラクトは 0x91..11 であり、そのわずか 4 分後の時刻であることがわかります。

https://blastscan.io/tx/0xea1d9c0d8de4280b538b6fe6dbc3636602075184651dfeb837cb03f8a19ffc4f

0xf5..cd にアップグレードされました。

また、2 つのコントラクトを比較すると、攻撃者が以前と同様に初期化関数でもトリックを行っていることがわかります。

0xf5..cd の初期化関数の部分的な実装:

0xf5..cd にアップグレードされました。

また、2 つのコントラクトを比較すると、攻撃者が以前と同様に初期化関数でもトリックを行っていることがわかります。

0xf5..cd の初期化関数の部分的な実装:

0x91..11 の初期化関数の部分的な実装:

同じ手口を再度使用してETHの量やロック解除時間を改ざんし、通常の契約書に置き換えて他者を欺いたことが明らかであり、プロジェクトチームとセキュリティ研究者がデバッグしていたところ、、表示される論理的なコントラクトはすべて正常であり、コントラクトはすべて非オープンソースのコントラクトであるため、問題の核心を明確に理解することはさらに困難です。

これまでのところ、17413 ETH に関わるこの取引と攻撃者がどのように実行したかはわかっていますが、この事件の背後にある情報はこれだけなのでしょうか?

上記の分析では、実際にハッカーがコントラクトに 3 つのアドレスを組み込んでいることがわかりました。

0x6e..c5 (攻撃者のアドレス 1)

0xc5..0d (攻撃者のアドレス 2)

0xbf..87 (攻撃者のアドレス 3)

ただし、上で見つけた攻撃トランザクションでは 0x6e..c5 しか確認できませんでしたが、他の 2 つのアドレスは何をしたのでしょうか?そして、address(0)、_dodoApproveAddress、および _uniswapV3Factorty にはどのような秘密が隠されているのでしょうか?

まず、同じ方法で 73.49 WETH を盗んだ攻撃者のアドレス 3 (0xbf..87) を見てみましょう。

https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233

そして、gas の送信元アドレス (0x97..de) を攻撃し、0xc5..0d (攻撃者アドレス 2) と 0xbf..87 (攻撃者アドレス 3) の両方に手数料を支払います。

ガスソースアドレス (0x97..de) を攻撃する 0.1 ETH のソースは、owlto.finance (クロスチェーンブリッジ) から来ています。

0xc5..0d（攻撃者アドレス2）は手数料を受け取った後は攻撃をしませんでしたが、実は裏の計画を抱えていたので見ていきましょう。

実際、救出後の公式トランザクションによると、被害を受けた契約の元のアドレス (0x29..1F) は 73.49 WETH だけではなく、攻撃が終了するまでまだ 7276.5 WETH と 7758267 USDB が存在していました。

実際、救出後の公式トランザクションによると、被害を受けた契約の元のアドレス (0x29..1F) は 73.49 WETH だけではなく、攻撃が終了するまでまだ 7276.5 WETH と 7758267 USDB が存在していました。

救助協定:

https://blastscan.io/tx/0x1969f10af9d0d8f80ee3e3c88d358a6f668a7bf4da6e598e5be7a3407dc6d5bb

攻撃者は元々これらの資産を盗むことを計画しており、アドレス 0xc5..0d (攻撃者アドレス 2) が元々 USDB を盗むために使用されていたことがわかります。

ここの _dodoApproveAddress は 0x0000000000000000000000004300000000000000000000000000000000000003 です

usdbのアドレスです

0xbf..87 (攻撃者のアドレス 3) このアドレスは次のものを盗むために使用されます。

0xbf..87 (攻撃者のアドレス 3) このアドレスは次のものを盗むために使用されます。

ここの _uniswapV3Factory は 0x00000000000000000000000430000000000000000000000000000000000004 です。

ウェスの住所です

そして、0x6e..c5 (攻撃者のアドレス 1) は、ネイティブ資産 ETH であるアドレス (0) を盗む役割を果たします。

field0 を設定すると、攻撃者は次のロジックを通じて対応する資産を盗むことができます。

質問

理論的には、彼はすべての資産、つまり残りのWETHとUSDBを盗むことができます。

0xbf..87 (攻撃者のアドレス 3) は 73.49 WETH のみを盗みました。0xbf..87 (攻撃者のアドレス 3) は実際に 7350 WETH をすべて奪うことができます。0xc5..0d (攻撃者のアドレス 2) を使用することもできます) は 7758267 USDB をすべて奪いました、なぜ少量のWETHを摂取しただけで停止したのかはわかりませんが、有名なチェーン探偵による詳細な内部調査が必要になる可能性があります。

0xbf..87 (攻撃者のアドレス 3) は 73.49 WETH のみを盗みました。0xbf..87 (攻撃者のアドレス 3) は実際に 7350 WETH をすべて奪うことができます。0xc5..0d (攻撃者のアドレス 2) を使用することもできます) は 7758267 USDB をすべて奪いました、なぜ少量のWETHを摂取しただけで停止したのかはわかりませんが、有名なチェーン探偵による詳細な内部調査が必要になる可能性があります。

https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233

誰もが知っているように、Blast メイン ネットワークは集中型の方法でこれらの ETH を傍受し、ユーザーに重大な損失を引き起こすことなく永続的にここに留まらせることが可能ですが、これらの ETH がイーサリアム メイン ネットワークに入ると、傍受する方法はありません。それ。

私たちは現在のBlastクロスチェーンブリッジを評価しました.公式のクロスチェーンブリッジの数に制限はありませんが、脱出するまでに14日を必要とし、Blast当局が迎撃計画を準備するのに十分な時間です。

サードパーティのクロスチェーン ブリッジは、攻撃者の料金源と同様に、ほぼリアルタイムで入金され、クロスチェーンを迅速に完了できます。

実際、攻撃者は最初の瞬間 (攻撃から 2 分以内) にクロスチェーンを実行しました。

https://blastscan.io/tx/0x10cf2f2b884549979a3a1dd912287256229458ef40d56df61738d6ea7d9d198f

さらに、資金がイーサリアムのメインネットワークに到着するまでに 20 秒かかりました 理論的には、クロスチェーンブリッジが手動で介入する前に、攻撃者はクロスチェーンを継続し、チェーン間で大量の ETH を転送することができます。

一度に 3 ETH しか使用できない理由については、Blast から ETH までのクロスチェーン ブリッジの流動性制限が理由です。

一度に 3 ETH しか使用できない理由については、Blast から ETH までのクロスチェーン ブリッジの流動性制限が理由です。

Blast をサポートする別のクロスチェーン ブリッジは、さらに少ないサポートをサポートします。

このクロスチェーン取引後、攻撃者は他のクロスチェーン操作を継続しませんでしたが、理由は不明ですが、「某国のハッカー」がブラストから資金を引き出すための十分な準備をしていなかったものと思われます。

攻撃後に何が起こったのか

コミュニティ ユーザー Nearisbuilding からのフィードバックに基づいて、彼は攻撃者の身元情報をさらに見つけ、攻撃者に資金の返還を促す方法を見つけました。

https://twitter.com/Nearisbuilding/status/1772812190673756548

最終的に、暗号化コミュニティの注目と努力により、「某国のハッカー」は、身元暴露を恐れたのか、上記 3 つの攻撃者アドレスの秘密鍵をプロジェクト チームに提供し、すべて返却しました。プロジェクトチームは救済取引も実施し、破損した契約書からすべての資金を複数署名契約書に移して保管する。