仮想通貨とハッキング — ブラックハットの悪夢
ブラックハットによる仮想通貨インシデント — ブリッジ、鍵、ソーシャルエンジニアリング、ガバナンスエクスプロイト — そして、真摯に取り組むチームが採用する、時間とコストのかかる防御策。
他の言語: EnglishРусскийEspañol中文ไทยFrançaisУкраїнськаTürkçeहिंदीفارسیالعربيةHausaPortuguêsTiếng Việt한국어Bahasa IndonesiaDeutschTagalog

目次
暗号資産は、暗号技術、分散型コンセンサス、そして不変の台帳によって築かれた城として描かれることが多い。しかし、このデジタルの約束の地の現実は、はるかに複雑で、より危険なものである。主流メディアが暗号資産分野のハッキングについて語る際、その多くはソーシャルエンジニアリングやフィッシングキャンペーン、あるいは単に悪意のあるサイトで疑うことを知らないユーザーに取引所のアドレスや秘密鍵を入力させる詐欺に関するものである。
しかし、本記事ではこうした人間由来の失敗については一切触れない。本記事で扱うのは「純粋なハッキング」である。それは、崩壊したサイバーセキュリティと、深刻な欠陥を抱えたコードが悲惨な侵害を引き起こす世界だ。これこそがブラックハットの夢であり、コードが作成者に対して武器となり、一発の銃弾も放つことなく、わずか数分で数億ドルを流出させる。そして、論理的な脆弱性、コンパイラのバグ、設計上の見落としといった極限の状態へと我々を追い込むのである。
スマートコントラクトの脆弱性が生まれる場所
純粋なスマートコントラクトハッキングを語るには、まず一つの説明が必要だ。それは、イーサリアムの進むべき道を永遠に変えてしまった、当時のDeFi史上最も悪名高い事例の一つである。プログラマブルなブロックチェーンの黎明期、The DAOと呼ばれるプロジェクトが存在した。そのファンドは、人間を介さず、すべてスマートコントラクトによって管理される一種の分散型ベンチャーキャピタルファンドを目指していた。
このコントラクトには、提案への投票や報酬の獲得を期待する投資家から、数百万ドル相当のイーサ(Ether)が集まっていた。しかし、開発者は出金プロセスを安全な方法で実装しておらず、それは「リエントランシー(再入可能性)」と呼ばれるバグであった。
リエントランシー — スマートコントラクトが外部コントラクトを呼び出す際に、自身の内部状態を更新しないこと。例えば、The DAOにおける出金関数は、まず要求された資金をユーザーに送金し、その後に初めて、出金額に基づいてユーザーの状態を更新する仕組みになっていた。
ブラックハットハッカーは、フォールバック関数を持つ悪意のあるスマートコントラクトをデプロイすることも可能であることに気づきました。The DAOがこの悪質なコントラクトに資金を送金するたびに、フォールバック関数が呼び出されました。フォールバック関数は単に資金を受け取るだけでなく、即座にThe DAOの出金関数を再び呼び出しました。最初の出金時点ではハッカーの残高がまだ更新されていなかったため、これによりフォールバック関数が再度トリガーされ、The DAOはそれを実行しました。
ネットワークが対応できるようになる前に、このプロセスが何度も繰り返され、The DAOから数百万ドルが引き出されました。
余波とハードフォーク
このハッキングによる余波は、これまでに類を見ないものでした。ネットワークは崩壊の危機に瀕しており、存在する全Etherの大部分が盗まれました。これはコミュニティにとって存亡に関わる技術的な危機をもたらし、最終的にコミュニティはブロックチェーンの履歴を巻き戻して資金を返還するために、ハードフォークを実施しました。
この物議を醸した決定は永久的な分裂を引き起こし、EthereumとEthereum Classicが誕生することとなりました。この特定の脆弱性は今日ではよく知られており、主に「Checks-Effects-Interactions」パターンの使用によって対策されています。 このパターンは、コントラクトがまずすべての条件を検証し、その後にのみ内部状態を更新し、外部コントラクトの呼び出しは最後の段階でのみ行わなければならないというものです。
しかし、基本的なリエントランシーは現在、自動監査ツールで非常に容易に検出できるようになりましたが、非常に特殊でニッチな状況下では、巧妙なクロスコントラクト・リエントランシー攻撃が依然として発生する可能性があり、確立された概念であっても新たな攻撃へと変貌を遂げる可能性があることを示しています。
未初期化ロジックとDelegate Callの時代
The DAOから得られた教訓は開発者コミュニティに素早く吸収され、それ以来、ガス代の節約やアップグレードの容易化のために、ライブラリコントラクトやプロキシパターンといった概念に結びついた、より複雑なシステムが開発されるようになりました。この複雑さの中に、純粋なハッキングの新たなベクトルが生まれました。その最も悪名高い例が、Parityマルチシグウォレットの脆弱性です。
Parityは広く利用されているイーサリアムクライアントであり、コアロジックを中央のライブラリコントラクトに置くマルチシグウォレット用のスマートコントラクトを提供していました。これは、同じコードを何度もデプロイする代わりに、多くのウォレットが同じライブラリを参照できるようにすることで、リソース効率を高めることを目的としていました。

この脆弱性の種類は、delegatecall関数と未初期化のステート変数に対する誤解に起因するものでした。delegatecall関数は、あるコントラクトが別のコントラクトの関数を実行することを可能にしますが、その関数に呼び出し元コントラクトのストレージへのアクセス権を与えます。Parityのライブラリコントラクト内には、ウォレットの所有者を初期化するための関数が含まれていました。
しかし、ライブラリコントラクト自体は、実際には一度も初期化されていませんでした。
あるハッカーは、ライブラリコントラクトの初期化関数を直接呼び出し、そのライブラリのオーナーであると主張できることに気づきました。ライブラリの所有権を取得した後、彼らはそれを自己破壊(self-destruct)させる関数を呼び出しました。マルチシグウォレットの凍結
そのライブラリに依存していたマルチシグウォレットは、ライブラリが破壊されると即座に機能不全に陥りました。トランザクションの処理、資金の引き出し、あるいは単なる残高照会に必要なすべてのロジックが失われてしまったのです。この過程で、純粋な設計上のミスにより、数億ドル相当のイーサ(Ether)が盗まれたのではなく、物理的に凍結されることとなりました。
この事件は、未初期化のロジックコントラクトが孕む極端な危険性と、delegatecall関数に関連する微妙なリスクを浮き彫りにしました。これらは今日では常識のように思われますが、当時は十分に理解されていませんでした。これを修正するために、現在の開発者は、コントラクトが一度しか初期化できないように強制する特別な初期化モディファイアを使用しています。また、誰も権限を主張できないように、デプロイ済みのロジックコントラクトの状態にダミー値を設定することも一般的です。
今日、全く同じ状況が起こる可能性は低いものの、プロキシパターンの管理ミスという一般的なリスクは、適切な分散型金融(DeFi)アーキテクチャを構築する上で、依然として慎重に検討されるべき事項です。
クロスチェーンブリッジの暗号技術的な蜃気楼
クリプトエコシステムが複数のブロックチェーンへと拡大するにつれ、相互運用性への需要が高まり、それがさまざまな種類のクロスチェーンブリッジとして具現化しました。これらのプロトコルにより、あるチェーン上で資産をロックし、別のチェーン上でその代替資産をミント(鋳造)することが可能になります。
膨大な資産を保有しているため、それらはブラックハットハッカーにとって格好の標的(ハニーポット)となっていました。
Wormholeブリッジの脆弱性攻撃は、実装におけるわずかな細部の見落としが、いかに複雑な暗号学的検証をいとも簡単に失敗させてしまうかを思い知らされる、実に恐ろしい事例です。Wormholeは、SolanaとEthereum間での資産転送を可能にしていました。これは、「ガーディアン」と呼ばれるグループが一方のチェーン上のイベントを監視し、それを証明するためにメッセージに署名するという仕組みでした。これらの署名は、トークンが新しいトークンとしてミント(鋳造)される前に、ターゲットとなるチェーンによって検証されます。
脆弱性は、Solanaのスマートコントラクトにおける署名検証にありました。暗号学的検証は、コントラクトから呼び出されるSolanaの組み込みプログラムによって行われていました。しかし、Wormholeの開発者は、呼び出されているプログラムが実際のシステムプログラムであるかどうかの確認を怠っていました。ハッカーはまた、入力内容に関わらず常に成功メッセージを返すプログラムを作成しました。

次に、Wormholeのコントラクトはこの偽のアプリを検証に使用するよう指示されました。署名が正当であるという誤った前提のもと、コントラクトは処理を進め、反対側のチェーンにEthereumが全くロックされていないにもかかわらず、Solanaネットワーク上で数億ドル相当のラップドEthereumをミントしました。ハッカーはその後、これらの新たにミントされた裏付けのないトークンをEthereumへ戻し、プロトコルから本物の資産を奪い去りました。
これは、Solanaのアカウント検証モデルを突いた、鮮やかで高度にテクニカルな実行でした。この問題は、検証シェルが実際にハードコードされた公式のシステムアドレスであることを確認する、より厳格なバリデーションを導入することで修正されました。
その影響は甚大であり、SolanaのDeFiエコシステムのシステム的な崩壊を防ぐため、プロジェクトの支援者による救済措置が必要となりました。このような脆弱性は、スマートコントラクト開発パラダイムの独自の特性、特にSolanaのようなアカウントモデルを多用する環境において、開発者がスマートコントラクト内で呼び出されるすべての外部エンティティに対して厳格なアカウントおよびプログラムの検証と確認を行わない限り、将来的に再発する可能性があります。
Nomadブリッジのエクスプロイト
Wormholeが特定の方向を狙った組織的な攻撃であったのに対し、Nomadブリッジのエクスプロイトは、たった一つの単純なロジックの欠陥が、いかに簡単にプロトコルを無秩序な乱戦状態のような混乱に陥れるかを証明しました。このクロスチェーンメッセージングを実装するために、Nomadはメッセージの有効性を示すためにマークルツリーに依存するオプティミスティック・ロールアップのモデルを採用していました。開発者は、プロトコルのアップデートをデプロイする際、トラステッドルートの初期化において重大なミスを犯しました。
これは、彼らがトラステッドルートを、Solidityにおける未初期化変数のデフォルト値であるゼロハッシュに設定したために起こりました。その結果、明示的に検証されていないメッセージはすべてゼロハッシュにフォールバックされ、それがコントラクトによって有効なトラステッドルートとして認識されるようになってしまったのです。本質的に、あるハッカーは資金の引き出しを要求するトランザクションを作成できることに気づきました。その証明のハッシュ値がゼロハッシュになるため、コントラクトは常にそれを承認してしまう状態でした。
このハッキングは、その単純さと、その後に生じた狂乱的な混乱において特異なものでした。最初のハッカーがエクスプロイトを実行した後、他のユーザーもこれに便乗しました。技術的なハッキング能力は一切不要で、単にハッカーのトランザクション情報をコピー&ペーストし、送信先アドレスを自分のものに書き換えてネットワークに送信するだけでした。」
わずか数時間の間に、数百人もの異なる攻撃者がNomadブリッジから2億ドル近くを流出させました。
それは教科書的なサイバーセキュリティの不備でした。わずか1行の初期化コードの設定ミスが、暗号化セキュリティシステム全体を無効化してしまったのです。この問題は、ゼロルート初期化ロジックにパッチを当て、それを有効なルートとして明示的に拒否することで対処されました。ブリッジの利用者はその代償を払うこととなり、スマートコントラクトの開発において、文字の欠落一つやデフォルト値の誤りが、プロトコル全体を事実上危険にさらす可能性があるという厳しい教訓を残しました。
この特定のバグは入念なテストを行えば容易に回避できるものでしたが、初期化エラーという大きなカテゴリーのミスは、依然としてシステムを悩ませ続けています。
コンパイラのバグと市場操作
最も恐ろしいタイプの純粋なハッキングの一つは、開発者が書いたコードではなく、そのコードをコンパイルするために使用されたツール自体に欠陥がある場合です。DeFiの基盤に激震を走らせたCurve Financeのエクスプロイト事件の際、私たちはこの事実を思い知らされました。ステーブルコインの主要なDEXであるCurveのコアコントラクトの多くは、セキュリティとシンプルさを重視するPython風のスマートコントラクト言語であるVyperで記述されていました。

幸いなことに、Curveの開発者はスマートコントラクトにリエントランシー・ガードを実装しており、かつてThe DAOに壊滅的な被害を与えたのとまさに同種の攻撃から防御していました。しかし、Vyperコンパイラの特定の古いバージョンの中に、そのバグは潜んでいたのです。
コンパイラは、人間が読める形式のVyperコードを、イーサリアム仮想マシン(EVM)上で実行されるマシンが読み取り可能なバイトコードへと正常に変換しましたが、複数の関数にわたるリエントランシー・ロックの適用が不十分でした。コード自体は安全であり、開発者は意図した通りに記述していましたが、コンパイラがそれを裏切る形で、脆弱性を含むバイトコードを生成してしまいました。これにより、あるブラックハットハッカーが、Curveの一部の流動性プールがクロスファンクション・リエントランシーに対して脆弱であることに気づきました。彼らはこの隙を突き、プールから数千万ドルを奪い去りました。
このハッキングが特に巧妙だったのは、従来のソースコード監査では決して発見できなかった点にあります。ソースコード自体は正しかったのです。脆弱性は、コンパイルされたバイトコードの中にのみ存在していました。この出来事は、業界全体がコンパイラやインフラに対する信頼を再考するきっかけとなりました。この問題は、Vyperコンパイラのアップデートと、脆弱なプールから安全にコンパイルされた新しいコントラクトへの移行によって対処されました。
その結果、深刻な信頼の危機がもたらされ、セキュリティは技術スタックの最下層まで網羅されなければならないという認識が広まりました。コンパイラのバグは稀ですが、予見することはほぼ不可能です。そのため、このようなインフラレベルの悪夢は、容易に再発する可能性があります。
分散型金融(DeFi)の発展とともに登場した新しい金融手法である「フラッシュローン」は、ハッキングの本質を根本から変えました。フラッシュローンを利用すれば、同一のトランザクション内で返済が完了する限り、ユーザーは無担保でほぼ無制限の暗号資産を借り入れることができます。 資金が決済されない場合、トランザクション全体が取り消されます。まるで最初から行われなかったかのようになります。
通常、アービトラージや清算を目的とするフラッシュローンは、ブラックハットハッカーに対し、市場メカニズムにおける深刻な論理的欠陥を突くために必要な流動性を提供することとなりました。Euler Financeのハッキング事件をケーススタディとして挙げると、Eulerは預け入れと収益化のためのレンディングプロトコルでした。ユーザーは預け入れた資産をプロトコルのリザーブに寄付することもでき、プロトコル内では「donateToReserves」という関数がその役割を担っていました。
しかし、開発者はその特定の関数において、非常に重要なヘルスチェックを見落としていました。寄付によって資金が差し引かれた後のアカウントが、依然として健全な状態を維持しているかどうかの確認も行われませんでした。攻撃者はフラッシュローンで多額の資産を借り入れ、それをEulerに預け入れました。次に、彼らはdonateToReserves関数を呼び出し、預け入れ資産の一部を寄付しました。
ヘルスチェックがなかったため、プロトコルはこの寄付を承認し、ハッカーのアカウントを極めて人為的な破産状態へと陥れました。その後、ハッカーは自身のアカウントの清算を実行しました。しかし、Eulerの清算ボーナスの計算式は複雑であり、さらにフラッシュローンが非常に巨額であったため、清算人は結果として、預け入れた額よりも多くの価値をプロトコルから奪い取ることになりました。
彼らはフラッシュローンを返済し、約2億ドルを手にして逃走しました。これは暗号学的な欠陥やコンパイラのバグではなく、コードにおける単純な金融ロジックの失敗でした。このケースでは、開発者は特定の操作後のアカウントの健全性を確認する、たった1行のコードを挿入し忘れただけだったのです。修正パッチは、適切なヘルスチェックの実装と、プロトコルのリスク管理ロジックの全面的な見直しで構成されました。
これは深刻な影響を及ぼし、プロトコルの中断を招いたほか、資金の一部を回収するために数ヶ月に及ぶ交渉を要することとなりました。
複雑な金融メカニズムが互いに意図しない形で反応するようなロジカル・エクスプロイト(論理的脆弱性の悪用)は、今日の純粋なハッキングにおいて最も一般的かつ危険な形態となっています。プロトコルの複雑性は増し続けており、この種の論理的な見落としは、今後もほぼ確実に繰り返されるでしょう。コードと結果の間に続く絶え間ない闘い
これら大規模な流出事件の歴史を振り返れば、容易にあるパターンが見えてきます。これらの脆弱性が、基盤となるブロックチェーンのコンセンサス・メカニズムの不備に起因することは稀です。そうではなく、それらは変更不可能なコードに書き込まれた、人間の論理的な設計ミスなのです。ステート更新の失敗、プロキシの未記述のコードパス、暗号学的チェックの漏れ、コンパイラエラー、あるいは金融的な不変条件チェックの欠如など、その要因が何であれ、根本的な問題は常にスマートコントラクト自体の設計ミスにあります。
これらのリスクを排除するために、業界には徹底した防御体制が存在します。それには以下が含まれます。
1. 独立したセキュリティ企業による第三者の人間によるコード監査。2. コードが計画通りに正確に実行されることを数学的に証明する形式検証ツール。3. 悪意のある攻撃者よりも先に欠陥を発見したホワイトハッカーに報酬を支払う、高額なバグバウンティ(バグ報奨金)。4. 悪意のあるアップデートの適用を遅らせるための、タイムロックやマルチシグによる管理者鍵の管理。5. 侵害が発生した場合に補償を提供する分散型保険プロトコルの利用。
しかし、これらの防御策が高度化したとしても、ブラックハット・ハッキングは依然として存在し続けています。ソフトウェア開発における大原則は、「複雑さは失敗の温床となる」ということなのです。
分散型金融(DeFi)の複雑化が進み、開発者が数十ものスマートコントラクトを統合し、複数のブロックチェーンにまたがって機能する複雑なプロトコルを構築するようになったことで、これまでにない新たな攻撃手法が生まれています。
攻撃者の手法は自らの想像力にのみ制限されるため、成功するためには有効な攻撃ベクトルを1つ見つけるだけで済みますが、防御側は常に後手に回り、対応に追われることになります。これは、分散型の未来を築く者と、それを悪用する者が火花を散らす、終わりのない永続的な闘争となるでしょう。全面的なハッキングという悪夢は形を変え続け、常に私たちに思い知らせます。「コードは法なり(Code is Law)」の世界では、たった一つのタイポ(打ち間違い)がすべてを奪い去る可能性があるということを。
コードの1行1行が文字通り数十万ドルの価値を持つ中、最高レベルのパフォーマンスを確保するためには、セキュリティと同様に、日々の運用における効率性と正確性が重要となります。ユーザーはデジタル資産、特にステーブルコインを管理する際、ネットワークコストという摩擦に常に悩まされています。現在、資金移動のために頻繁にUSDTを送金する場合、そのUSDTのトランザクションコストの変動が、いかに資産を削り、悪影響を及ぼすかを実感しているはずです。

エコシステムの積極的な参加者として、USDTの安価な送金方法を見つけることは極めて重要です。ここで、特定のツールが優位性をもたらします。nettsサービス:USDT送金計算機(USDT Transfer Calculator)は、まさにこうした運用の効率化を促進するために開発されました。
TRONネットワーク上でTetherを送金する際、エネルギーと帯域幅(Bandwidth)が消費されます。これらを保有していない場合、ネットワークはUSDTの手数料に基づいてTRXをバーン(焼却)します。
必要なエネルギーと帯域幅を事前に正確に算出するNettsエスティメーターを利用することで、ユーザーはTRXをバーンする代わりにエネルギーをレンタルし、大幅にコストを削減できます。トークンの最小単位までが重要となる世界において、資産を可能な限り効率的に管理し、守ることが可能になります。