Web3をプロアクティブな脅威防止で保護する

はじめに

過去3年間で、DeFiエコシステムではいくつかのセキュリティインシデントが発生しました。これらの脅威に対抗するため、コミュニティでは静的コード監査、スマートコントラクトスキャナー、動的ファジングといったコード中心の手法が採用されてきました。これらの手法は有効性を示していますが、コード中心のアプローチだけではセキュリティ問題やユーザー資産を完全に解決できないと私たちは考えています。例えば、脆弱なコントラクトが複数の著名なコード監査会社によって監査された事例が複数存在します。

既存のコード中心のアプローチに加えて、脅威に対抗するための、より積極的な脅威防止ソリューションが存在すべきだと私たちは信じています。このアイデアについて2021年末に社内で検討し、2022年初頭にIronDomeというシステムを開発しました。それ以来、BlockSec社内でこのシステムを導入しています。2022年には、IronDomeは複数の攻撃を阻止し、500万ドル以上のユーザー資産を保護しました。これには、2022年4月のSaddle Financeへのエクスプロイトを防ぎ、380万ドルを救済した事例も含まれます。

本ブログでは、IronDomeのシステムアーキテクチャとその成功事例について詳しく説明します。また、当社のシステムの限界と、脅威防止の将来の方向性についての洞察も議論します。

システムアーキテクチャの概要

IronDomeの基本的な考え方は、Ethereumの保留中トランザクションプールを監視し、トランザクション事前実行システムMopsusを通じて攻撃トランザクションを検出し、脆弱な資産を安全なアカウントに移動させるための救済トランザクションを自動的に生成してFlashBotで攻撃トランザクションより先に実行することで攻撃を阻止するというものです。以下の図は、そのアーキテクチャを示しています。

Mempool監視

IronDomeは、カスタムGethクライアントを通じてメモリプール内の保留中トランザクションを監視します。重要な点は、システムがトランザクションを迅速に監視し、可能な限り多くのトランザクションを監視する必要があるということです。

攻撃検出

保留中の各トランザクションは、攻撃検出モジュールに渡されます。これらのトランザクションはまだチェーン上にないため、トランザクション事前実行エンジンMopsusを活用してこれらのトランザクションを事前実行し、トランザクションの実行時状態と結果に基づいて攻撃（悪意のある）トランザクションを検出します。

救済Tx合成

攻撃トランザクションに対して、IronDomeは自動的に救済トランザクションとその補助コントラクトを合成します。救済トランザクションは、攻撃トランザクションと同様の方法で脆弱なコントラクトを「エクスプロイト」しますが、利益を攻撃者が制御するアカウントではなく、当社の安全なアカウント（マルチシグアカウント）に転送します。例えば、攻撃コントラクトと同様の補助コントラクトを自動的にデプロイできますが、トークン転送先アドレスを当社の安全なアカウントに置き換えます。もちろん、一部の攻撃トランザクションには、より複雑なアプローチが必要になります。

救済トランザクションを攻撃トランザクションより先にチェーン上に載せる必要があります。現在のシステムでは、この目的のためにFlashBotを利用しています。まず、他の誰にも当社の救済Txが傍受されないことを保証する必要があります。次に、救済トランザクションをブロックの先頭に配置するための戦略をとることができます。

代表的な成功事例

IronDomeは2022年初頭に導入されました。このシステムは、複数の攻撃を検出し、阻止することに成功しました。この表は、いくつかの成功事例をまとめたものです。

以下のタイムラインは、当社のシステムが2022年4月末にSaddle Financeから380万ドルを救済した経緯を示しています。特に、当社のシステムは、攻撃トランザクションの検出から救済Txの自動合成まで、プロセス全体を1秒未満で完了しました。救済された全資金はSaddle Financeに返還されました。元のハックTxと当社の救済Txへのリンクは以下の通りです。

元のハックTx: https://etherscan.io/tx/0xd9bc83688e8eddde39bd9073c363665b1419d475dd4498e81b52cce41d7c76b3
当社の救済Tx: https://etherscan.io/tx/0x9549c0cb48ec5a5a2c4703cbbbbea5638028b2d8c8adc103220ef1c7fe5e99a3

倫理的配慮

当社は、システムにおけるセキュリティ倫理を真摯に受け止めています。当社のシステムは、脆弱なコントラクトを「エクスプロイト」してユーザー資産を救済しますが、この行為に倫理的な問題はないと考えています。

第一に、当社のシステムは脆弱なコントラクトを積極的にエクスプロイトするわけではありません。保留中の攻撃トランザクションを検出した場合にのみ反応し、類似のトランザクション（攻撃トランザクションを阻止するため）を自動的に合成します。攻撃トランザクションを最初に作成することはありません。
第二に、影響を受けたプロトコルと積極的にコミュニケーションを取り、救済した資金を返還しています。

限界

IronDomeはその有効性を示していますが、システムにはいくつかの限界があります。以下にこれらの限界を説明し、積極的な脅威防止のさらなる方向性について議論します。

第一に、当社のシステムはmempool内の保留中Txを監視します。攻撃者がFlashBotのようなプライベートトランザクションサービスを利用する場合、攻撃トランザクションはmempoolに存在せず、検出できません。この問題に対処するため、プライベートトランザクションサービスプロバイダーとの協力を呼びかけ、当社のシステムと同様の方法で悪意のあるトランザクションを検出および阻止することを目指します。さらに、当社のシステムが保留中プールで攻撃Txを阻止できない場合でも、チェーン上の攻撃Txを検出し、さらなる攻撃トランザクションを防ぐために救済Txを送信することができます。多くのケースでは、複数の攻撃トランザクションが存在します。
第二に、セキュリティは軍拡競争です。攻撃者が救済トランザクションの合成のハードルを上げる事例を見てきました。例えば、攻撃トランザクションを複数のトランザクションに分割し、利益のアドレスを隠蔽することができます。これらの問題は解決可能ですが、軍拡競争は止まらないと考えています。これらの問題の解決策に取り組んでいます。
第三に、救済トランザクションを攻撃Txより先にチェーン上に載せる方法が依然として未解決の課題です。一部の入札戦略は、当社の救済Txがブロックに取り込まれる可能性を高めることができますが、100%の保証はありません。