背景

Blastは、Blurの創設者であるPacman（Tieshun Roquerre。EthereumのLayer2ネットワークで、2月29日にメインネットワークを立ち上げ、現在Blastのメインネットワークで約19,500 ETHと640,000 stETHが誓約されている。

攻撃されたプロジェクトMunchablesは、ブラストが主催したBigbangコンペティションで優勝したプレミアムプロジェクトでした。

ブラストは公式に、ブラストのメインネットでETHを誓約したユーザーに定期的にポイントを付与しています:

ブラストエコシステム上のDeFiプロジェクトにユーザーが参加することを奨励するため、ブラストの公式は高品質なプロジェクトを選んで推薦し、ユーザーにETHを2回DeFiに誓約するよう促します。その結果、多くのユーザーがブラストのメインネットワークにあるETHを新しく作られたDeFiプロジェクトに誓約した。

そして、これらのDeFiプロジェクトがどれだけ成熟し、安全であるか、そしてこれらの契約が数千万ドル、あるいは数億ドルのユーザーの資金を保持するのに十分安全であるかどうかは、まだわからない。

インシデントの概要

インシデントの概要は以下の通りです。strong>

ブラストのメインウェブサイトは1カ月も前に公開され、SSSトークン（Super Sushi Samurai）に対する攻撃は2024年3月21日に行われました。1310 ETH (~460万ドル)以上の損失をプロジェクトに与えました。

そしてSSSトークンの攻撃から1週間も経たないうちに、さらに大規模な攻撃がブラストで発生し、Munchablesプロジェクトが17,413.96ETH、総額約6,250万ドルを一手に攻撃者に一掃されました。strong>となった。

この攻撃取引の30分後、プロジェクトの契約書にある73.49WETHもハッカーによって別のアドレスに盗まれました。

この時点で、契約アドレスのプロジェクト側は、まだ7276 WETH、7758267 USDB、4 ETHがあり、いつでもハッカーの手に落ちるでしょう、そしてハッカーは、プロジェクト全体のすべての資金を奪う権限を持っている、約9700万ドルの合計が危険にさらされている！。

この事件の直後、X（ツイッター）の有名なチェーン・スルースzachXBT氏は、この攻撃の根本的な原因は、特定の国からハッカーを雇ったことにあると指摘した。

それでは、「ある国から来たハッカー」がどのようにして1億ドル近い攻撃を成功させたのか、詳しく見ていきましょう。

現場を再現する

.strong>

• 被害者の発声

[UTC+0]2024年3月26日21時37分（襲撃から5分後）、Munchablesの関係者はX（ツイッター）に襲撃されたというメッセージを投稿した。



チェーン探偵ZachXBTの調査によると。開発者の一人が「某国のハッカー」だからだそうで、aavegotchiの創設者coderdannn氏もX（ツイッター）で「Aavegotchiの開発チームPixelcraft Studiosは2022年当時、MMSと短期雇用契約を結んでいた。Pixelcraft Studiosは2022年当時、ゲーム開発のためにMunchables Attackerを短期間雇いましたが、彼は非常に大雑把で、某国のハッカーのような感じでした。彼はまた、同様にハッカーであろう彼の友人を私たちに雇わせようとしました。"

この攻撃によってコミュニティが多大な損害を被ったため、私たちはすぐにオンチェーン調査を開始しました。そこで、この "ある国から来たハッカー "による攻撃の詳細を詳しく見ていきましょう。

• 最初のシーン

[.UTC+0]2024年3月26日21時32分、17413.96ETHを含む攻撃が行われました。

Blastscanを使用すると、この攻撃トランザクションを確認できます: https://blastscan.io/tx/0x9a7e4d16ed15b0367b8ad677eaf1db6a2a54663610696d69e1b4aa1a08f55c95



侵害されたコントラクト（0x29..1F）は、ユーザーの誓約資金を保持するプロキシコントラクトであり、攻撃者が誓約コントラクトのロック解除関数を呼び出し、すべての特権チェックをパスして、コントラクトのすべてのETHを攻撃者に転送していることがわかります。すべてのETHを攻撃者のアドレス1 (0x6E..c5) に転送していることがわかります。



攻撃者はロック解除関数の同様の動作を呼び出したようです。

ロック解除関数の引出し動作を呼び出したようで、侵害されたコントラクトのETHのほとんどを奪っています（0x29..1F）。

ロックを忘れたのは、保管庫のプロジェクト側でしょうか？

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

まず、パーミッションをチェックする過程で、コントラクト (0x16..A0) の isRegistered メソッドが呼び出され、ハッカー・アドレス 1 (0x6E..c5) である現在の msg.sender が登録されているかどうかを確認していることがわかります:





答えは「検証に合格した」だ。



ここには契約があります（0x16.

[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に変え、認証許可のバイパスを完成させていると思われます。

本当ですか？

ウェブ3.0では、推測したり人の話を聞いたりする必要はありません。

2つのコントラクト（オープンソースのコントラクトではない）を比較すると、オリジナルの0x9e..CDコントラクトと更新された0xe7..f1には明らかな違いがあります。



0x9e.">0x9e...CDの初期化関数は、以下のように部分的に実装されています:



0x9e.align: "left;">攻撃者が最初の論理契約(0x9e..CD)で攻撃者アドレス(0x6e..c5)をREGISTERに設定し、他の2つの攻撃者アドレス、0xc5..0dと0xbf..87もREGISTEREDに設定され、それらのfield0が初期化に設定されていることがわかります。フィールド0は後で説明する。

実際、私たちが疑っていたことに反して、本当の裏口ロジックの契約は最初に存在したものであり、後から更新されたものは正常なものです！

ちょっと待ってください、このアップデートは2024年3月24日08:39 [UTC+0] (攻撃の2日前)に表示されています。

これはdelegatecallのためで、実際の状態ストアの更新はコントラクト(0x16..A0)にあり、論理コントラクトがバックドアのない論理コントラクト0xe7..f1に更新されても、コントラクト(0x16..A0)の変更されたssは変更されたという事実につながります。strong>変更されたスロットはまだ復元されません。

検証してみましょう:



対応するスロットの契約（0x16.....A0）に値があることがわかります。

これにより、攻撃者はisRegisteredメソッドのチェックサムを渡すことができます:



その後、攻撃者はバックドアのコントラクトを通常のコントラクトに置き換え、バックドアがすでに仕込まれていることを偽装します。

さらに、ロックを解除する過程で、2つ目のチェックがあります：

ロック時間のチェックで、ロックされた資産が期限切れになる前に譲渡されないようにします。期限切れ前に譲渡されないようにします。



攻撃者は、ロック解除が呼び出されたときに、ブロック時間が必要な値よりも大きいことを確認する必要があります。ロック解除が呼び出されたときのブロック時間が、要求されたロックの有効期限(field3)よりも大きい。

このチェックでは、危険なコントラクト(0x29..1F)と対応する論理コントラクト0xf5..cd.

アンロックが呼び出されたときに、攻撃者のブロック時間が必要なロック有効期限(field3)よりも大きいことを確認します。

攻撃者は、アンロックが呼び出されたときに、ブロック時間が必要なロック有効期限よりも大きいことを確認する必要があります。攻撃の5日前）トランザクション

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



破損したコントラクト（0x29..1F）は当初、0x91..11の論理コントラクトを持っており、わずか4分後には、

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

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

同様に、次のように比較してみましょう。

0xf5..cd用の初期化関数の一部が実装されています:

0x91..11用の初期化関数の一部実装:



ご覧のように、ETHの保持数＆改ざん、ロック解除時間の改ざんという同じ手法が再び使われたことは明らかです。同じ手法で保有ETH数＆;アンロック時間を変更し、通常のコントラクトに置き換えて隠蔽していたのです。 プロジェクトチームとセキュリティ研究者がデバッグを行った際、論理的なコントラクトはすべて正常であり、コントラクトがオープンソースではなかったため、問題の核心を見抜くことがより困難でした。

ここまでのところ、攻撃者が17,413ETHを含むこのトランザクションをどのように行ったかは理解できましたが、この出来事の背後にはこれだけの情報しかないのでしょうか？

上記の分析で、私たちは実際にハッカーがコントラクトの中に3つのアドレスを組み込んでいるのを見ました:

0x6e...c5（攻撃者のアドレス1）

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

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

そして、上記で見つかった攻撃は、次のようになります。トランザクションは0x6e..c5しか見ていませんが、他の2つのアドレスは何をしていたのでしょうか？また、address(0)、_dodoApproveAddress、_uniswapV3Factortyには他にどんな秘密が隠されているのでしょうか？同じ手法で73.49WETHを盗んだ攻撃者アドレス3(0xbf..87)を見てみましょう:

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

そして、0xc5...0d（攻撃者アドレス2）を与えながら、ガスのソースアドレス（0x97.0d(攻撃者アドレス2)と0xbf..87(攻撃者アドレス3)の両方に手数料を与えます。



そして、ガスソースアドレス（0x97....DE）の0.1ETHがowlto.finance（クロスチェーンブリッジ）から資金提供されました。

0xc5...0d（攻撃者アドレス2）は手数料を受け取り、何の攻撃も行いませんでしたが、私たちが引き続き見ているように、実はその肩には隠された意図がありました。

実際、事後の公式な救済取引によると、元の被害を受けた契約のアドレス(0x29..1F)には73.49WET以上あり、攻撃が終わるまで、7276.5WETH & 7758267USDBも残っていました

レスキュー取引:

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



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



ここで、https://img.jinse.cn/7200168_image3.png。https://img.jinse.cn/7200169_image3.png">

usdbのアドレスは



0xbf..87（攻撃者のアドレス3）このアドレスは、ウェスを盗むために使用されました:



ここでの_uniswapV3Factoryは次のとおりです。0x000000000000000000000000000000000000000000000000000000000000000000000000000004



ウェス用アドレス



そして0x6e..c5（攻撃者アドレス1）は、ネイティブアセットETHであるアドレス(0)を盗む役割を担っています。攻撃者は以下のロジックでfield0を設定することで、対応するアセットを盗むことができます:





質問

• なぜ攻撃者はすべての資産を盗まなかったのですか？

理論的には、彼はすべての資産、つまり残りのWETHとUSDBを盗むことができました。73.49WETH、0xbf.87（攻撃者のアドレス3）は、実際には、完全にすべての7758267 USDBを取るために0xc5..0d（攻撃者のアドレス2）の助けを借りて、また、離れてすべての7350 WETHを取ることができ、なぜ停止するWETHのほんの少しは、我々は知らない、内部調査を深めるために探偵のよく知られているチェーンである必要があるかもしれません。

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



• なぜ攻撃者は17413ETHをメインのイーサリアムネットワークに送金しなかったのでしょうか？

ブラストのメインネットがこれらのETHを中央集権化することで傍受し、ユーザーに実質的な負担をかけないように永続的にとどまらせることが可能であることはよく知られていますが、いったんイーサリアムのメインネット上にあれば、傍受する方法はありません。しかし、一旦イーサリアムのメインネット上にあれば、それを傍受する方法はありません。

現在のブラストのクロスチェーンブリッジを評価したところ、公式のクロスチェーンブリッジの数に制限はありませんが、14日間のオプトアウト期間があるので、ブラストの関係者が傍受のための計画を準備するには十分な時間です。

サードパーティのクロスチェーンブリッジはほぼリアルタイムで利用可能であり、攻撃者の料金源と同様に、非常に迅速にクロスチェーンを完成させることができますが、そもそもなぜ攻撃者はそれをしなかったのでしょうか？

実際、攻撃者は最初に（攻撃から2分以内に）クロスチェーンを行いました：

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



また、イーサリアムのメインネットに資金が到着するまでに20秒かかったため、理論的には攻撃者はクロスチェーンを続け、クロスチェーンブリッジが手動で介入する前にチェーンをまたいで大量のETHを送金できた可能性があります。



一度に3ETHしか送金できない理由については、以下の通りです。ブラストからETHに渡るクロスチェーンブリッジの流動性の制限：



ブラストをサポートするもう一つのクロスリンクブリッジは、さらにサポートが少ない:



このクロスチェーン取引の後、攻撃者は理由はわかりませんが、他のクロスチェーン操作を続けませんでしたが、「某国のハッカー」はブラストからの資金引き出しの準備を十分にしなかったようです。

攻撃後の展開

コミュニティユーザーのNearisbuildingによると、彼は攻撃者の身元について詳しく知ることができ、また攻撃者に資金を返すよう促す方法を見つけたそうです。

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



結局、暗号コミュニティの注目と努力のおかげで、「某国のハッカー」は、身元がバレるのを恐れたのか、3人の攻撃者のアドレスの秘密鍵をプロジェクトに提供し、すべての資金を返却し、プロジェクトは救済された。プロジェクトはまた、漏洩した契約からすべての資金をマルチシグネチャ契約に移し、安全に保管するという救済取引も行いました。