2023年の大部分はDeFiプロトコルにとって弱気相場でしたが、エコシステムはプロトコルの脆弱性に起因する深刻なハッキングの被害を受け続けています。特に、Euler Financeのハッキングでは2億ドル近くという甚大な損失が発生しました。その一方で、コンパイラや広く普及した規格間の非互換性に起因する脆弱性など、DeFiのセキュリティインシデントにおける新たな傾向も浮上しています。こうした脅威に対抗するため、コミュニティは監視や脅威インテリジェンスなど、複数の解決策を提案してきました。これらの対策の一部は有効であることが証明されていますが、私たちはこれらの取り組みが場当たり的であると考えています。コミュニティには、DeFiプロトコルを保護するための体系的なアプローチや指針が依然として不足しています。
本ブログでは、まず代表的なケースを用いてDeFiプロトコルのセキュリティに関する新たな傾向を提示し、次に現在の解決策とその限界を明らかにします。最後に、DeFiプロトコルを保護する方法についてのBlockSecの見解を提案します。
0x0. DeFiプロトコルセキュリティの新たな傾向
トレンドI：実績のあるプロトコルが攻撃を受けている
2023年には、Curve、Balancer、KyberSwapなど、十分な実績があり信頼性の高いプロトコルが侵害されました。以下の表は、これらのプロトコルのローンチ時期と攻撃を受けた時期を示したものです。悪用された脆弱性は、プロトコルの初期リリース後のアップデートで導入された可能性があることに注意してください。したがって、表に記載された期間は概算であり、関連する期間の全体像を示すためのものです。
上記以外にも、Aave V2は11月にコミュニティから脆弱性の報告を受けた後、緊急停止措置が取られました。プロトコルは攻撃を受けてはいませんが、実績のあるプロトコルであってもセキュリティ懸念が浮き彫りになりました。
これらのプロトコルはいくつかの監査を受けており、内部的に複数のセキュリティ対策が実装されています。以下の表は、各プロトコルの監査担当企業をリストアップしたものです。監査担当企業は、プロトコル内のスマートコントラクトの一部のみを監査した可能性があることに注意してください。表に記載されている監査担当企業は、必ずしも脆弱性があった特定のスマートコントラクトを監査した企業とは限りません。この表の目的は、各プロトコルがセキュリティに多大なリソースを投資してきたことを示すことにあります。
| プロトコル | 監査担当企業 | リンク |
|---|---|---|
| kyberSwap | ChainSecurity, Sherlock, Hacken | Audits - KyberSwap Docs |
| Curve | TrailOfBits, MixBytes, Quantstamp, ChainSecurity | Audits - Curve Docs |
| Balancer | OpenZeppelin, TrailOfBits, Certora, ABDK | Security | Balancer |
幸いなことに、被害者は各プロトコルによって実施された計画を通じて損失の補償を受けています。例えば、Kyber Networkは、KyberSwapの財務部門を通じて影響を受けたユーザーに補償を行う意向を表明しました。同様に、Curveのコミュニティは、流動性提供者（LP）の金銭的損失を補填する提案に投票で賛成しました。これらの措置は、多大な費用はかかりますが、DeFiコミュニティの信頼を回復するための第一歩です。
トレンドII：新たな攻撃ベクトルの出現
コンパイラのバグや互換性のないサードパーティ製ライブラリに関連する攻撃ベクトルが、DeFi分野で実際に浮上しています。例えば、Curveのセキュリティインシデントの根本原因は、特定のバージョンのVyperコンパイラのバグであると特定されました。さらに、一部のプロトコルでは、thirdwebなどの一般的なサードパーティ開発ライブラリに実装された際に、ERC2771とMulticallという広く採用されている2つの規格間に非互換性が生じたことで攻撃を受けました。こうした複雑な技術的課題は、綿密なセキュリティプラクティスの重要性と、未知の脆弱性から保護するためのセキュリティ対策の継続的な進化の必要性を裏付けています。
コンパイラのバグ
1983年、ケン・トンプソンはチューリング賞受賞講演において「信頼の信頼性に関する考察 (Reflections on Trusting Trust)」と題するスピーチを行いました。このスピーチの中で、彼はCコンパイラを改変してプログラムにバックドアを挿入する方法を説明しました。これは予期せぬ結果をもたらす可能性があります。この講演で伝えられたアイデアはコミュニティに広く受け入れられました。しかし、（有名なXcodeGhostセキュリティインシデントを除き）悪意のあるコンパイラの現実的なケースは稀です。仮にセキュリティモデルを「悪意のあるコンパイラ」から「良性だが予期せぬ動作をするコンパイラ」に緩和したとしても、深刻な金銭的損失を引き起こすような公的なケースは依然として稀です。
VyperコンパイラのバグによるCurveのセキュリティインシデントは、約7,000万ドルの損失をもたらした公に知られている事例の1つです（一部は返還されており、実際の損失は約2,300万ドルです）。Vyperコンパイラのバージョン0.2.15、0.2.16、および0.3.0には、リエントランシーガード（再入保護機能）を無効にするバグがあります。つまり、攻撃者はリエントランシー（再入攻撃）を利用してハッキングを実行できるということです。開発者が再入攻撃を防ぐコードを追加していれば本来は起こり得ないはずですが、コンパイラが正しいバイトコードを生成できなかったために発生しました。
攻撃トランザクション: 0x2e7dc8b2fb7e25fd00ed9565dcc0ad4546363171d5e00f196d48103983ae477c
一般的な規格の非互換性
DeFiのコンポーザビリティ（構成可能性）により、異なるスマートコントラクトや規格が連携し、強力なアプリケーションを作成することが可能になります。しかし、これは潜在的な互換性の問題を引き起こします。例えば、各スマートコントラクトは個別に問題なく機能していても、人気のある規格を組み合わせることで新しいセキュリティの脆弱性が導入される可能性があります。
この非互換性の問題の例として、ERC-2771規格とMulticall規格の組み合わせが挙げられます。ERC-2771は、信頼できるフォワーダーを介してメタトランザクションを受信するためのインターフェースを定義し、Multicallは1回のトランザクション内で複数の関数呼び出しをバッチ処理するためのメカニズムです。問題は、信頼できるフォワーダーから転送された呼び出しが、calldataから実際の呼び出しアドレスを取得する際に発生します。これは攻撃者によって改ざんされる可能性があります。それぞれの規格は単独では完全に機能しますが、組み合わせて使用すると特定の前提条件が崩れ、予期せぬ問題につながる可能性があります。詳細については、OpenZeppelinのブログ記事を参照してください。
ERC-2771とMulticallの両規格は、OpenZeppelinやthirdwebなどの一般的な開発ライブラリに実装されていることに注意してください。開発者はこうした有名なコードベースを信頼しがちで、コード監査から除外してしまうことがあります。この慣習は、プロトコル自体に固有の脆弱性がなくても、新たなセキュリティの抜け穴を生む可能性があります。
トレンドIII：古い脆弱性がもたらす新たなセキュリティインパクト
精度欠損（Precision loss）とは、計算の過程で期待よりも小数点以下の桁数が少なくなることによって、精度が低下することを指します。静的解析ツールでは精度欠損の問題を容易に検出できますが、それが存在すること自体が直ちにセキュリティの脆弱性を示すわけではありません。精度欠損が重大な結果につながる可能性がある場合にのみ、脆弱性と見なされます。しかし、プロトコルのセマンティクス（意味論）とコードの具体的な文脈を深く理解する必要があるため、精度欠損による影響を評価することはしばしば困難です。
Compound v2やAave v2など、主要プロトコルのフォークであるプロトコルを標的とした攻撃がいくつか発生しており、それらが既知の精度問題の影響を受けやすい可能性があります。特に、Compound v2からフォークされたHundred FinanceやChannels Financeに関わるインシデントは、不適切に初期化されたマーケットや精度欠損に起因するものでした。これらの問題により、攻撃者は切り捨てエラー（rounding down errors）を利用して、少数のトークンで担保を償還することができました。
攻撃トランザクション: 0x3f7de75566289224c5e95a35ee8717ddd6928500227a05c1d83838844c60491d
0x1. 現在の解決策
実績のあるDeFiプロトコルがセキュリティ対策に多額の投資を行い、複数回のセキュリティ監査を受けてきたのは事実です。それにもかかわらず、これらのプロトコルが管理する膨大なユーザー資産を考慮すれば、プロトコルのセキュリティを極めて重要視することは完全に正当化されます。コード監査以外にも、脅威監視のような解決策が提案されています。現在のこれらの解決策の状況とその限界を掘り下げてみましょう。
コード監査
ここで定義するコード監査とは、プロトコルのリリース前に行われる、プロトコルのセキュリティ評価における重要なプロセスです。マニュアルコードレビュー、静的解析、動的ファジング（Fuzzing）、形式検証などの手法が組み込まれています。また、このプロセスは単一または少数の監査会社によって、あるいはコミュニティ主導の方法で行われることもあります。しかし、コード監査には認識すべき限界があります。
-
第一に、コード監査は主にプロトコルのデプロイ前に行われます。プロトコルが稼働を開始すると監査プロセスは通常終了し、最初のコード監査によって継続的なセキュリティを評価し続けることはできません。つまり、ローンチ後に発生する脆弱性や問題が、最初のコード監査では検出されない可能性があるということです。
-
第二に、コード監査では、悪用するために複雑な相互作用や特定の状態が必要となるような、微妙な脆弱性の特定がしばしば困難です。DeFiプロトコルのコンポーザビリティ（構成可能性）は、柔軟性と統合を促進する機能である一方で、プログラム空間を大幅に拡大し、人間のレビュー担当者や静的解析ツールにとって深刻な課題を突きつけます。これらはプログラムの全状態を網羅的に探索することが難しいためです。動的ファジングテストは有益ですが、トランザクションと状態の依存関係によって制限されます。不具合を検出できる「DeFiプロトコル対応のファジングオラクル」の欠如は、現在も産業界と学界双方にとって未解決の研究課題であり、この分野の大きなギャップとなっています。
-
第三に、有能なコード監査担当者が不足しており、人材プールが限られているため、迅速に解決することができません。コード監査はサイバーセキュリティ、金融、数学の知識を必要とする学際的なタスクです。この専門分野の教育を提供している大学は現在限られており、高品質なコード監査には高いコストがかかり、サービスまでの待ち時間も長くなっています。その結果、プロトコルはビジネス上のスケジュールを守るために、コード監査なしでリリースされる可能性があります。
-
第四に、ユーザーにとってコード監査の品質を評価することは困難です。ユーザーはプロトコルに資産を預け入れるため、そのセキュリティに最も投資している存在ですが、監査の徹底度を評価できるユーザーはほとんどいません。これは外見上の監査につながる恐れがあり、最終的にはプロトコルとユーザー資産の両方のセキュリティを損なう可能性があります。
結論として、コード監査はプロトコルを保護する上で貴重なツールですが、その本質的な限界から、唯一のセキュリティソリューションにはなり得ません。
脅威監視
脅威監視の基本的な考え方は、不審なトランザクションを監視・検出することです。これはセキュリティを向上させますが、効果的であるためには以下の懸念に対処する必要があります。
-
第一に、脅威監視システムの精度が非常に重要です。誤検知（偽陽性）と未検知（偽陰性）の両方を最小限に抑えるバランスをとる必要があります。誤検知率が高いと偽のアラートが発生し、ユーザーやセキュリティチームが警告に対して鈍感になり、真の脅威を見落とす可能性があります。
-
第二に、現在の脅威監視システムの多くは、不審なトランザクションの検出に対して積極的に行動を起こすために、手動での確認を必要としています。これは主に前述の誤検知率が高いという問題によるものです。手動介入のリアクティブな（受動的な）性質は、ペースの速いブロックチェーンやDeFiプロトコルの環境では、手動対応を行う前にも攻撃によってリソースが急速に枯渇してしまう可能性があるため、問題となります。したがって、攻撃を阻止または緩和するためのタイムリーな自動アクションを講じられない場合、脅威監視システムの価値は大幅に低下します。
-
さらに、脅威監視は永続的であり、新たな脅威が出現した際に適応できる能力を備えている必要があります。
0x2. BlockSecの見解
私たちは、プロトコルのセキュリティには、高品質なコード監査、リリース前のセキュリティテスト、攻撃の検出とブロック、そしてリリース後のセキュリティインシデントへの対応など、プロトコルのライフサイクルにおける各段階での多層防御が必要だと考えています。また、コミュニティで見過ごされてきた視点も強調したいと思います。
-
第一に、小規模なコードの更新や設定のアップグレードであっても、徹底的なセキュリティテストが必要だと考えています。このようなテストは、ユーザーデータの偽の状態ではなく、プロトコルの実際の状態で行われるべきです。前述したように、プロトコルの状態は、複雑なプロトコルの脆弱性を特定するために不可欠です。
-
第二に、手動介入以外の、攻撃に対する自動的な応答システムが必要です。これには、誤検知が非常に少なく、未検知がほぼゼロの、正確かつ迅速な攻撃検出システムが不可欠です。例えば、自動応答が導入されていれば、数百万人のユーザーの資産を守れる可能性があります。
-
第三に、適切なセキュリティインシデントへの対応手順を確立し、包括的なセキュリティサービスを提供できるセキュリティパートナーが必要です。例えば、エクスプロイト（脆弱性攻撃）が発生した際、パートナーは「作戦室」の立ち上げプロセスを支援し、講じるべき対策を推奨し、セキュリティパッチのレビューや監査を支援し、資金の流れを追跡するなどのサポートが可能です。yearn financeの記事は、エクスプロイトへの対処方法を学ぶための優れたリソースです。
BlockSecが提供するフルスタックセキュリティサービス
これらの知見に基づき、BlockSecはプロトコルに対してフルスタックのセキュリティサービスを提供します。
- 高品質なコード監査サービス。BlockSecは、DeFiプロトコルに対して徹底したコード監査サービスを提供します。独創的な学術研究に裏打ちされた静的解析ツール、動的ファジング、差分テストフレームワークを活用することで、私たちのコード監査はプロトコルと基盤となるEVM実行エンジンの両方を網羅しています。さらに、静的解析ツールHookScanは、Uniswap V4フックの脆弱性を検出するためにUniswap Labから支援を受けました。
- Phalcon: 攻撃検出およびブロックシステム。20以上の攻撃をブロックし、約1,400万ドル（USD）もの資金を救済した実績のある技術を持つBlockSec Phalconは、プロトコルが攻撃契約やトランザクションを積極的に監視（ハッカーが攻撃トランザクションを開始する前であっても）できるようにします。99.99%に近い精密な攻撃検出エンジンとユーザー定義のポリシーにより、BlockSec Phalconは誤検知と未検知のバランスを保ち、自動防御メカニズムを実現します。
- セキュリティインシデント対応。BlockSecは、DeFiハッキングにおける攻撃の根本原因や脆弱性を迅速に特定できる（最初ではなくても）最速のセキュリティベンダーです。私たちはプロトコルのセキュリティパッチのレビュー支援（Telcoin）、資金のホワイトヘット救出 [例: AnySwap, TransitSwap, Paraspace, Loot]、ハッキングされた資金のフロー追跡、Hopeland攻撃者の身元特定などを支援します。
0x3. 結論
2023年、私たちはDeFiプロトコルのセキュリティにおける新たなトレンドを見出し、多くの実績あるプロトコルが攻撃を受けていることを目の当たりにしました。プロトコルのセキュリティを技術面で確実に確保することは、複雑かつ継続的な挑戦です。単にコード監査や監視システムを採用するだけではもはや不十分です。私たちは、これらの要素を組み合わせ、プロトコルのライフサイクル全体を通して機能するフルスタックのソリューションを必要としています。
結論として、最先端の監査技術、自動攻撃防御ツール、迅速なインシデント管理を組み合わせたBlockSecの包括的なDeFiプロトコルセキュリティへのアプローチは、2024年のDeFi空間における進化し続ける脅威に直面し、セキュリティ対策を強化しユーザー資産を保護しようとするプロトコルにとって、主要なパートナーとしての地位を確立するものです。
