SSRF脆弱性影響調査: データ露出の影響を受けるセクタにはテクノロジー・産業・メディアなど

This post is also available in: English (英語)

概要

サーバーサイドリクエストフォージェリ(SSRF)とは、ファイアウォールの背後にある内部ネットワークやローカルホストに攻撃者のリクエストをリダイレクトしてしまうWebアプリケーションの脆弱性を指しています。SSRFは、クラウドサービスにとってとくに脅威となります。というのも、メタデータAPIを使用することで、基盤となるクラウドインフラストラクチャの構成やログ、認証情報などにアプリケーション側からアクセスできてしまうからです。メタデータAPIは、通常ローカルの接続元に限定してアクセスするものですが、SSRF脆弱性があるとインターネット側からでもアクセスできてしまいます。さらにこの種類の脆弱性は、コンテナサンドボックスによる保護もバイパスしてしまうので、内部ネットワークの偵察や水平展開からリモートコード実行にいたるまでの扉を開きかねません。

コンテナ内のアプリケーションはデフォルト設定でホスト上のメタデータAPIに直接アクセスできます。これにより、コンテナエスケープ、つまりコンテナから外のホストへのアクセスが特例的に可能となります。こうした問題がどの程度深刻なものであるかを知るために、私たちパロアルトネットワークス脅威インテリジェンス調査チームUnit 42のリサーチャーは、Jiraという商用プロジェクト管理ソフトウェアに存在するSSRF脆弱性CVE-2019-8451を例として取り上げ、この脆弱性による6つのパブリッククラウドサービスプロバイダ(CSP)への影響について調査することにしました。このJiraのSSRF脆弱性は、2019年7月に米金融大手Capital Oneのデータ侵害につながった脆弱性と同じ種類のものです。

弊社の脆弱性スキャナを使って確認できた内容は次の通りです。

• パブリッククラウド上にはインターネットに公開されているJiraインスタンスが7,000以上ある
• この7,000強のJIRAインスタンスの45％にあたる3,152個のインスタンスにCVE-2019-8451の脆弱性があり、これらはパッチ適用も更新もされていない
• この3,152個の脆弱なインスタンスの56％にあたる1,779個のインスタンスがクラウドインフラストラクチャのメタデータを露出させている

NVDによれば、CVE-2019-8451はバージョン7.6で初めて導入されたことになっていますが、私たちの調査からは、実際には2017年11月にリリースされたバージョン7.6ではなく、2011年3月にリリースされたバージョン4.3にまでさかのぼって同脆弱性の影響を受けることがわかりました。露出するメタデータは、内部ネットワークの構成、ソースコード、認証情報にまで及びます。影響を受ける組織にはテクノロジー・産業・メディア関連企業が含まれていましたが、とくにこれらのセクタに限定されるということはありません。

サーバーサイドリクエストフォージェリとは

サーバーサイドリクエストフォージェリ(SSRF)とは先に説明したとおりwebアプリケーション脆弱性で、本来ならサーバーに制限されているリソースに、悪意のあるリクエストをリダイレクトしてしまうものです。攻撃者は、脆弱なアプリケーションを騙して内部ネットワークやローカルホストなど任意のドメインに悪意のあるリクエストを転送することで、ファイアウォールを回避します。もっともよくあるタイプのSSRFリクエストはHTTP(s)ですが、ほかのすべての有効なUniform Resource Identifier(URI)スキーム、たとえばホストファイルシステム(file:////)、辞書サービス(dict://)、redisサービス(redis://) などを利用することができます。攻撃者は、対象アプリケーションがそのURIスキームをサポートさえしていれば、脆弱なサーバーと信頼関係をむすんでいるあらゆるターゲットにアクセスできますし、アクセスには追加の認証も必要ありません。

SSRFの根本的要因は、あるwebアプリケーションが別ドメインからのリソースを取得してリクエストに応えなければならないとき、その入力URLを適切にサニタイズせず、攻撃者に宛先を操作させてしまうことにあります。たとえばCVE-2019-8451の場合、脆弱性のあるAPI/plugins/servlet/gadgets/makeRequest?url=endpointがサービスプロバイダのエンドポイントからデータを取得し、gadgetに入力していくことになります。このとき、サーバーはクエリ文字列を検証し、ホワイトリストに登録されたエンドポイントのみを許可するのですが、ここでJiraWhiteListクラスに論理エラーがあり、パラメータの文字列に含まれる「@」記号がホワイトリスト検証をバイパスできてしまうのです。つまり、http://vulnerablehost.com/plugins/servlet/gadgets/makeRequest?url=http://vulnerablehost.com@http://targethost.comに送信されたリクエストは、targethost.comにリダイレクトされることになります。攻撃者がこの論理エラーを悪用すれば、脆弱なサーバーの到達範囲内にある任意のターゲットにHTTPリクエストを送信することができるようになります。

パブリッククラウドのメタデータAPI

ほとんどのクラウドサービスプロバイダ(CSP)は、メタデータAPIを提供しています。メタデータAPIとは、VMインスタンス上で実行されているプロセスが、そのVMについての情報を得やすくするためのもので、これによってプロセスは自身の実行環境を把握し、実行環境に応じた構成変更ができるようになります。メタデータAPIからは、インスタンスID、イメージID、プライベート/パブリックIP、ネットワーク構成などの情報が提供されます。このほか、VMの起動スクリプトやシャットダウンスクリプトも、メタデータサービスに配置されることがあります。こうすることで、同一のイメージからそれぞれに設定の異なる複数のVMインスタンスを作成できるようになります。CSPによっては、アプリケーションから動的なデータをメタデータAPIに書き込み、それを一時データストレージとして使用できる場合もあります。

メタデータAPIはVMインスタンス内からのみアクセスでき、ホスト外に公開されることはありません。このAPIにはどんなプライベートIPを割り当ててもよいのですが、ほとんどのCSPはルーティング不可の(リンクローカルな) IPアドレスである169.254.169[.]254を割り当てています。たとえば、あるプロセスは、AWS EC2インスタンス上でcurlコマンドを発行し、そのロールに関連付けられたセキュリティ認証情報を取得することができます(図1参照)。

curl
http://169.254.169[.]254/latest/meta-data/iam/security-credentia
ls/role-name

デフォルトでは、すべてのユーザーとプロセスにメタデータAPIへの完全なアクセス権限があります。観測で確認できた興味深い内容のひとつが、コンテナ内のアプリケーション(Docker、Kubernetes、ECS、EKSなど)も、ホストのメタデータAPIにアクセスできることです。コンテナから簡単にホスト側のメタデータにアクセスできるということは、便利な反面リスクでもあります。というのも、コンテナ内アプリケーション側は、ホストのメタデータAPIにクエリを発行し、添付した認証情報を使用してS3やRDSなどほかのクラウドサービスにアクセスすることができますし、ホストメタデータAPI側も、コンテナ化されたアプリケーションが機密性の高いホストのメタデータに直接アクセスできるよう、コンテナの「脱出経路」を用意しているからです。つまりコンテナが侵害されれば、攻撃者はこの経路を悪用してクラウド内ホストそのほかのサービスを侵害できる、ということになるのです。メタデータを公開せずともホスト-コンテナ間でデータを共有するすべはほかにもありますから、この利便性は実は潜在リスクに見合っていません。

さて、メタデータAPIサービスは通常ならインターネットに直接公開されることはないわけですが、インターネットに向けられた脆弱なアプリケーションがあれば、間接的には公開されてしまうおそれがあります。つまりSSRF脆弱性の存在はメタデータAPIサービスをインターネット全体に晒すことに等しいのです。これにより、露出したメタデータをもとに同じ仮想プライベートクラウド(VPC)内のほかのホストがさらに侵害されたり、クラウドインフラ全体が乗っ取とられてしまうおそれさえあります。機密性の高いメタデータとその影響の例としては、次の内容があげられます。

• IAMの認証情報: この情報はS3バケットやコンテナレジストリなどのクラウドサービスへのアクセスに使用できます。対象のインスタンスに管理者のアイデンティティが紐付けられていたり、そのアイデンティティが過剰な特権を付与されてプロビジョニングされている場合、攻撃者がクラウドインフラ全体を侵害してしまうおそれもあります。
• ユーザーデータ: メタデータ内には、ユーザーが指定したデータを格納することができます。通常、VMの起動スクリプトやシャットダウンスクリプトもユーザーデータに配置されます。これにより、当該VMがアクセスしうるアプリケーション構成やVM構成などのクラウドリソースが露出しかねません。こうしたスクリプト内にハードコードされた認証情報が見つかることも珍しくはありません。
• VMのイメージID: そのイメージが公開されていれば、悪意のある攻撃者は当該VMを精査して侵害戦略を立てることができます。
• ネットワーク構成: VMのプライベートIP、パブリックIP、MAC、ローカルホスト名、サブネット、VPCなどのネットワーク情報が露出されてしまいます。

メタデータAPIの悪用を防ぐため、一部のCSPはメタデータのHTTPリクエストに特別なヘッダをつけることを要件としている場合があります。たとえばAzure VMの場合、「Metadata: True」というヘッダをチェックしますし、Google Compute Engineであれば「Metadata-Flavor: Google」というヘッダをチェックし、要求されたヘッダのないHTTPリクエストは拒否されます。攻撃者にはリダイレクトされたリクエストのヘッダを制御することはできないので、こうしたヘッダを適用すればSSRFによるメタデータAPIアクセスはうまく阻止できます。表1は、調査対象の6つのCSPのメタデータAPIを比較したものです。

パブリッククラウドにおけるCVE-2019-8451の影響

パブリッククラウドにおけるSSRFの実際的な影響を知りたければ、パブリッククラウドに広く展開されているアプリケーションで既知のSSRF脆弱性を持つものを見つけなければなりせん。そこで私たちの目を引いたのが、2019年8月に発見された認証なしで悪用可能なJiraのSSRF脆弱性CVE-2019-8451でした。このパッチはすぐにリリースされましたが、Jiraのようにビジネスオペレーションに密接に関連しているソフトウェアが即座に更新されることはめったにありません。システム管理者も、業務を中断するよりパッチ適用を遅らせたがるのです。Shodan検索したところ、現状、インターネットには約25,000個のJiraインスタンスが公開されていることがわかりました。次に、Jiraデプロイ数が最も多い6つのCSPを選択して調査を実施しました。調査目標は「パブリッククラウドに存在するCVE-2019-8451に対して脆弱なJiraインスタンス数」、「それらJiraインスタンスが悪用される可能性」、「メタデータを露出しているホストの数」を特定することでした。調査の結果、6つのパブリックCSPで7,002個のJiraインスタンスが見つかりました。図2はそれぞれのJiraバージョン分布を示したものです。

CVE-2019-8451に対するパッチが最初に適用されたバージョンが8.4であることを考慮すると、図2のJiraインスタンスの80％が8.4未満のバージョンであるということは、パッチを適用しない限りこれらすべてのバージョンに脆弱性がある可能性があるということを意味します。また私たちがスキャンした結果からは、7,002個のJiraインスタンスのうち、45%にあたる3,152個のインスタンスにはパッチが適用されておらず、脆弱性があることもわかっています。

図3は、パッチが適用されていないJiraのバージョン上位10位までを示しています。3,152個の脆弱なJiraインスタンスのうち、56%にあたる1,779個がホストのメタデータを露出させています。表2は、すべてのCSPの統計をまとめたものです。DigitalOceanを利用しているユーザーのメタデータ露出割合が最も高く(93％)、次点がGoogle Cloudのユーザー(80％)、その後はAlibabaのユーザー(71％)、AWSのユーザー(68％)、Hetznerのユーザー(21％)と続きます。

メタデータ露出のない唯一のCSPがMicrosoft Azureです。Microsoft AzureではメタデータAPIについて先に述べたヘッダが厳密に要求されるので、すべてのSSRFリクエストが実質上ブロックされます。GCPの場合、最新のメタデータAPI (V1)であればヘッダ要件は強制ですが、レガシーAPIエンドポイント(v0.1およびv1beta1)が明示的に無効化されていないかぎり、攻撃者はレガシーAPI経由でほぼすべてのメタデータにアクセスできます。

図3からは予期せぬ知見が得られました。その1つが、上位10バージョンに含まれる2つのバージョンv7.3.6とv6.3.6が、Jiraの公開している脆弱なバージョンに含まれていないことです。Jiraのバグ管理システムとNVDによれば、「CVE-2019-8451はv7.6で初めて導入され、v8.4で修正された」ことになっています。ところがスキャン結果からは、上記対象以外の多くのバージョンも脆弱であることが示されたのです。そこで私たちは当該脆弱性による実際の影響を調べるために、SSRFを引き起こす脆弱性をもつクラスJiraWhiteListを確認しました。メソッドを1つしかもたないこのシンプルなJavaクラスは、Jiraにv4.3から存在しています。このレガシーJiraソフトウェアについてさらに調査を進めた結果、本脆弱性は、8年以上前の2011年3月にリリースされたバージョン4.3まで遡って実際に影響を与えることが確認されました(訳注: ただし脆弱性のあるバージョンは2019年11月末にサポートを終了しています)。

緩和策とベストプラクティス

SSRF脆弱性の根本的要因は適切な入力サニタイズが行われないことにあります。この問題を解決するには、開発者がユーザー入力の形式とパターンを厳密に検証してから、アプリケーションロジックに渡さなければなりません。

ここではwebアプリケーションのインストールと管理のみを行うシステム管理者向けに、SSRFの影響緩和で推奨される保護対策の一例を以下に示します。

• ドメインのホワイトリスト登録: ほとんどのアプリケーションが通信する必要があるのは、データベースやAPIゲートウェイなど、ごく一握りの限られたドメインだけです。アプリケーションが通信できるドメインのホワイトリスト登録を強制すれば、攻撃者が標的にできるサービスは大幅に減らせます。
• ゼロトラストネットワーク: 同じ内部ネットワーク内にあるという理由だけで別のアプリケーションを信頼してはいけません。SSRFは標的となったサービスに認証が要求されれば失敗しますので、すべてのアプリケーションに認証・認可機能を実装するようにします。
• webアプリケーションファイアウォール(WAF): WAFを使えばHTTPリクエストに含まれる異常なパターンや悪意のあるコンテンツを検出することができます。ただしWAFは、既知の脆弱性やSQLインジェクションやXSSなどのように、明確なパターンをもつ攻撃用に作成されたルールを使って対策をするものなので、ゼロデイの脆弱性はバイパスされる場合があります。
• パッチ適用と更新: 継続的にアプリケーションにパッチを適用して更新することが、脆弱性を防ぐ上で最もシンプルで有効な手段です。ただしこれもベンダからのサポートが受けられる場合に限られます。サポートが終了したアプリケーションであれば更新を受けられないからです。

表2にも示したとおり、メタデータAPIを最も効果的に保護できるのはCSPでしょう。つまり、そのCSPからの保護が受けられない状況であれば、クラウドユーザー側が予防措置を講じてメタデータの露出リスクを減らさねばなりません。

• CSPのメタデータAPI保護機能を有効にする: 一部のCSPは、設定でメタデータAPI保護できるようなオプションを用意しています。GCPのユーザーはレガシーメタデータAPIのバージョンを無効化し、HTTPリクエストのヘッダ要件を強制しましょう。DigitalOceanのユーザーはcloud-configスクリプトでメタデータAPIサービスをを無効化できます。
• メタデータIPをブロックする: ファイアウォールルールをVM内に作成し、メタデータAPIのIPを完全にブロックすることができます。より細かくファイアウォールルールを設定して特定のアプリケーションやユーザーだけにメタデータAPIへのアクセスを許可することもできます。
• メタデータプロキシ: オープンソースツールのmetadataproxyやaws-metadata-proxyなどを使うとネイティブのメタデータAPI上にもう1つレイヤーが作成され、そこでメタデータへのアクセスを必要とするアプリケーションをきめ細かく制御できます。
• IAMで最小限のアクセス権のみを付与する：VMにIAMロールを紐付けることで、そのVM上のアプリケーションが他のクラウドサービスにアクセスできるようになります。IAMの特権を、アプリケーションが必要とする必要最小限のサービスに制限することが重要です。この最小特権の原則は、認証情報が侵害された場合の影響を最小限に抑えてくれます。

結論

SSRFはそれ自体では深刻な脆弱性ではないかもしれません。ですがメタデータAPIやクラウドインフラの構成ミスと合わさると、他のさまざまな攻撃ベクトルへの扉を開いてしまいますし、そこから認証情報やネットワークアーキテクチャなど、機密性の高いメタデータが漏えいし、データベースやストレージなどの内部サービスが露出してしまいかねません。最悪の場合、クラウドインフラ全体が侵害される可能性すらあります。この調査ではクラウドインフラへのSSRFの影響を示す例としてとくにJiraの脆弱性CVE-2019-8451を取り上げましたが、Jira以外にもクラウドでの悪用が可能な既知のSSRF脆弱性をもつアプリケーションは多数存在します。CSP側もメタデータAPIの保護に努めはじめてはいるようですが、そうした実装が行き渡るにはまだしばらく時間がかかることでしょう。システム管理者やクラウドサービスの利用者は、リスク緩和のため、上記をはじめとするベストプラクティスに従うことを強くお勧めします。

Palo Alto Network製品をお使いのお客様は、VM-seriesとPrisma CloudによってSSRFから保護されています。VM-series はアプリケーショントラフィック分析でクラウドのワークロードを保護し、Prisma Cloudはパブリック、プライベートを問わずクラウド環境にフルスタックにわたる可視性を提供します。