背景
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 もハッカーによって別のアドレスから盗まれました。
現時点では、プロジェクト当事者の契約アドレスにはまだ 7276 WETH、7758267 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
破損したコントラクト (0x 29..1 F) は、ユーザーのプレッジされた資金を保管するプロキシ コントラクトです。攻撃者がプレッジ コントラクトのロック解除機能を呼び出し、すべての権限チェックに合格し、それを転送したことがわかります。コントラクトは攻撃者のアドレス 1 (0x 6 E..c 5) に送信されます。
攻撃者は引き出しのような動作でロック解除関数を呼び出し、侵害されたコントラクト (0x 29..1 F) の ETH の大部分を奪い取ったようです。
プロジェクトの当事者は金庫の鍵を閉め忘れましたか?
破損したコントラクト (0x 29..1 F) には、ロック解除に関連する 2 つのチェックがあります。1 つずつ見てみましょう。
まず、権限の検証プロセス中に、コントラクトの isRegistered メソッド (0x 16..A 0) が呼び出され、現在の msg.sender、つまりハッカーのアドレス 1 (0x 6 E..c) かどうかを確認したことがわかりました。 5) すでに登録されている場合:
答えは「検証に合格しました」です。
これには、コントラクト (0x 16..A 0) とそれに対応する最新の論理コントラクト (0x e 7..f 1) が含まれます。
[UTC+ 0 ] 2024 年 3 月 24 日 08:39 (攻撃の 2 日前) に、コントラクト (0x 16..A 0) に対応する論理コントラクトがアップグレードされました。
論理契約アップグレード トランザクション:
https://blastscan.io/tx/0x9c431e09a80d2942319853ccfdaae24c5de23cedfcef0022815fdae42a7e2ab6
ロジック コントラクトは 0x e 7..f 1 に更新されます。
元の論理コントラクト アドレスは、0x 9 e..CD です。
https://blastscan.io/tx/0x7ad050d84c89833aa1398fb8e5d179ddfae6d48e8ce964f6d5b71484cc06d003
現時点では、ハッカーがプロキシ コントラクトのロジック実装コントラクトを更新し、 0x 9 e..CD を悪意のある 0x e 7..f 1 に変更し、検証権限のバイパスを完了したと考えられます。
本当か？
Web3.0 では、推測したり他人の意見を聞いたりする必要はなく、自分自身で答えを得るテクノロジーを習得するだけで済みます。
2 つのコントラクト (オープンソース コントラクトではない) を比較すると、元の 0x 9 e..CD コントラクトと更新された 0x e 7..f 1 の間には明らかな違いがいくつかあります。
0x e 7..f 1 の初期化関数部分は次のように実装されます。
0x 9 e..CD の初期化関数部分は次のように実装されます。
攻撃者が攻撃者アドレス (0x 6 e..c 5) を元の論理コントラクト (0x 9 e..CD) のレジスタとして設定し、他に 2 つの攻撃者アドレス 0x c 5 ..0 が存在することがわかります。 d, 0x bf..87 も登録されており、フィールド 0 は初期化時にブロック時間に設定されます (フィールド 0 の使用方法については後述します)。
実際、私たちの予想に反して、バックドアによる実際のロジック コントラクトは最初から存在しており、その後の更新は正常でした。
待ってください。この更新は 2024 年 3 月 24 日 [UTC+ 0] の 08:39 (攻撃の 2 日前) に表示されました。つまり、このインシデントの前に、ロジック コントラクトはバックドアのないコントラクトになっていました。なぜですか? 攻撃者はまだ完了できますか?攻撃？
これはデリゲートコールによるもので、実際の状態ストレージの更新はコントラクト (0x 16..A 0) 内にあり、その結果、ロジック コントラクトが後でバックドア 0x e 7.. のないロジック コントラクトに更新されたとしても、その結果が生じます。 f 1 では、コントラクト内の変更されたスロット (0x 16..A 0) はまだ復元されません。
確認してみましょう:
ご覧のとおり、コントラクト内の対応するスロット (0x 16....A 0) には値があります。
これにより、攻撃者は isRegistered メソッドのチェックに合格できます。
その後、攻撃者はバックドアがすでに仕掛けられているという事実を隠すために、バックドア コントラクトを通常のコントラクトに変更します。
さらに、ロック解除プロセスには 2 番目の検証も含まれます。
ロック時間チェックに関しては、ロックされた資産が期限切れになる前に転送されないことを確認する部分です。
攻撃者は、ロック解除が呼び出されたときのブロック時間が、必要なロック有効期限 (フィールド 3) よりも長いことを確認する必要があります。
検証のこの部分には、破損したコントラクト (0x 29..1 F) と、対応する論理コントラクト 0x f 5..cd が含まれます。
2024 年 3 月 21 日 [UTC+ 0] (攻撃の 5 日前) 11:54 のトランザクションで、
https://blastscan.io/tx/0x3d08f2fcfe51cf5758f4e9ba057c51543b0ff386ba53e0b4f267850871b88170
破損したコントラクト (0x 29..1 F) コントラクトの元の論理コントラクトは 0x 91..11 であり、わずか 4 分後の次の時点であったことがわかります。
https://blastscan.io/tx/0xea1d9c0d8de4280b538b6fe6dbc3636602075184651dfeb837cb03f8a19ffc4f
0x f 5..cd にアップグレードされました。
また、2 つのコントラクトを比較すると、攻撃者が以前と同様に初期化関数でもトリックを行っていることがわかります。
0x f 5..cd の初期化関数の部分的な実装:
0x 91..11 の初期化関数の部分的な実装:
同じ手法を再度使用してETHの量やロック解除時間を改ざんし、通常のコントラクトに置き換えて他者を欺いていたことがわかります。プロジェクトチームとセキュリティ研究者がデバッグしていたところ、全員が見られる論理的な契約は正常であり、契約はすべて非オープンソース契約であるため、問題の核心を明確に理解することはさらに困難です。
これまでのところ、17413 ETH に関わるこの取引と攻撃者がどのように実行したかはわかっていますが、この事件の背後にある情報はこれだけなのでしょうか?
上記の分析では、実際にハッカーがコントラクトに 3 つのアドレスを組み込んでいることがわかりました。
0x 6 e..c 5 (攻撃者のアドレス 1)
0x c 5..0 d (攻撃者のアドレス 2)
0x bf..87 (攻撃者のアドレス 3)
ただし、上で見つけた攻撃トランザクションでは 0x 6 e..c 5 しか確認できませんでしたが、他の 2 つのアドレスは何をしたのでしょうか?そして、address(0)、_dodoApproveAddress、および _uniswapV3Factorty にはどのような秘密が隠されているのでしょうか?
2番目のシーン
まず、同じ方法で 73.49 WETH を盗んだ攻撃者のアドレス 3 (0x bf..87) を見てみましょう。
https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233
そして、gas の送信元アドレス (0x 97..de) を攻撃し、0x c 5..0 d (攻撃者アドレス 2) と 0x bf..87 (攻撃者アドレス 3) の両方に手数料を提供します。
ガスソースアドレス (0x 97..de) を攻撃する 0.1 ETH のソースは、owlto.finance (クロスチェーンブリッジ) から来ています。
0x c 5..0 d (攻撃者アドレス 2) は、手数料を受け取った後は攻撃を実行しませんでしたが、実は隠された計画を背負っていました。
実際、公式の救済取引によると、被害を受けた契約の元のアドレス (0x 29..1 F) は 73.49 WETH だけではなく、攻撃が終了するまでまだ 7276.5 WETH と 7758267 USDB が存在していました。
救助協定:
https://blastscan.io/tx/0x1969f10af9d0d8f80ee3e3c88d358a6f668a7bf4da6e598e5be7a3407dc6d5bb
攻撃者は元々これらの資産を盗むことを計画しており、アドレス 0x c 5..0 d (攻撃者のアドレス 2) が元々 USDB を盗むために使用されていたことがわかります。
ここの _dodoApproveAddress は 0x0000000000000000000000004300000000000000000000000000000000000003 です
usdbのアドレスです
0x bf..87 (攻撃者のアドレス 3) このアドレスは次のものを盗むために使用されます。
ここでの _uniswap V3 ファクトリーは 0x0000000000000000000000004300000000000000000000000000000000000004 です。
ウェスの住所です
そして、0x 6 e..c 5 (攻撃者のアドレス 1) は、ネイティブ資産 ETH であるアドレス (0) を盗む役割を果たします。
フィールド 0 を設定すると、攻撃者は次のロジックを通じて対応する資産を盗むことができます。
質問
なぜ攻撃者はすべての資産を盗まなかったのでしょうか?
理論的には、彼は残りのWETHとUSDBであるすべての資産を盗むことができます。
0x bf..87 (攻撃者のアドレス 3) は 73.49 WETH のみを盗みました。0x bf..87 (攻撃者のアドレス 3) は実際にすべての 7350 WETH を奪うことができます。または、0x c 5..0 d (攻撃者のアドレス 2) を使用することもできます全てを離れて 7758267 USDB。なぜ少量の WETH を摂取しただけで停止したのですか? わかりません。詳細な内部調査を行うには、有名なチェーン探偵が必要になる可能性があります。
https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233
なぜ攻撃者は 17413 ETH をイーサリアム メインネットに転送しなかったのでしょうか?
誰もが知っているように、Blast メイン ネットワークは集中型の方法でこれらの ETH を傍受し、ユーザーに重大な損失を引き起こすことなく永続的にここに留まらせることが可能ですが、これらの ETH がイーサリアム メイン ネットワークに入ると、傍受する方法はありません。それ。
現在の Blast クロスチェーン ブリッジを評価しました。公式のクロスチェーン ブリッジの数に制限はありませんが、脱出までに 14 日を必要とし、Blast 当局が迎撃計画を準備するには十分な日数です。
サードパーティのクロスチェーン ブリッジは、攻撃者の料金源と同様に、ほぼリアルタイムで入金され、クロスチェーンを迅速に完了できます。
実際、攻撃者は最初の瞬間 (攻撃から 2 分以内) にクロスチェーンを実行しました。
https://blastscan.io/tx/0x10cf2f2b884549979a3a1dd912287256229458ef40d56df61738d6ea7d9d198f
さらに、資金がイーサリアムのメインネットワークに到着するまでに 20 秒かかりました 理論的には、クロスチェーンブリッジが手動で介入する前に、攻撃者はクロスチェーンを継続し、チェーン間で大量の ETH を転送することができます。
一度に 3 ETH しか使用できない理由については、Blast から ETH までのクロスチェーン ブリッジの流動性制限が理由です。
Blast をサポートする別のクロスチェーン ブリッジは、さらに少ないサポートをサポートします。
このクロスチェーン取引後、攻撃者は他のクロスチェーン操作を継続しませんでしたが、理由は不明ですが、「某国のハッカー」がブラストから資金を引き出すための十分な準備をしていなかったものと思われます。
攻撃後に何が起こったのか
コミュニティ ユーザー Nearisbuilding からのフィードバックに基づいて、彼は攻撃者の身元情報をさらに見つけ、攻撃者に資金の返還を促す方法を見つけました。
https://twitter.com/Nearisbuilding/status/1772812190673756548
最終的に、暗号化コミュニティの注目と尽力により、「某国のハッカー」は身元暴露を恐れたのか、上記 3 つの攻撃者アドレスの秘密鍵をプロジェクト当事者に提供し、すべて返却しました。プロジェクト当事者はまた、救済取引を実施し、破損した契約書からすべての資金を保管のために複数署名契約書に移管しました。
