ブラックボックス診断エンジンの改善
Takumi ブラックボックス診断エンジンの検知率と精度を高める改善を導入しました。
概要
脆弱性の種別毎に検証方法をより最適化し、検出精度を向上させました。またクローリング用エージェントが報告した情報を、より早期かつ効率的に診断エージェントのコンテキストに含めることで検知率を向上させました。
脆弱性タイプ別の検証戦略
Takumi ブラックボックス診断エンジンは大きく分けて以下三つの段階で構成されています。
- クローリングエージェントが診断対象を発見する段階
- 診断エージェントが脆弱性を発見・攻撃を試行する段階
- 発見された問題について、再現や悪用が可能かどうかを検証エージェントが調査する段階
三段階目では、LLMを介さない専用のプログラムを脆弱性種別毎に用意することで、LLMのハルシネーションによる偽陽性（存在しない、あるいは再現不可能な脆弱性の報告）に対応してきました。しかし、アプリケーション特有の脅威モデルや対策の実装方法によって判 断基準が異なるケースでは、このような手法は実装が困難であったり、実装しても偽陰性（存在する脆弱性の見逃し）に繋がってしまうことがあります。
今回のアップデートでは、従来のLLMを介さない検証プログラムを拡充しつつ、より柔軟性が必要な一部のケースについて新たな検証方法を導入しました。
Tier 1:
レスポンスから機械的に攻撃成功を判定できる脆弱性には、従来のLLMを介さない自動検証を使用します。今回、SQLインジェクションとサーバーサイドテンプレートインジェクションの Oracle を追加しました。
| 脆弱性 | 方法 |
|---|---|
| SQLi | 遅延ペイロードとレスポンス時間の測定によるタイムベース検出 |
| SSTI | プロキシログ内で計算式の評価結果（例: 2つの数の乗算結果）を検索 |
Tier 2:
機械的な判定は難しいものの、攻撃成立条件に一定の普遍性がある脆弱性には、チェックリストを持たせた批判役のLLMエージェントによる検証を導入しました。以下に例を挙げます。
| 脆弱性 | 確認事項 |
|---|---|
| CORS | Access-Control-*系のヘッダの組み合わせが脆弱かつ、レスポンスに機密情報が含まれるか |
| CSRF | CookieのSameSite属性、Content-Type、HTTP methodの組み合わせが脆弱かつ、当該リクエスト は状態遷移を伴うか |
これらのエージェントは診断環境にアクセスを持たず、与えられた脆弱性レポートをチェックリストに基づき承認或いは棄却します。
Tier 3: 観点を絞った検証
攻撃の方法や成立条件がアプリケーションごとに異なる脆弱性には、どちらの検証方法も適しません。例えば認証系の脆弱性は、アプリケーションの仕様によって攻撃が成立する条件が大きく変わります。
このような脆弱性に対しては、CORSやCSRFのように攻撃成立条件が明確な粒度までテスト観点を分解して診断を行い、その上で以下2点を検証しています。
- 発見された脆弱性が、指定された観点から逸脱していないか
- 発見された脆弱性が、指定された攻撃成立条件を満たしているか
パラメータ情報の早期収集による検知率の向上
従来、診断エージェントはパラメータ情報を自ら収集し診断を行っていました。今回の改善では、クローリング段階でURLおよびリクエストボディに含まれるパラメータの情報が体系的に収集され、診断エージェントのコンテキストに事前に含まれるようになりました。より効率的な対象理解や攻撃ベクトルの洗い出しが可能になり、検知率が向上 しました。
利用開始方法
本機能は既にすべてのTakumi by GMOユーザーに提供されています。ブラックボックス診断を開始するだけで、最新の機能をご利用いただけます。