見せて、語るな：Evo Continuous Offensive Securityが実際のエンタープライズSaaSで発見したこと

自律型AI攻撃は、誰もが驚嘆した研究デモの段階を明確に脱し、今や日常的な攻撃手法となっています。十分に注意を払っている人にとっては、必ずしも目新しい話ではありません。Five Eyes Allianceは6月の時点で、AIがサイバーセキュリティを脅かすのは数年後ではなく数か月後だと警告し、攻撃者が防御を突破するまでの時間は、今や秒単位で測れると指摘しました。Gartnerも同様の予測を発表し、早ければ来年にも、悪用に至るまでの時間が半減すると見込んでいます。

攻撃者が見つけるものを、攻撃者より先に見つける。

だからこそ、Evo Continuous Offensive Securityの提供開始を発表したことは、ますます重要でタイムリーな意味を持ちます。人間の一流レッドチームと同じ方法で、アプリケーションとAIシステムを継続的に攻撃する自律型オフェンシブセキュリティを、3つの統合機能、AIペネトレーションテスト、エージェント型レッドチーム演習、動的テスト（DAST）を通じて提供します。

COSは市場で最も正確で信頼できるAIペネトレーションテスターを目指して設計されています。すべての検出結果は、いわば「独立した判定役」によって、実際に再現可能な悪用ができるか検証されてから、お客様に届けられます。これにより、最終的にレポートに記載されるのは、攻撃者が実際に悪用できるものだけです。

しかし、できることを言葉で伝えるだけでなく、実際にお見せしたいと考えています。以下で紹介するのは、顧客アプリケーションに対して実施した実際の評価と、そこで発見し、実証した本物の脆弱性2件です。

マルチテナント型エンタープライズSaaSに対する実際の顧客評価

ある顧客は、マルチテナント型エンタープライズSaaSアプリケーションの評価にCOSを利用しました。このアプリケーションは、Webクライアントとして使われるフロントエンドのシングルページアプリケーション（SPA）で構成され、そのSPAが、ビジネスロジックを担う数百のマイクロサービスエンドポイント群を利用していました。

このアプリケーションは、人間のペネトレーションテスターにも、DASTスキャナーのような決定論的ツールにも、さまざまな点で評価が難しく、特に興味深い事例です。

人間にとっては、数百ものマイクロサービスにわたって認可とビジネスロジックを漏れなく調べるのは非常に困難です。一方、機械にとって課題となるのはアクセスではありません。Snyk API & Web（Evo COSの動的テスト機能）のような最新のDASTスキャナーは、SPAに認証して、その背後にあるエンドポイントを問題なく列挙できます。難しいのはその後のほぼすべてです。認可やビジネスロジックの不備には照合できるシグネチャがありません。特定のロールが特定のエンドポイントを呼び出せるべきか、個々には有効なリクエストを連続して行うことで、アプリケーションが意図しない結果が生じるかどうかを判断するには、アプリケーションの目的と各ユーザーが実行できるべき操作を理解する必要があります。これが数百ものマイクロサービスにわたると考えれば、これは網羅性よりも推論の問題であることがわかるでしょう。そして、これこそ動的テストで自動化できていなかった部分です。

COSのエージェント型ソリューションは、LLMの力を活用しながら、体系的かつガイド付きのアプローチでアプリケーションを「探り」ました。

• 事前チェック：ヘッドレスブラウザーで提供された認証情報をテストし、必要なアプリケーション資産すべてにアクセスできること、またアプリケーションがテスト可能な状態であることを確認しました。

• 初期偵察：専用のサブエージェントが、アプリケーションの技術スタックや既存の各種エンドポイント、WAFの使用、チャットインターフェース経由で公開されたLLMエージェント、認証フローなどのセキュリティ関連情報を特定しました。重要なのは、この段階でアプリケーションのビジネス上の目的についても洞察が得られたことです。この事例では、ドキュメントがほとんどなく、テストデータしか用意されていないステージング環境だけを使って、製品の用途、利用者、実際の商業的価値を持つワークフローを正しく推定しました。この推定によって、以降のすべての評価を技術的な深刻度ではなく、ビジネスへの影響に照らして判断できました。

• 脆弱性のテストと検証：偵察の結果に基づいて、特定の脆弱性クラスを探す専門のサブエージェントを起動しました。個々の検出結果は、敵対的なサブエージェントが相互検証し、独立して再現できることを確かめ、誤検知の可能性を最小限に抑えました。

• 脆弱性の連鎖と検証：個々の脆弱性を論理的に関連付け、組み合わせて利用することでビジネスへの影響が増大するかどうかを検証しました。脆弱性の連鎖も、敵対的なサブエージェントが相互検証し、再現しました。

• レポートの作成：調査結果を、人間のチームが作成するレポートに倣った形式の文書にまとめました。エグゼクティブサマリーと、リスクを低減するための優先順位付きアクションリストも含まれています。

今回の評価は完全なブラックボックス方式で実施しました。つまり、ソースコードにアクセスせずに行いました。検出精度と効率を高めるためにソースコードへのアクセスを利用するグレーボックス方式にも対応していますが、今回はあえて使用しませんでした。いずれにせよ、実際の攻撃者と同じように外部からアプリケーションを攻撃する、動的テストの側面に焦点を当てています。

では、このアプローチでどのような利点が得られたのでしょうか。

1. アプリケーションのビジネス上の目的を見極められることは、特にそれが明白でない場合に大きな強みとなります。今回のテスト環境は実データがほとんどない「雑然とした」状態で、人間にとっても難しいタスクでした。ビジネス上の目的を特定することで、エージェント群は特定の脆弱性がビジネスに与える影響をより的確に解釈できます。

2. 当社のエージェントは実際のブラウザーを操作し、対象ごとのスクリプトを用意することなく、アプリケーションが採用する認証方式に適応します。ある評価では、顧客のログインが時間ベースの2要素認証で保護されていたため、TOTPシードを提供したところ、エージェントはログイン方法を把握する過程で、個別に設定することなくワンタイムコードの生成を自ら処理しました。これは機能としての能力以上に、信頼性を示す点で重要です。自動テストが最も頻繁に気づかれないまま失敗するのは認証の段階であり、ログイン画面を越えられない評価は、テストの質がどれほど高くても価値がありません。

3. ガイド付きの体系的なマルチエージェントアプローチを採用することで、人間のように創造的なエージェントの利点を活かしつつ、各マイクロサービスの認可、認証、ビジネスロジックの不備を体系的にテストし、テスト範囲を確保できます。

発見された脆弱性

このアプリケーションでは、古く安全でないjQueryライブラリの使用といった影響の小さい問題から、重大な脆弱性まで、合計33件の脆弱性を確認しました。重大なものには、任意の悪意あるサイトが認証トークンを窃取し、ユーザー操作なしにユーザーになりすませる、安全でないCORSポリシーや、あらゆるユーザーが自身のテナント内で管理者に昇格できる認可レベルの不備が含まれます。

簡潔にするため、ここでは2つの検出結果を取り上げます。これらは、このアプローチを際立たせる2つの点、つまり他のツールでは構造上見つけられないものを発見できることと、ツールが検出できる問題の真の影響を伝えられることを示しています。

1. Mass Assignmentと関数レベルの認可不備によるテナント全体の侵害

これは、DASTスキャナーでは構造上検出できず、人間のペネトレーションテスターでも発見するにはアプリケーションに関する深い知識が必要となるタイプの問題です。検出可能なリフレクションペイロードも、追跡できる明らかなエラーもありません。この不備は、テナント全体の設定を管理するレガシーな管理用エンドポイントにおける、アプリケーションの認可ロジックそのものに潜んでいます。

エージェントは、テナント全体のアカウント設定の保存に使われるレガシーなJSONエンドポイントが、サーバー側でロールや権限を確認せず、無制限のキーと値のアップサートを実行していることを特定しました。また、このエンドポイントの表面上は必須に見えるHMAC形式のsignature / timestampパラメーターも検証していませんでした。そこから結果を推論し、さらに脆弱性を連鎖させました。最も権限の低いユーザーロール（ログイン時に一般従業員全員に付与され、管理UIすら開けないロール）でも、テナント全体のセキュリティ上重要な設定を自由に書き換えられ、そのうち複数の設定を変更すれば、完全な侵害につながる可能性がありました。

発見から検証済みの連鎖を独立して再現するまでの全工程が、人間の介在なしに、1回の無人実行で完了しました。人間のチームが同じ結論に至るには、通常、アプリケーションに精通するまで何日もかかります。

以下は、エージェントのレポートから一部を抜粋したものです（顧客固有および製品を特定できる情報はすべて一般化しています）。

レガシーな管理用「アカウント設定の保存」エンドポイントは、テナント全体の設定ストアに対して無制限のキーと値のアップサートを実行します。サーバー側のロールや権限の確認も、HMAC形式の signature / timestamp クエリパラメーターの検証もありません。最も権限の低いロール（管理UIにすら移動できないロール）を含む、認証済みのテナントユーザーなら誰でも、標準のBearerアクセストークンを使ってこのエンドポイントを呼び出し、テナント全体のセキュリティ上重要な設定を自由に書き換えられます。

[...]

影響を受けるキーには以下が含まれます。

• パスワードポリシー：複雑さ、最小文字数、履歴数、最大有効期間。

• 認証ロックアウトポリシー：認証失敗のしきい値とロックアウト期間。

• 実行可能ファイル形式のアップロード拒否リスト。

• Content-Security-Policyに追加するソース。

• テナントから送信するメールの送信者ドメイン。

• サードパーティのエンタープライズ連携用OAuthパラメーター（クライアントID、クライアントシークレット、ログインURL、リソース、有効化フラグ）。

• 攻撃者が任意に定義した新しいキー。

根本原因：

1. 書き込みメソッドにロール／権限の確認がない。 2. 設定可能なキーの許可リストがなく、エンドポイントが任意のキー文字列を受け付ける。 3. 表面上は必須に見えるHMAC形式の signature / timestamp クエリパラメーターを検証していない。意図的に無効な署名を使ってテストしても、処理は成功した。

レポートではさらに、この脆弱性を再現する手順が詳しく説明され、ビジネスへの影響に関するセクションも記載されています。以下に抜粋します（こちらも一般化しています）。

影響：

最も権限の低いユーザーがテナント全体のセキュリティ設定を完全に読み書きできるため、侵害された、または悪意のあるテナントアカウント1つ（あるいは正当な低権限アクセスを持つ内部関係者）が、次のことを実行できます。

1. パスワードの最小文字数を1にする、複雑さの要件をなくすなど、パスワードポリシーを弱体化し、ロックアウトポリシーを無効にしたうえで、テナントのログインエンドポイントに対してオンラインでパスワードを推測し、テナント内の全ユーザーのアカウントを完全に乗っ取る。

2. 実行可能ファイルの拒否リストを解除し、低権限ユーザーがすでにアクセスできるコンテンツアップロード機能からネイティブ実行ファイルをアップロードして、テナント内にマルウェアを配布する。アップロードされたファイルは、テナントの共有コンテンツを閲覧するすべてのユーザーに広がる。

3. Content-Security-Policyの許可リストに攻撃者のオリジンを追加し、テナントの script-src と connect-src の範囲を広げて、クロスサイトスクリプティングを可能にする。

4. 送信メールの送信者ドメインを書き換えて悪用し、テナントへの通知が攻撃者の管理下にあるドメインから送信されたように見せかけます（テナントのインフラを通じて署名され、SPF/DKIMを通過するため、非常に巧妙な社内フィッシングが可能になります）。

5. サードパーティのOAuth連携のログインURL、クライアントID、リソースパラメーターを書き換えて乗っ取り、OAuthコード／トークンの交換先を攻撃者のインフラにリダイレクトします。さらに、テナントがIDプロバイダーだと思い込んで認証情報を発行したOAuth資格情報を窃取します。

6. セッションをまたいで侵害を持続させます。書き換えは攻撃者の約30分間有効なOIDCトークンの有効期限が切れた後も残るため、管理者が各キーを手動で検出して元に戻すまで、テナントは脆弱な設定のままになります。

7. 不正な設定を書き込んで管理UIを次回の解析時にクラッシュさせ、管理ページをサービス拒否状態にします。

必要なのは、最小権限のOIDCアクセストークンを1つ入手することだけです。これは一般社員を含む実際のテナントユーザー全員がログイン時に発行される、まさにそのトークンです。追加の制限も、管理者スコープも、署名も必要ありません。

これこそ、従来のスキャナーでは到達できない推論レイヤーです。制限のない書き込みを見抜き、各設定がビジネスに何を意味するかを理解し、それらをいくつか組み合わせてテナント全体の侵害につなげます。

2. CORSオリジンの反射：「些細な」問題を疑いようのない形で実証

クロスオリジンリソース共有（CORS）の設定ミスは、Web脆弱性の中でもごくありふれたものです。ほぼすべてのスキャナーや、十分なスキルを持つテスターなら、リクエストのOriginをAccess-Control-Allow-Originに反映しながらAccess-Control-Allow-Credentials: trueを返すエンドポイントを検出できます。難しいのは検出ではありません。

難しいのは、業界で長年続いているのにほとんど語られてこなかった問題です。脆弱性が報告されても、その実際のビジネスへの影響を後続の担当者が理解できる形に落とし込めないのです。深刻度は緊急性を伝えやすい一方で、実際にどのような被害が起こり得るかは、ほとんど伝わらないからです。

検出結果には脆弱性のクラス名とCVSSスコアが記載されますが、受け取ったチームは、潜在的な結果を示さない情報をもとに重要度を判断しなければなりません。そのため、より簡単な分析に頼り、数値だけで判断してしまいます。

「中」と分類された問題はすべて「高」の後回しになります。その結果、対応が遅れるだけでなく、労力が本当に必要な場所に割り当てられなくなります。実際のリスクがバックログに放置される一方で、理解しやすい検出結果の修正にチームの手が取られるのです。リスク評価の質は、それを支える影響分析の質に左右されます。しかし多くのツールでは、その分析は読む側の解釈に委ねられています。

この検出結果は、その好例です。一般的なスキャナーレポートでは、許可範囲の広いヘッダーに関する「中」深刻度の項目が1行表示されるだけです。しかし、実際には、ログイン中のユーザーがアクセスしたWebサイトならどこからでも、ユーザーの操作やフィッシングなしにセッションを密かに読み取り、ユーザーになりすまして操作するためのトークンを盗める状態でした。

設定ミスはIDプロバイダーにあり、アプリケーションのすべてのエンドポイントに適用されていました。また、クロスオリジンのレスポンス本文にはアクセストークンが含まれていました。つまり、これは単なるヘッダー設定の問題ではありません。「危険な」ページをたまたま閲覧したユーザーのアカウントが完全に乗っ取られる問題です。それでも、この脆弱性は「中」に分類されていました。

お客様でありデザインパートナーでもある企業が最も感銘を受けたのは、検出できたことだけではありません。エージェントがその後に実行したことです。問題とビジネスへの影響を説明するだけでなく、わずか数分で、標準のChromeブラウザー上で攻撃全体を再現する完全に動作する概念実証を作成しました。ページを開けば、自分のアクセストークンが攻撃者の管理下にあるオリジンへ送信される様子を確認できます。

お客様のチームの開発者は、プロキシもセキュリティの専門知識も専用ツールも使わずに、検出結果が実際のアカウント侵害を意味することを、説明されるのではなくその場で確認できます。最終的に、この違いが、トリアージされるだけの検出結果と、修正される検出結果を分けるのです。

こうした検出結果については、Evoプラットフォーム上で直接質問することもできます。平易な言葉で説明を求めたり、修正方法を提案させたりできるため、実証と修正を同じ場所で行えます。

私たちが重視する違いはここにあります。些細なCORSの検出ではなく、手軽に見つかった問題と、その現実世界への影響を疑いようなく示す実証との隔たりを埋めることです。

2つの検出結果、2つの異なる強み

ここから分かるCOSの違いは、より深く掘り下げられることと、影響を適切に伝えられることです。

深さについては、スキャナーでは検出できず、人間なら発見に何日もかかる認可の不備を見抜くことです。そして伝え方については、どのツールでも検出できる問題の現実世界への影響を、疑いようなく示すことです。

高性能なモデルにとって、脆弱性の発見は簡単です。難しいのは、ノイズを抑え、対象者が実際に行動に移せる形で、分かりやすく伝えることです。私たちのエンジニアリングの取り組みの多くは、そこに注がれています。

実際の動作を見る

ここまでの内容はすべて、実際のアプリケーションに対する1回の無人実行で得られたものです。私たちの言葉を信じるだけでなく、ぜひご自身の目でお確かめください。

AIペネトレーションテスト、エージェント型レッドチーム、動的テストがどのように連携して機能するのか、そして年に1～2回のペネトレーションテストより継続的なカバレッジが優れている理由については、ローンチのお知らせをご覧いただき、9月2日開催のウェビナー「AIのスピードで実現するペンテストレベルのカバレッジ」にぜひご登録ください。