背景

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 にはどのような秘密が隠されているのでしょうか?

2番目のシーン

まず、同じ方法で 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 が存在していました。

救助協定:

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

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

ここの _dodoApproveAddress は 0x0000000000000000000000004300000000000000000000000000000000000003 です

usdbのアドレスです

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を摂取しただけで停止したのかはわかりませんが、有名なチェーン探偵による詳細な内部調査が必要になる可能性があります。

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