クリプトのセキュリティ概説
ハッカーは今年、dAppsから20億ドル以上を盗みました。クリプトのエコシステムが成長し、より多くの悪意のある人々を引き寄せるにつれ、問題は悪化の一途をたどるでしょう。何かを変えなければなりません。一歩下がって過去の失敗を振り返り、この業界におけるセキュリティの扱い方を変えるときが来たのです。
この記事では、以下について解説します。
- ハッキングを分類するためのフレームワークの提示
- 収益性の高いハッキングに使用された手法の説明
- ハッキング防止のために使用されているツールの長所と短所を検証
- クリプトにおけるセキュリティの将来像
ハッキングの種類
dAppsのエコシステムは、ホストチェーンとインターネットの基礎インフラに依存するスマートコントラクトを搭載した相互運用可能なプロトコルで構成されています。
各レイヤーには、それぞれ固有の脆弱性があります。ハッキングは、悪用されたレイヤーと、その方法に基づいて以下のように分類することができます。
インフラ
インフラレイヤーへの攻撃は、dAppsをサポートする基本システムの弱点を突くもので、コンセンサスアルゴリズムを用いるブロックチェーン、フロントエンドに使用するインターネットサービス、秘密鍵管理に使用するツールなどがこれにあたります。
スマートコントラクト言語
このレイヤーのハックは、Solidityのようなスマートコントラクト言語（プログラミング言語）の弱点を突きます。スマートコントラクト言語には、リエントランシー(reentrancy)※や不正なDelegateCall実装の危険性など、一般的に知られている脆弱性がありますが、ベストプラクティスに従うことで脆弱性を緩和することができます。
※脚注：悪名高い$60M DAOハッキングに使用された脆弱性であるリエントランシーは、実はLeast AuthorityによるEthereumのセキュリティ監査で確認されていました。もし、この脆弱性がローンチ前に修正されていたら、どれほど事態が変わっていたかと考えると、おかしな話です。
プロトコルロジック
このカテゴリの攻撃は、単一のアプリのビジネスロジックのミスを悪用します。ハッカーがこの誤りを発見すると、それを利用して、アプリの開発者が意図しない動作を引き起こすことができます。
例えば、新しい分散型取引所(DEX)で、ユーザーがスワップして受け取る金額を決定する計算式に誤りがあった場合、その誤りを悪用して、本来可能なはずの金額よりも多くの金額をスワップして受け取ることができるのです。
また、アプリのパラメータを制御するために設置されたガバナンスシステムを利用して、プロトコルロジックレベルで攻撃することも可能です。
エコシステム
最も影響力のあるハッキングの多くは、複数のアプリ間の相互作用を利用したものです。最も一般的なのは、ハッカーがあるプロトコルのロジックミスを悪用し、他のプロトコルから借りた資金で攻撃の規模を拡大させるケースです。
通常、エコシステム攻撃で使用される資金は、フラッシュローンを使用して借用されます。フラッシュローンを行う場合、資金が同じトランザクション内で返却される限り、担保を設定せずにAaveやdYdXなどのプロトコルの流動性プールから好きなだけ資金を借りることができます。
データ分析
2020年以降の最大のハッキング100件のデータを収集すると、盗まれた資金の総額は50億ドルに上ります。
エコシステム攻撃は最も頻繁に発生しました。サンプル群の41%を占めています。
プロトコルロジックの悪用は、最も資金流出を生み出したという結果になりました。
データセットに含まれる3大攻撃、Roninブリッジ攻撃（$624M）、Poly Networkハッキング（$611M）、Binanceブリッジハッキング（$570M）は、結果に多大な影響を及ぼしています。
上位3つの攻撃を除くと、インフラへのハッキングが、失われた資金で最も影響の大きいカテゴリーとなります。
ハッキングはどのように実行されるのか？
インフラへの攻撃
データセットのインフラ攻撃の61%で、秘密鍵が未知の手段で漏洩しています。ハッカーは、フィッシングメールや偽の求人広告などのソーシャル攻撃を利用して、これらの秘密鍵にアクセスした可能性があります。
スマートコントラクト言語への攻撃
スマートコントラクト言語レベルでは、リエントランシー攻撃が最も頻繁に生じていました。
リエントランシー攻撃では、脆弱なスマートコントラクト内の関数が、悪意のあるコントラクト上の関数を呼び出します。あるいは、脆弱なコントラクトが悪意のあるコントラクトにトークンを送信すると、悪意のあるコントラクトの関数がトリガーされることもあります。その後、その悪意のある関数は、コントラクトが残高を更新する前に、再帰的ループで脆弱な関数にコールバックします。
例えば、Siren Protocolのハッキングでは、担保となるトークンを引き出すための関数がリエントランシーに弱く、担保がすべてなくなるまで（悪意のあるコントラクトがトークンを受け取るたびに）繰り返し呼び出されていました。
プロトコルロジック攻撃
プロトコルレイヤーに対する攻撃のほとんどは、（純粋なフォークでない限り）すべてのアプリが固有のロジックを持ってい るため、その特定のアプリに固有の問題です※。
アクセス制御のミスは、データセット内で最もよくある問題でした。例えば、Poly Networkのハッキングでは、「EthCrossChainManager」コントラクトは誰でもクロスチェーン取引を実行するために呼び出すことができる関数を持っていました。
このコントラクトは「EthCrossChainData」コントラクトを所有しているため、「EthCrossChainData」をクロスチェーン取引のターゲットとして設定すれば、onlyOwner()のチェックを回避することができたのです。
あとは、どの公開鍵がプロトコルの「キーパー」として定義されているかを変更するために適切なメッセージを作成し、コントロールを奪い、資金を流出させるだけだったのです。一般ユーザーは、「EthCrossChainData」コントラクトの機能にアクセスすることができないはずでした。
※脚注：脆弱性のあるコードベースをフォークしたために、同じ手法で複数のプロトコルがハッキングされたケースは数多く存在します。
例えば、CREAM、Hundred Finance、Voltage Financeなどの多くのCompoundのフォークは、事前にCompoundのコードの相互作用の効果をチェックしなかったため、リエントランシー攻撃の犠牲になっています。これは、Compoundがサポートする新しいトークンの一つ一つについてその脆弱性を吟味していたからうまくいったのであって、フォークを作ったチームはそのような調査をしなかったのです。
エコシステム攻撃
エコシステム攻撃の98%でフラッシュローンが使用されています。
フラッシュローン攻撃は通常、次のような方式で行われます。ローンを利用して大規模なスワップを行い、レンディングプロトコルが価格フィードとして参照しているAMM上のトークンの価格を上昇させます。次に、その同じ取引で、その膨張したトークンを担保に、真の価値をはるかに上回るローンを受け取るのです。
ハッキングはいつ実行されるのか？
このデータセットは、時間分布から意味のある傾向を導き出すには十分な大きさではありません。しかし、異なる種類の攻撃が異なる時間に頻繁に発生することがわかります。
2021年5月は、エコシステム攻撃が過去最高となりました。2021年7月は、プロトコルロジック攻撃が最も多く、2021年12月はインフラへの攻撃が最も多い月でした。これらの分布が偶然なのか、それとも1回ハッキングに成功したことにより、同一犯や他のハッカーを特定のカテゴリに引き寄せた事例なのか、判断するのは難しいです。
スマートコントラクト言語レベルの悪用は、最もまれなケースでした。このデータセットは2020年に開始されており、すでにこのカテゴリの大半のエクスプロイト手法がよく知られており、早期に発見される可能性が高いです。
盗まれた資金の時間的分布は、主に4つのピークがあります。2021年8月にPoly Networkのハッキングに起因するピークがあります。2021年12月にも、例えば8ight Finance、Ascendex、Vulcan Forgedなど、秘密鍵が漏洩したインフラの大規模なハッキング群による大きなピークがあります。そして、2022年3月にRoninのハッキングにより、史上最高値を記録します。最後のピークは、Binanceのブリッジ攻撃によるものです。
ハッキングはどこで実行されるのか？
私は、資金が盗まれたコントラクトやウォレットをホストしているチェーンに基づいてデータセットを分類しました。イーサリアムはサンプル群の45%で、ハッキングの量が最も多かったです。Binance Smart Chain（BSC）は20％で2位でした。
これにはいくつかの要因があります。
- イーサリアムとBSCはTVL（Total Value Locked: アプリに預けられた資金）が最も高いため、ハッカーにとって盗める資金の規模がより大きい状況です
- クリプト開発者の多くは、イーサリアムとBSCで利用されているスマートコントラクト言語のSolidityを知っており、この言語をサポートする、より洗練されたツールが存在します
イーサリアムは盗まれた資金量が最も多く（$2B）、2位はBSCでした（$878M）。1回の事案でイーサリアム、BSC、ポリゴンで資金が盗まれたハッキングは3位（$689M）でした。これは主にPoly Network攻撃によるものです。
ブリッジやマルチチェーンアプリ（例：マルチチェーンスワップやマルチチェーンレンディング）を含むハッキングは、データセットに大きな影響を与えました。ハッキング件数の10%しか占めていないにもかかわらず、これらのハッキングにより25億2000万ドルの資金が盗まれました。
ハッキングを防ぐにはどうすればよいのか
各レイヤーには、潜在的な攻撃パターンを早期に特定し、エクスプロイトの発生を防止するために使用できるツールがあります。
インフラ
インフラへの大規模なハッキングのほとんどは、ハッカーが秘密鍵などの機密情報を入手することに関係しています。優れた運用セキュリティ（OPSEC）を実践し、脅威のモデリングテストを繰り返し行うことで、このような事態が発生する可能性を低減することができます。優れたOPSECのプロセスを持つ開発チームは、次のことを行います。
- 機密データ（秘密鍵、従業員情報、APIキーなど）の特定
- 想定される脅威の特定（ソーシャル攻撃、技術的なエクスプロイト、内部脅威など）
- 既存のセキュリティの抜け穴や弱点の特定
- 各脆弱性の脅威レベルの決定
- 脅威を軽減するための計画の策定と実行
スマートコントラクト言語とプロトコルロジック
ファジング
Echidnaのようなファジングツールは、ランダムに生成されたトランザクションの広いセットにスマートコントラクトがどのように反応するかをテストします。これは、特定の入力が予期しない結果を生み出すエッジケースを検出するのに有効な方法です。
静的解析
SlitherやMythrilなどの静的解析ツールは、スマートコントラクトの脆弱性を自動的に検出します。これらのツールは、一般的な脆弱性を素早く発見するには最適ですが、事前に定義された特定の問題しか捉えることができません。ツールの仕様にない問題がスマートコントラクトに存在する場合、それは検出できません。
形式的な検証
Certoraのような形式的検証ツールは、スマートコントラクトを開発者が書いた仕様と比較します。この仕様には、コードが何をすることになっているかや、その望ましい性質が詳細に記述されています。例えば、レンディングアプリを開発する開発者は、すべてのローンは十分な担保に支えられていなければならないと仕様を定めているといった感じです。
スマートコントラクトの動作のいずれかが仕様を満たさない場合、ツールはその違反を特定します。
形式的な検証の弱点は、テストが仕様と同程度のものでしかないことです。提供された仕様が特定の動作を考慮していなかったり、許容的すぎたりすると、検証プロセスはすべてのバグを捕捉することはできません。
監査とピアレビュー
監査やピアレビューでは、信頼できる開発者グループがプロジェクトのコードをテストし、レビューします。監査役は、発見した脆弱性の詳細と、それらの問題を修正するための推奨事項を記載した報告書を作成します。
専門家である第三者にコードをレビューしてもらうことは、チームが見逃していたバグを発見するための素晴らしい方法です。しかし、監査役も人間であり、すべてを把握できるわけではありません。また、監査役が問題を発見した場合、自分たちでそれを利用するのではなく、あなたに教えてくれることを信頼する必要があります。
エコシステム攻撃
残念なことに、エコシステム攻撃は頻繁に起こり、最も破壊的な攻撃であるにもかかわらず、この種の攻撃を防止するのに適したツールはあまりありません。
自動化されたセキュリティツールは、一度に1つのコントラクトのバグを見つけることに重点を置いています。監査は通常、エコシステム内の複数のプロトコル間の相互作用がどのように悪用されうるかについて対処することができません。
FortaやTenderly Alertsのような監視ツールは、コンポーザビリティ攻撃が発生したときに早期に警告を発し、チームが対策を講じられるようにします。しかし、フラッシュローン攻撃では、通常、資金は1回の取引で盗まれるため、アラートが届いた時には、巨額の損失を防ぐには遅すぎる可能性があります。
脅威検知モデルを使えば、ノードが処理する前のトランザクションが置かれているメモリプールで悪意のあるトランザクションを見つけることができますが、ハッカーはフラッシュボットなどのサービスを使ってトランザクションを直接マイナーに送り、こうしたチェックをすり抜けることができます。
セキュリティの将来
クリプトのセキュリティの将来について、2つの予測をしています。
1つ目は、最高のチームは、セキュリティをイベントベースの取り組み（テスト→ピアレビュー→監査）のように扱うのではなく、継続的なプロセスとして扱うように変化すると信じています。そのようなチームは
- メインコードベースへコードを追加する際に、必ず静的解析とファジングを実行する
- メジャーアップグレードごとに形式的な検証を実行する
- レスポンスアクション（アプリ全体または影響を受けた特定のモジュールの一時停止）を伴うモニタリングとアラートシステムをセットアップする
- セキュリティシステムおよび攻撃対応計画の作成と維持にチームメンバーを充てる
セキュリティは、チェックボックスを埋めたら終わりというものではありません。セキュリティの作業は、監査をクリアした後も続けるべきものです。Nomadブリッジ・ハッキングのように、監査後のアップグレードで生じたミスが悪用されたケースは少なくありません。
2つ目は、セキュリティ関係のコミュニティによるハッキング対応プロセスが、より組織的かつ合理的になるというものです。ハッキングが発生するたびに、セキュリティ関係のグループチャットに協力者が殺到しますが、組織化されていないため、重要事項が混乱で失われる可能性があります。私は、このようなグループチャットが、より構造化された組織へと移行する未来を見ています。
- オンチェーンモニタリングとソーシャルメディアモニタリングツールを使用して、攻撃を迅速に検出する
- セキュリティ情報およびイベント管理ツールを使用して、作業を調整する
- ホワイトハック、データ分析、根本原因の理論化などの作業について、異なるチャネルで連絡を取り合いながら、一連の作業を分担する
謝辞：このレポートは、CIA Officer、Kris Oosthoek、Rekt、Emiliano Bonassi のおかげで実現できました。
