ギャップを埋める: アプリケーション セキュリティ テストでレッドチーム診断を向上

※この投稿は米国時間 2024 年 12 月 6  日に、Google Cloud blog に投稿されたものの抄訳です。

概要

包括的なレッドチーム サービスであれ、標的型の外部評価であれ、組織はアプリケーション セキュリティ（AppSec）の専門知識を取り入れることで、最近の攻撃者の手口や手法を適切にシミュレートすることができます。以下に例を示します。

• 最小限のアクセスで最大限の効果を得る: 高度な権限昇格は不要です。多くの場合、レッドチームの目標はアクセスが制限されていても達成できます。このことから、インターネット接続されているすべてのアセットを保護することが重要であることがわかります。

• 脆弱性の連鎖で起こり得る、影響度の低い脆弱性の影響を認識する: 影響度が低い脆弱性と中程度の脆弱性を組み合わせて悪用されると、重大な影響が及ぶおそれがあります。

• 独自の不正プログラムを開発する: 公開されている概念実証の不正プログラムがない場合、スキルの高い攻撃者やコンサルタントは、リバース エンジニアリングやゼロデイ脆弱性の発見に時間とリソースを投じます。

• 多様なスキルセットを採用する: レッドチームは、AppSec を含む幅広い専門知識を持ったメンバーで構成する必要があります。

• 連携を促進する: 多様なスキルセットを組み合わせることで創造性が刺激され、より効果的な攻撃シミュレーションを行えるようになります。

• サービス全体で AppSec を統合する: 攻撃的なアプリケーション セキュリティの貢献が、プロジェクトのあらゆる段階でレッドチームに利益をもたらします。

組織はこのアプローチを採用することで、進化し続ける脅威ランドスケープに応じて能動的に防御し、堅牢で復元力の高いセキュリティ ポスチャーを確保できます。

はじめに

昨今の急速に進化する脅威ランドスケープにおいて、組織はますます巧妙化するサイバー犯罪者や国家アクターとの継続的な軍拡競争に巻き込まれています。そうした敵対者の先を行くために、多くの組織がレッドチーム診断を利用して実際の攻撃をシミュレートし、悪用される前に脆弱性を洗い出しています。しかし、従来のレッドチーム診断の多くは、ネットワークとインフラストラクチャのコンポーネントに対する攻撃を優先するのが一般的で、最近の攻撃対象領域の重要な要素であるウェブ アプリケーションを見落としがちでした。

このギャップをサイバー犯罪者が見逃すわけはありません。近年の業界レポートでは、攻撃者が組織への主な侵入経路として公開アプリケーションの脆弱性を悪用する傾向が強まっていることが常に取り上げられています。これは、脅威アクターの一般的な手口に関する Mandiant の見解と一致しています。2024 M-Trends レポートで Mandiant は、「初期侵入ベクトルが特定された侵入のうち、不正プログラムで侵入が開始されたのは 38% であり、2022 年から 6 ポイントの増加となった」としています。

また 2024 M-Trends レポートによると、初期侵害アクセスの 28.7% で、公開ウェブ アプリケーションが悪用されています（MITRE T1190）。

Mandiant はこのギャップを認識しており、AppSec の専門知識をレッドチーム診断に統合することでギャップの解消に取り組んでいます。このオプションのアプローチは、外部境界の範囲を拡大して自社のセキュリティ ポスチャーを深く理解しようと考えている顧客に提供されています。通常、大部分のインフラストラクチャはかなりのセキュリティ精査を受けていますが、ウェブ アプリケーションやエッジサービスには同程度の配慮がされていないことが多く、攻撃者の格好の標的となっています。

こうした統合型のアプローチは、全面的なレッドチーム サービスに限りません。さまざまな成熟度の組織が、重点的な外部境界評価において、アプリケーション セキュリティの専門知識を活かすこともできます。このような評価は、インターネット接続されているアプリケーションやシステムのセキュリティに関する分析情報を得るうえで、費用対効果の高い貴重な手段となります。

レッドチーム診断におけるアプリケーション セキュリティの役割

レッドチーム診断に AppSec の専門家が加わることで、ユニークな人員配置アプローチが実現します。この専門家の役割は、外部境界から組織を侵害するために攻撃者が使用する、進化し続ける悪用手法によってレッドチームの能力を強化することです。

AppSec の専門家は多くの場合、範囲設定や初期計画の段階でも、可能な限り早い段階で関与します。対象の境界を綿密に確認して、さまざまなアプリケーション インベントリをマッピングし、インターネットに公開されているウェブ アプリケーションやアプリケーション プログラミング インターフェース（API）のさまざまなコンポーネント内の脆弱性を特定します。

調査が行われている間、レッドチームのメンバーは、インフラストラクチャの準備、それらしいフィッシング キャンペーンの作成、ツールの開発と改良、標的環境の制御や防御のメカニズムを回避する効果的なペイロードの作成など、評価において重要な他の要素にも同時に注力します。

重大な影響を及ぼす AppSec の脆弱性を発見すると、一般的にチームはそれを悪用する段階に進み、予備的な知見を主な連絡先に通知するとともに、発見した脆弱性から起こり得る影響を検証します。ここで重要なのは、発見に成功しても、それが必ずしも標的環境への直接的な足場になるとは限らないということです。広範な偵察と境界確認の段階を通じて収集したインテリジェンスは、レッドチームのミッションのさまざまな部分で再利用できます。たとえば、次のようなことです。

• ソーシャル エンジニアリング キャンペーンを微調整するための、価値のある偵察対象または手法の特定

• 攻撃ペイロードの一層のカスタマイズ

• さらなる悪用につながる可能性のある一時的な足場の確立

• 攻撃シミュレーションの後の段階に向けた、悪意のあるペイロードのホスティング

レッドチームのメンバーは外部境界の調査段階が終わると、特定された脆弱性や関連する不正プログラムなど、AppSec チームの分析情報やインテリジェンスを基に、残りのミッション目標に取り掛かります。この時点でレッドチームのメンバーは残りの活動のほとんどを実施しますが、AppSec コンサルタントは引き続き密接に関与し、多くの場合、内部の悪用活動をさらにサポートします。たとえば内部からしかアクセスできないアプリケーションは、通常、外部からアクセスできるアセットよりも精査されることが少ないため、評価の頻度も低くなります。

AppSec の専門知識を取り入れることで、レッドチームが顧客の外部境界の確認において、足場を確立したり機密情報にアクセスしたりなど、大きな優位性を得ることに成功したケースが大幅に増加しました。この全体的なアプローチにより、ネットワークとアプリケーションの両方のセキュリティ リスクが包括的にカバーされ、顧客にとって現実的で価値のある評価ができるようになります。Mandiant は、攻撃対象領域全体にわたって脆弱性を発見し、対処することで、組織がさまざまな脅威を未然に防ぎ、全体的なセキュリティ ポスチャーを強化できるよう支援します。

事例紹介: アプリケーション セキュリティ サポートの効果の実証

Mandiant の AppSec チームの支援によって、レッドチーム診断の有効性が大幅に高まっています。このセクションでは、そうした実際の複数のシナリオから 4 つを取り上げます。それぞれの事例紹介で、攻撃ベクトル、攻撃の背景情報、経験から得られた主な教訓、関連する思い込みや誤解を紹介します。

こうした事例紹介から、レッドチーム活動にアプリケーション セキュリティ サポートを取り入れることの価値を知ることができ、連携や知識の共有が促進される貴重な学習機会も生まれます。

金庫を破る: 機密性の高い内部向けドキュメントにアクセスする API キーの漏洩

背景情報

あるエネルギー分野の企業が、検出、防止、対応に関するサイバーセキュリティ チームの能力の評価を Mandiant に依頼しました。この企業は幾度かの買収を経て過去数年間で大きく成長していたため、Mandiant は外部境界への注力を強化することを提案しました。こうすることで、子会社の外部セキュリティ ポスチャーを親会社と比較して測定できます。

標的

徹底的な偵察段階に続き、AppSec チームは顧客がビジネス パートナー向けに開発したモバイルアプリの調査を開始しました。モバイルアプリを逆コンパイルしたところ、外部の API サービスへの不正アクセスを許可する、ハードコードされた API キーが見つかりました。この API キーを利用し、API サービスに対して認証された偵察を行った結果、アプリの PDF 作成機能に重大な脆弱性があることが判明しました。完全読み取りサーバーサイド リクエスト フォージェリ（SSRF）が HTML インジェクションを通じて有効になるという脆弱性です。

脆弱性の特定

チームは最初の偵察段階で、多くの内部システムのホスト名が証明書の透明性ログを通じて一般公開されていることを確認しました。これを念頭に置いたうえで、SSRF 脆弱性を悪用し、外部 API サービスを介して到達可能な内部システムがあるかどうか判断することを目標としました。最終的に、そのようなホストが 1 つ特定されました。商用の ASP.NET ドキュメント管理ソリューションです。ソリューションの名前とバージョンが特定されると、AppSec チームはオンラインで既知の脆弱性を検索しました。その結果、安全でない ViewState のシリアル化解除に関する最近の CVE エントリが見つかり、影響を受けるダイナミック リンク ライブラリ（DLL）の名前が含まれていました。

悪用

不正プログラムの概念実証が公開されていないため、チームは DLL を検索し、最終的に VirusTotal の公開コーパスで見つけることに成功しました。その後 DLL を C# コードに逆コンパイルし、脆弱性のある関数を明らかにしました。この関数により、悪用を成功させるために必要なすべてのコンポーネントが提供されます。次に、アプリケーション セキュリティ コンサルタントが認証後の SSRF ベクトルを利用して、内部アプリケーションに影響を与える ViewState のシリアル化解除の脆弱性を悪用しました。この攻撃チェーンにより、親会社の内部ネットワークに信頼性の高い足場を築くことができました。

要点

この企業の非武装地帯（DMZ）が侵害され、リモート アクセスがレッドチームのメンバーに引き継がれました。これでレッドチーム側はネットワークへのラテラル ムーブメントを実施して、事前に定めたさまざまな目標を達成できます。ただし顧客は、特にアプリケーション サーバーに数多くの機密ドキュメントが保存されていたため、ラテラル ムーブメントの前に実証された影響に高い満足感を示しました。外部境界を悪用することは、内部ネットワーク内のラテラル ムーブメントがしやすくなるはずだというのは、よくある誤解です。しかし、実際にはラテラル ムーブメントの前であっても、顧客の機密データにアクセスできただけでその影響は明らかでした。

障壁を破る: 内部ネットワークへのゲートウェイとしてのブラインド XSS

背景情報

あるテクノロジー業界の企業が、Mandiant にレッドチーム診断を依頼しました。この企業は、セキュリティ プログラムが非常に成熟しており、すでに社内で数多くのフィッシングやビッシングの演習を実施していたため、フィッシングは行わないよう求めました。また、これまでに実施したレッドチーム診断ではさまざまなソーシャル エンジニアリングの手法に大きく依存しており、成功率は一貫して低かったとのことです。

標的

AppSec チームは外部偵察を行う中で、特注の顧客管理（CRM）ソリューションなど、興味深いの対象を複数特定しました。CRM のホスト名で Wayback Machine を利用したところ、古いエンドポイントが見つかりました。このエンドポイントは使われていないようでしたが、認証なしでアクセス可能でした。

脆弱性の特定

CRM のユーザー インターフェースからはアクセスできないにもかかわらず、エンドポイントにはサポートをリクエストするための機能的なフォームが含まれていました。AppSec チームはこのフォームに対し、悪用後のコードを含む外部 JavaScript ファイルを読み込む、ブラインド クロスサイト スクリプティング（XSS）ペイロードを挿入しました。この方法が成功すると、攻撃者は標的となったユーザーのブラウザタブを一時的に乗っ取り、そのユーザーに代わって操作を行うことができます。その後しばらくして、ユーザーが社内のカスタマー サポート管理パネルをブラウジングしている状況でペイロードが正常に実行されたとの通知がチームに届きました。

AppSec チームは引き出されたドキュメント オブジェクト モデル（DOM）を分析し、ペイロードの実行コンテキストを詳しく調べ、この社内アプリケーションからアクセスできるデータを評価しました。そして分析の結果、2004 年に初めてリリースされた Apache Tapestry フレームワークのバージョン 3 を参照していることが明らかになります。社内アプリケーションのフレームワークを特定した直後、Mandiant はローカルの Tapestry v3 インスタンスをデプロイし、潜在的なセキュリティ上の問題を特定しました。コードレビューを通じて、このコア フレームワークに、リモートコード実行（RCE）につながるシリアル化解除のゼロデイ脆弱性があることが判明しました。Apache Software Foundation は、この RCE に CVE-2022-46366 を割り当てました。

悪用

社内のカスタマー サポート アプリケーションに影響するゼロデイ脆弱性は、ブラインド XSS ペイロードを追加で送信することで悪用されました。フォーム送信時にトリガーされるよう作られたペイロードは、従業員のブラウザで自律的に実行され、社内アプリケーションのシリアル化解除の欠点を悪用します。こうしてクライアントのインフラストラクチャ内に重要な足場が築かれ、レッドチームはすべての目標を達成するまで、ラテラル ムーブメントを進めることができるようになりました。

要点

この実際のシナリオは、クロスサイト スクリプティングがレッドチーム診断にほとんど関連性がないという、よくある誤解を表しています。この事例において、特定の攻撃ベクトルの重要性と影響は明らかでした。つまり、ゲートウェイとして機能しており、社内アプリケーションを悪用するために外部ネットワークを侵害し、従業員の内部ネットワーク ポジションをプロキシとして利用しています。Mandiant はそれまで外部境界で XSS 脆弱性を特定したことはありませんでしたが、このことは、外部境界のほうが内部ネットワークよりもセキュリティ ポスチャーがはるかに堅牢である可能性があることを示しています。

ロガーの危険性: ログファイルからクラウドへの不正アクセスまで

背景情報

運輸分野のある企業が、Mandiant にレッドチーム診断の実施を依頼しました。目標は、外部に公開されたシステムやサービスに注目して、イニシャル アクセス ブローカー（IAB）の脅威グループをエミュレートすることです。通常そうしたグループは侵害された被害組織の環境への不正アクセスを転売します。それがこの企業にとって重大な脅威であることは、診断活動の支援を目的とした脅威プロファイルの構築の際、Google Threat Intelligence（GTI）チームによってすでに特定されていました。

標的

偵察段階で特定された数百の外部アプリケーションの中で特に目立っていたのは、クラウドでホストされている Java ベースの商用サプライチェーン管理ソリューションでした。このアプリケーションは、インストール手順を説明したオンライン フォーラムの投稿が見つかったことでさらに注目を集めました。その投稿には、インストールと管理について詳しく説明する、限定公開の YouTube 動画の共有リンクが記載されていました。動画を確認した AppSec チームは、このアプリケーションのトライアル インストーラの URL が、参照もインデックス登録もまったくされていないにもかかわらず、オンラインでアクセス可能になっていることに注目します。

インストールしてローカルにデプロイしたところ、インストール フォルダに管理マニュアルが用意されていました。マニュアルには、このアプリケーションとともにデフォルトでデプロイされたウェブベースのパフォーマンス モニタリング プラグインのセクションがあり、デフォルトの認証情報も記載されていました。そしてこのプラグインには、未処理エラーの発生時、パフォーマンス指標とトラック トレースをローカル ファイルに保存するロギング機能があります。さらに、プラグインのエンドポイント名は独特なものになっており、ディレクトリを総当たりする従来の方法で発見される可能性はほとんどありませんでした。

脆弱性の特定

AppSec チームは管理マニュアルから入手したデフォルトの認証情報を使用して、この企業のパフォーマンス モニタリング プラグインにログインし、認証後の脆弱性を特定するためのローカルテストを再開しました。また手動テストと並行してコードレビューを行うことで、認証済みのユーザーがログのファイル名やディレクトリを操作できるログ管理機能を特定しました。さらに、標的を絞った不正な HTTP リクエストを通じてエラーを誘発できることも確認しています。ログファイル名の操作と併せて、サーバーの基礎となるファイル システムの任意の場所に、任意のデータを強制的に保存することが可能でした。

悪用

手口は、意図的に例外をトリガーし、パフォーマンス モニタリング プラグインのログが、ウェブ アプリケーションのルート ディレクトリ内にある攻撃者が定義した Jakarta Server Pages（JSP）ファイルに保存されるようする、というものです。AppSec チームは不正プログラムを作成して、HTTP リクエストのパラメータに任意の JSP コードを挿入し、パフォーマンス モニタリング プラグインのエラーが攻撃者の管理する JSP ファイルに記録されるようにしました。JSP ログファイルにアクセスすると挿入されたコードが実行され、Mandiant は顧客のクラウド環境を侵害し、機密性の高い何千もの物流ドキュメントにアクセスすることができました。

要点

この事例では、侵害はオンプレミスの内部ネットワークへのアクセスや Active Directory の不正使用につながるはずだ、というよくある思い込みが覆されました。ラテラル ムーブメントには時間的制約がありましたが、イニシャル アクセス ブローカーをエミュレートするという当初の目標は達成されました。これには、内部の Active Directory ネットワークと比べてクライアントの可視性に欠けるクラウド環境を侵害することや、ビジネスに不可欠な重要情報にアクセスすることが含まれます。

共同侵入: Webhook による CI / CD パイプラインへのアクセス

背景情報

自動車分野のある企業が、Mandiant にレッドチーム診断の実施を依頼しました。目標は、継続的インテグレーションおよび継続的デリバリー / デプロイ（CI / CD）パイプラインへのアクセスです。外部に公開されているシステムがあまりに多かったため、AppSec チームには、レッドチームによる偵察と侵害をサポートするための人員が配置されました。

標的

興味を引いたアプリケーションのほとんどは、顧客のシングル サインオン（SSO）プロバイダにリダイレクトしていました。しかし、あるアプリケーションは異なる動作をしていました。Wayback Machine にクエリすることで、チームは SSO にリダイレクトしていないエンドポイントを明らかにしました。リダイレクトする代わりに、独自のファビコンを設定した空白ページが表示されました。チームはアプリケーションの基礎となっているテクノロジーを特定する目的でファビコンのハッシュを計算し、Shodan を使用してクエリします。その結果、同じファビコンを共有する、稼働中の他のアプリケーションが数多く返されました。興味深いことに、こうしたアプリケーションの中には SSO とは独立して動作しているものがあったため、チームはアプリケーションの名前とベンダーを特定できました。

脆弱性の特定

アプリケーションの名前を特定した後、チームはベンダーのウェブサイトにアクセスし、公開 API ドキュメントにアクセスしました。API エンドポイントの中に、目立つものが 1 つありました。SSO へのリダイレクトなしで顧客のアプリケーションに直接アクセスできるようです。この API エンドポイントは認証を必要とせず、数値 ID が増加するだけのパラメータ値を取っています。クエリすると、レスポンスにメールアドレスや電話番号など、機密性の高い従業員情報が含まれていました。チームはこの API エンドポイントに対して ID パラメータを増やしながら体系的な反復処理を行い、従業員のメールアドレスと電話番号の包括的なリストを作成しました。しかしレッドチームは別の興味深いアプリケーションを見つけたため、このデータの利用は控えました。そのアプリケーションでは、完全にユーザーが制御するメールを当該企業の「no-reply@」メールアドレスから送信させることのできる機能が公開されていました。

レッドチームはこうした脆弱性を利用してフィッシング キャンペーンを開始し、AppSec チームが外部侵害ベクトルを特定する前に、顧客のネットワークに足場を築くことに成功しました。内部の悪用後の活動が継続する中、アプリケーション セキュリティ コンサルタントは、内部ネットワーク内のレッドチームの活動をサポートすることに軸足を移しました。

悪用

ネットワーク共有を調査したレッドチームは、企業のソース管理アプリケーション アカウントの、開発者の認証情報を見つけました。AppSec チームは偵察データを選別し、同じソース管理アプリケーション サーバーが外部に公開されていることを報告しました。このユーザーは多要素認証を利用していなかったため、発見された認証情報を使用してログインができました。チームは GitHub インターフェースで、この企業の内部の Jenkins（ソース管理システムと CI / CD パイプラインの間の通信をしやすくするためによく採用されるインテグレーション）にリンクされた事前定義の Webhook を特定しました。そしてこの発見を活かし、新しい Webhook を作成しました。この Webhook が手動でトリガーされると、内部の URL に SSRF を行います。最終的に、認証されていない Jenkins サンドボックス バイパス脆弱性（CVE-2019-1003030）が悪用されてリモートコード実行につながり、企業の CI / CD パイプラインが効率的に侵害されます。

要点

この事例では、レッドチームと AppSec チームの連携の有効性が実証されました。両チームは共同で収集した分析情報を利用し、顧客が定めた主な目標である CI / CD パイプラインへのアクセスを達成するための戦略的なプランを策定しました。さらに、目標を達成するためには単一の致命的な脆弱性が不可欠であるという誤解に異議を唱えました。目標を達成するには、むしろ革新的なまわり道が必要になる場合が多いという現実を明らかにしています。実際、脆弱性と構成ミスを組み合わせる場合、それを見つけたのが AppSec チームかレッドチームかにかかわらず、戦略的に結びつけることで目的を果たすことができます。

まとめ

このブログ投稿で示したように、アプリケーション セキュリティの専門知識をレッドチーム診断に取り入れることで、セキュリティ ポスチャーの把握と強化を目指す組織に大きな利益がもたらされます。従来のアプローチでは見落とされがちなものを含め、攻撃対象領域全体にわたって脆弱性を事前に特定し対処することで、企業は侵害のリスクを最小限に抑え、重要なアセットを保護し、攻撃が成功した場合に生じる金銭的被害や評判の低下を回避することができるでしょう。

こうした統合型のアプローチは、レッドチーム サービスに限りません。さまざまな成熟度の組織が、重点的な外部境界評価において、アプリケーション セキュリティの専門知識を活かすこともできます。このような評価は、インターネット接続されているアプリケーションやシステムのセキュリティに関する分析情報を得るうえで、費用対効果の高い貴重な手段となります。

包括的なレッドチーム サービスであれ、標的型攻撃対策の外部評価であれ、組織はアプリケーション セキュリティの専門知識を取り入れることで、最近の敵対者の手口や手法を適切にシミュレートすることができます。

-Mandiant、執筆者: Ilyass El Hadi 氏、Louis Dion-Marcil 氏、Charles Prevost 氏