HTTP Terminatorは数千件のHTTPデシンク仮説を生成・評価・実戦投入し、AIと人間の運用者のどちらか一方だけでは決して発見できなかったであろう新たな手法を浮かび上がらせました。
HTTP Terminatorをご紹介します。これは、HTTPリクエストスマグリングの脆弱性を抱えるウェブサイトを数百件も特定し、それらを大規模かつ実際にハッキングしてみせ、さらには「shared-parser confusion(共有パーサー混同)」と名付けられた「まったく新しいクラス」の脆弱性まで発見した、新種のAIシステムです。
しかし、これはAI単独の成果ではありません。終始、人間による導きがあったという点こそが、今回の発見の中で最も興味深い部分と言えるかもしれません。
セキュリティ企業PortSwiggerの研究者は、自らの研究手法を活かしてこのAI「HTTP Terminator」を設計・構築しました。的を絞った価値の高い問いを投げかけ、精度の低い回答を除外し、異常検知のロジックを適用し、決定論的なコードでエージェントの挙動を制限した上で、得られた知見をその後の「カスケード」型調査に反映させていったのです。
「これは、専門家がAI研究システムの強力な増幅装置になり得ることを示すもので、従来の通説を覆すものです」と、PortSwiggerの研究部門ディレクターであるJames Kettle氏はホワイトペーパーの中で説明しています。「ループを構築してあとは後ろに下がるだけでなく、人間がループの中に留まり続けることで、依然として大きな価値を付加できるのです」
HTTPリクエストの流れを乱す仕組み
HTTPリクエストスマグリングとしても知られるHTTPデシンク攻撃は、ウェブサイトがさまざまなユーザーからのHTTPリクエストを処理する仕組みそのものを妨害する攻撃です。このアーキテクチャでは、ユーザーはまずフロントエンドサーバーにリクエストを送り、フロントエンドサーバーがそれをバックエンドサーバーへ転送します。
問題は、リクエスト同士の分離が本質的に「脆弱」である点にあるとKettle氏は指摘します。フロントエンドサーバーは通常、パフォーマンスと効率を高めるために、同一のバックエンドとのネットワーク接続上で複数のリクエストを一度にまとめて送信します。
「HTTPリクエストは次々と送信されるため、受信側のサーバーは、どこで一つのリクエストが終わり、次のリクエストが始まるのかを判断しなければなりません」と同氏は説明します。しかし、フロントエンドとバックエンドの両システムは、各リクエストの終端がどこにあるかについて「合意」しておく必要があり、そうでなければ攻撃者はあいまいなメッセージを送りつけ、バックエンド側にそれを二つのリクエストとして誤認識させることができてしまいます。
攻撃者はレスポンスクエリポイズニング(RQP)を通じて、後続のリクエストに偽の情報を注入したり、データの流れを操作したりすることで、システムにどのレスポンスがどこから来たものかを見失わせることができます。そうなれば、本来他のユーザー宛てのレスポンスを横取りすることも可能になり、そこには機密情報や認証情報、APIキーが含まれる場合もあります。
リクエストスマグリングは一般にHTTP/1のリクエストに関連付けられていますが、Kettle氏によれば、バックエンドのアーキテクチャ次第では、HTTP/2をサポートするウェブサイトも脆弱性を抱える可能性があるとのことです。
「リクエストスマグリングの脆弱性は往々にして深刻な性質を持ち、攻撃者にセキュリティ制御の回避、機密データへの不正アクセス、そして他のアプリケーションユーザーへの直接的な侵害を許してしまいます」と同氏は述べています。
HTTP Terminatorの手法
Kettle氏は、自身の研究手法をベースにHTTP Terminatorを構築しました。
最初の段階は発想(アイデア創出)です。ここでは、例えばデシンクのトリガーやパターン、実戦投入の手法といった、検証可能なRQP攻撃の仮説を自律的に生成します。
次のステップは評価です。仮説を大規模に検証し、実際に機能するものを見極めます。HTTP Terminatorは、バグバウンティや脆弱性開示プログラム(VDP)を通じてセキュリティテストを許可している実在のウェブサイトを対象に利用しました。組み込みの異常検知レイヤーが、通常とは異なるレスポンスにフラグを立てる仕組みです。
続くのが実戦投入フェーズで、発見した内容が実際に現実世界で影響を及ぼすかどうかを判定します。
実際に影響を及ぼしたケースもありました。HTTP Terminatorは当初、3万件の固有の攻撃ベクトルを生成して継続的にテストし、まもなく金融機関や政府インフラを含む700件の脆弱なターゲットを特定しました。このシステムは、これらの銀行の一つから実際に稼働中のAPIキーを盗み出すことにも成功し、その他にもApache Traffic Server、Citrix NetScaler、BeyondTrustといった有名な企業向け製品の欠陥に起因する侵害が確認されています。
最後に、Kettle氏が「カスケード」と呼ぶステップがあります。一つひとつの発見は、見落とされていた標的や検知経路への手がかりとなり得ます。「何かを発見したら、その木を根元までさかのぼって探索することで、まだ見つかっていない別の枝を発見できることがあります」と同氏は説明します。
例えば、同様の挙動をほかの場所でどう検知できるか。そして、その挙動は他の種類の攻撃を可能にし得るか。本質的に、一つひとつの発見が「次の発見の種」になるのです。
「大したことがないように見えるかもしれませんが、これがポジティブなフィードバックループを生み出し、予測可能な発見の枠を超えて未知の領域へと連鎖的に発見が広がっていく可能性があります」とKettle氏は述べています。
最終的に、「自律型か人間かという構図自体が間違った捉え方だと気づきました」と同氏は説明します。「システム設計は『AI対コード対人間』という枠組みで捉えるほうが適切です」
HTTP Terminatorは、複数の新規デシンクトリガー、一つの新規デシンクパターン、そして一つのデシンク実戦投入手法を、考案かつ実証することに成功しました。
特筆すべきは、攻撃者がリクエストとレスポンスを解析して攻撃対象領域を広げることを可能にする、新たな「shared-parser confusion(共有パーサー混同)」という手法を発見した点です。
「それ自体、とてつもなく大きな成果です」とKettle氏は述べています。しかし同氏はこう強調します。「この発見は完全に自律的なものではありません。HTTP Terminatorが提案し、私がそれを検証したのです。どちらか一方だけでは、この発見には至らなかったでしょう」
Kettle氏はHTTP Terminatorを自身の研究の設計図とともにオープンソース化し、他のセキュリティチームが「自らの手法と直感を、自律的な調査兵器へと転換できる」ようにしました。
同氏は、目標を設定する、評価戦略を立てる、着想の源を確立する、そして新たな発見に向けてカスケード経路を探るという、四つのステップで課題に取り組むことを推奨しています。
「評価は、設計と実装の双方にとって最初の具体的なステップです」と同氏は述べています。「なぜなら、そこでの問題はプロジェクト全体を頓挫させかねないからです」
また、データ品質の問題を「積極的に」洗い出して解決しておくことも重要です。これは後になるほど修正が難しくなるためです。さらに、あまり範囲を広げすぎずに価値の高い問いを投げかけること、初期のテスト実行での出力結果を確認して価値の低い仮説を除外すること、そして「プロンプトの一文一文が増えるたびに、コンテキストが汚染されるリスクが高まる」ことを忘れないようにと、Kettle氏は述べています。
システムが完全にAI主導であり、かつAIが構築したコードに依存している場合、時間の経過とともに改善していくことはほぼ不可能だと同氏は言います。まずはAI主体のアプローチで素早く着手し、その後、速度と精度を高めるために決定論的なコードへと責任を移していくほうが良いとのことです。
「完全に自律的な研究は現実のものです」とKettle氏は認めています。しかし、「人間はAI研究システムにとって、強力なパワー増幅装置なのです」
