脆弱性自動発見マシンを構築 ―― AIトークンを投入すればゼロデイが出てくる

AIは脆弱性調査のあり方を変えつつありますが、その議論の多くは依然として理論の域を出ていません。モデルが将来的に何をできるようになるかではなく、現在利用可能なモデルが実際に何を発見できるのかを検証する必要があります。

私たちが答えたかったのは、より実践的な問いです。今すぐ利用できるモデルを使って、実運用中のソフトウェアに存在する現実の悪用可能な脆弱性を、AIはどこまで発見できるのでしょうか。

本稿では、Intruderのチームが、コードスキャンフレームワークと現行の(Mythos以前の)モデルを組み合わせ、LLMを使って未知の脆弱性を発見している手法を詳しく解説します。

実例として、30万人を超えるユーザーを抱えるWordPressプラグインで発見した、リモートから悪用可能な多段階SQLインジェクションのゼロデイ脆弱性を取り上げます。発見からエクスプロイトまでの一連の工程は完全に自動化されており、人間の介在は一切ありませんでした。

焦点の問題 ―― AIをコードベース全体に向けても機能しない理由

AIとコードスキャナーを組み合わせる際に大きな壁となるのが、「焦点」の問題です。LLMは、コードの小さな断片や特定の問題の説明を与えられれば、興味深い解決策を見つけ出すことに長けています。しかし、大規模なコードベース全体を対象にセキュリティ上の問題を探すよう指示すると、モデルはリポジトリ内のすべてのファイルを読み込もうとしてしまいます。

これはトークン消費の面でコストが高いだけでなく、精度の面ではさらに厄介な問題を引き起こします。処理が半分ほど進んだ頃には、モデルのコンテキストは無関係なコードで埋め尽くされ、本当に見つけたいバグはノイズの中に埋もれてしまうのです。

複数のステップを連鎖させる必要のある、より複雑なバグの場合はなおさらです。正しいコンテキストを記憶に保持し続けるか、必要に応じて的確に呼び出せるかどうかを、フレームワーク側に委ねることになります。私たちの経験では、この方法では質の低い出力しか得られず、本物の興味深いバグにはなかなかたどり着けません。

この問題は、従来型のコードスキャンフレームワークではすでに解決済みです。私たちは「プログラムスライス」と呼ぶ手法を用いています。これはIDEやLSPツールが「実装元を検索」機能やコールグラフを使い、現在の関数から呼び出されるすべての関数を特定するのと似た仕組みです。こうしたツールは成熟しており十分にテストされているため、コンテキストが希釈される問題をそもそも回避できます。

私たちのパイプライン ―― コードベースから動作するエクスプロイトまで

私たちは、コードベースを入力としてコードスキャンエンジン(Joernを使用)にかけ、各検出結果に関連するコードのスライスを生成し、LLMを使ってその問題のトリアージとエクスプロイトを行うパイプラインを構築しました。この設計はnooperator氏によるSliceの取り組みに着想を得ていますが、私たちはCodeQLではなくJoernを採用しており、対象とする特定の脆弱性クラスを扱うためにスライシングアルゴリズムもかなり異なる設計にしています。 

今回、このパイプラインを人気WordPressプラグイン上位200個に対して実行しました。これらはすでにバグバウンティ研究者によって徹底的に調査し尽くされているコードであり、そこで実際に何かを発見できれば、このプロセスが熟練した人間の調査員に匹敵する能力を持つことの証明になります。

まず、Joernが広く「興味深い」パターンを検出するよう設計されたルールに基づいてコードベースを解析します。このルールは意図的に緩めに設定しており、あまりに厳密なルールを作ってバグを見逃してしまう事態を避けています。どのみち後段のトリアージエージェントがフィルタリングを行うため、誤検知が多くなる方向に振り切っても構わないという判断です。

今回の実験では、未認証でアクセス可能なWordPressプラグインの攻撃対象領域を狙っていたため、Joernを使ってユーザー入力の影響を受けうる箇所をすべて特定させました。RESTルート、テンプレートフック、nopriv AJAX呼び出しなどが対象です。

WordPressの各フックについて、Joernはスライスを生成します。具体的には、そのフックが呼び出す関数、その関数がさらに呼び出すすべてのメソッド、というように連鎖をたどっていきます。基本的なテイント追跡によって、既知の安全なサニタイザーを経由するSQLやXSS向けの入力など、明らかに安全な関数は除外されます。コードが安全に実行できることを静的に検証できた場合は、それらをLLMに送る対象から外しています。

各スライスは、まず軽量なトリアージモデル(今回の検証ではSonnet)に送られ、公開を意図していて副作用のないフックなど、明らかに興味を引かない項目をふるい落とします。

残った候補は、より高性能なモデル(Opus)に渡され、悪用可能性を評価します。この際、関連するコール全体のコンテキストをメモリ上に保持したまま処理するため、無関係なソースコードをあちこち探し回る必要がありません。

悪用可能と判定されたものはすべて、最終段階のエクスプロイト作成エージェントに送られ、実際にエクスプロイトの作成が試みられます。このエージェントは(必要であれば)フルソースへのアクセス権も持っており、的を絞った検索で関連コードを見つけられるほか、開発中に対象ソフトウェアを動かすDockerコンテナを立ち上げてテストすることもできます。

最初の脆弱性 ―― 人気WordPressプラグインに潜んでいたブラインドSQLインジェクション

このパイプラインが最初に発見した脆弱性は、Creative Mailプラグインに存在するSQLインジェクション脆弱性CVE-2026-3985でした。この脆弱性が特に注目に値する理由はいくつかあります。 

• 攻撃者にデータベースへの読み取りアクセス権(管理者のハッシュ値や秘密トークンを含む)を与えてしまう、影響度の高い脆弱性である

• 悪用には複数のリクエストを連鎖させる必要があり、従来型のツールでは検知されにくい

• 根本原因は開発者自身のコード中のミスによって、開発者自身が使う静的解析ツールからも隠されていた

この脆弱性を悪用するにはCreative MailとともにWooCommerceがインストールされている必要がありますが、WooCommerceは人々がWordPressを利用する一般的な理由の一つであり(アクティブインストール数は700万件超)、この組み合わせは決して珍しいものではありません。

エクスプロイト作成エージェントは一発で動作する概念実証コードを作り上げ、問題の存在を確認するチェック機能と、データベースからパスワードハッシュを抽出できる完全な抽出手法を作成しました。

この脆弱性は、CleanTalk Inc.のDmitrii Ignatyev氏によっても独立して発見されており、同氏はWordfenceに報告を行っています。

当該プラグインはレビューのためWordPressストアから取り下げられています。WooCommerceと併せてCreative Mailを利用している場合は、パッチが提供されるまで無効化することをお勧めします。

技術的な詳細については、私たちの調査レポートをご覧ください。

発見は加速している ―― 検知もそれに追いつく必要がある

今回ご紹介したのは、このパイプラインが発見した最初の脆弱性に過ぎません。私たちはすでにさらなる脆弱性を発見しており、影響を受けるベンダーへの報告も進めています(それらは現在も情報公開前の段階にあります)。 

AIが脆弱性調査において果たす役割は明らかに拡大しており、いま取り組むべきは、現行モデルから最大限の成果を引き出すためのフレームワークを構築することです。攻撃者側もすでに同様のツールを使い、AIに高精度な入力を与え始めています。つまり、私たちがここで示した速度面での優位性は、防御側だけの専売特許ではないということです。

私たちの脆弱性自動発見マシンによって明らかになった脆弱性は、Intruderプラットフォームの検知チェック項目に反映されるため、次回のスキャンでそれらが発見・報告されるようになります。

Intruderを無料で試してみる。

著者: 

Sam Pizzey、セキュリティエンジニア、Intruder

Sam PizzeyはIntruderのセキュリティエンジニアです。以前はペネトレーションテスターとしてリバースエンジニアリングに没頭していた経験を持ち、現在はアプリケーションの脆弱性を大規模かつリモートで検知する手法の研究に注力しています。