Tenable ブログ
ブログ通知を受信する
サーバー側要求偽造の検出に Tenable.io WAS を活用する
本稿では SSRF の脆弱性の背景、よく使用される 3 つの攻撃経路の措置が困難な理由、Tenable.io Web Application Scanning を活用したセキュリティ対策について解説します
最新の Web アプリケーションは、内部および外部のアプリケーションプログラミングインターフェース (API)、マイクロサービス、データベースなどと相互に通信し、データを共有するさまざまなサービスを使用して設計されています。これらの Web アプリケーションは、外部コンテンツの読み込みなどの便利な機能をエンドユーザーに提供します。
しかしながら、攻撃者はサーバー側要求偽造 (SSRF) の脆弱性を悪用する可能性があります。サーバー側要求偽造 (SSRF) は、深刻な影響を与える可能性がある、複雑な Web アプリケーションのセキュリティ上の脆弱性です。SSRF の脆弱性は非常に一般的な脅威であり、2021 年には Open Web Application Security Project (OWASP) トップ 10 に挙げられています。
サーバー側要求偽造とは
SSRF は、アプリケーションの機能の脆弱性で、悪用されるとフィルタリングや検証が行われない任意の URL が提供できるようになり、攻撃者は通常は内部ネットワークからのみアクセス可能なサードパーティのサービスまたはリソースに新しい要求を送信できるようになります。攻撃者は SSRF を使用して、機密性の高い内部サービスにアクセスしたり、資格情報や設定ファイルなどのリソースを取得したりする可能性があります。
通常は内部ネットワークサービスと相互作用するコンポーネントから要求が行われるため、ファイヤーウォールの通過が許可される場合があります。そのため、SSRF は機密性の高いビジネスシステムに重大なリスクをもたらす可能性があります。
この種の脆弱性の悪用と潜在的なリスクに関する問題の詳細を見る前に、いくつかの基本的な概念を理解する必要があります。私の経験では、セキュリティ担当者は、SSRF をオープンリダイレクトの脆弱性と混同することがよくありますが、これらは、まったく異なる影響を伴う 2 つの異なる脆弱性です。
次の例を考えてみましょう。
GET“ returnUrl” パラメータがユーザーにより指定された場合、Web サイトは指定された値にリダイレクトします。したがって、この場合、攻撃者から URL “http://domain.tld/?returnUrl=https://evil.org“ が提供されると、ブラウザは HTTP リクエストを送信し、ユーザーを “https://evil[.]org” にリダイレクトします。
上記の例では、リダイレクトはサーバー自体ではなくクライアント側で実行されます。したがって、ブラウザから直接社内サーバーにアクセスしようとするので、内部リソースにアクセスすることはできません。これは、パブリック IP アドレスがない場合は技術的に不可能です。
次の例を見てみましょう。
GET “url” パラメータが攻撃者により指定された場合、curl リクエストが行われ、結果が表示されます。したがって、任意の URL を渡すと、コードがページのコンテンツを取得して表示します。
前の場合と同様に、HTTP リクエストがリソースに対して行われます。ただし、この場合、要求はサーバー自体から送信され (サーバー側の要求)、ブラウザからは送信されません (クライアント側の要求)。
この特定のケースでは、SSRF の脆弱性の問題はありません。Web アプリケーションが外部リソースからコンテンツをフェッチする (プロファイルにアバターを追加するなど) ことは正常で予想されるためです。このアバターの例では、ユーザーは Web アプリケーションを使用して、ハードドライブまたはリモート URL から画像を選択できます。Twitter のような人気のあるサービスは、ツイート内の URL のプレビューを提供し、このプレビューは、サービスレベルのアプリケーションに対して正当な HTTP リクエストを作成します。
最近の Web アプリケーションアーキテクチャには、多くのマイクロサービスと API (Rest、GraphQL など) が含まれていることが多く、これらのサービスは相互に通信する必要があることがよくあります。たとえば、コース集中化サービスは、コースをプラットフォームに統合するために、JSON 形式のコースの URL をユーザーに要求できます。したがって、アプリケーションはリソースに対して正当な HTTP リクエストを行うことができます。ただし、フィルタリングまたは検証が実行されない場合、ユーザーはプライベートリソースを取得するために任意の URL を渡すことができます。
この例では、SSRF の脆弱性は、Web アプリケーションが内部ネットワークなどの許可された範囲外の URL で許可されていないリソースをフェッチしたときに発生します。
SSRF 攻撃の 3 つの一般的な攻撃経路
攻撃者は SSRF の脆弱性を突いて、さまざまな経路で攻撃を仕掛けることができます。最もよく使用される 3 つの攻撃経路は以下のとおりです。
- 「file://」ラッパーを使用してサーバー上の任意のファイルを読み取る
- 「http://」または「gopher://」ラッパーを使用して他のサービスと対話し、リモートコード実行 (RCE) を実行する
- ブラインド攻撃
「file://」ラッパーを使用してサーバー上の任意のファイルを読み取る
Web アプリケーションが「http://」を使用する代わりに、「file://」ラッパーを使用するように強制できます。「file://」ラッパーは、通常、自分のコンピューター上のファイルを検索するために使用される URI (URI（Uniform Resource Identifier) スキームです。したがって、アドレス/ URL バーで「file:///etc/passwd」を使用するか、端末で curl コマンド（「file:///etc/passwd’」）を使用すると、自らの「passwd」ファイルが表示されます。
さまざまなユースケースに使用できるさまざまなラッパーがありますが、「file://」ラッパーはデフォルトで有効になっていることが多いため、SSRF 攻撃の標的になっています。次の表は、デフォルトでファイルラッパーを有効にするラッパーを示しています。
前述のケースの例として、次の脆弱なアプリケーションを見てみましょう。予想される URL の代わりに「file:///etc/passwd」を使用して、ファイルラッパーを使用すると passwd ファイルを取得できます。
この脆弱性に対する 1 つの解決策は、単に別のラッパーの使用を禁止するか、ユーザーが指定した URL の入力をより厳密に制御することです。ただし、クラウドサービスの大規模な使用と「http://」ラッパーの使用により、これは新しい可能性への扉を開きます。
他のサービスとのやり取り
アマゾンウェブサービス (AWS) などのクラウドプロバイダを使用する場合、サーバーメタデータ (実行中のインスタンスの設定または管理に使用できる AWS インスタンスに関するデータ) にアクセスできます。これは、通常、サーバー自体からのみアクセスできる URL を介してアクセスできます。詳細については、こちらをご覧ください。
一般的に使用されているクラウドプロバイダの URL は次のとおりです。
- http://169.254.169.254 AWS、Google Cloud Platform (GCP)、DigitalOcean および Azure
- リンクローカルアドレス (通常、動的ホスト設定プロトコル (DHCP) クライアントとして設定されたインターフェースが DHCP サーバーから応答を受け取らない場合に使用されます。)
- http://192.0.0.192 Oracle Cloud インフラストラクチャ
- Bogon (到達不能なプライベート IP) ローカルネットワークやプライベートネットワークなどの特定の用途のために予約されている IP アドレスであり、パブリックインターネットには表示されません。
- http://100.100.100.200 Alibaba Cloud
- Bogon IP アドレスは、ローカルネットワークやプライベートネットワークなどの特定の用途のために予約されているため、パブリックインターネットには表示されません。
到達不能なプライベート IP を使用している場合でも、SSRF 攻撃の場合、サーバー自体がこれらのリソースへのアクセスへの許可を要求するため、攻撃者はメタデータの内容を読み取ることができます。
たとえば、AWS のようなクラウドサービスは、機密データとシークレットを含むメタデータを返すエンドポイントを提供します。この情報は、AWS アカウントに関連付けられたトークンに関連付けられています。メタデータが取得されれば、トークン情報を AWS コマンドラインインターフェースで使用して、トークンに定義された権限に従って AWS アカウントに関連付けられたリソースにアクセスできるようになります。
対策として、DigitalOcean などの一部のクラウドプロバイダは機密情報を表示しませんが、AWS または GCP の場合は、リクエストに特定のヘッダーを含める必要があります。これにより脆弱性は軽減できますが、常に十分とは言えません。
特に cloud-init ファイルを使用してサーバーをインストールし、サーバーに含まれている機密情報にアクセスされる可能性があります。メタデータを検索する代わりに、公開されている機密ファイルを直接検索できます。
一例は、2021 年の Tenable Capture The Flag コンペティションのチャレンジです。「ハッカーツールズ」チャレンジの目的は、保護された AWS サーバーのメタデータを取得し、特定の HTTP ヘッダーをクエリすることでした。
1 つの Web ページは、提供された Web サイトのスクリーンショットを表示できました。スクリーンショットは、ブラウザによって撮られたもので、ブラウザはページにアクセスし、スクリーンショットを取得してユーザーに表示しました。カスタム JavaScript を使用するカスタムサイトは、ブラウザに必要な要素を含む AWS メタデータへの HTTP リクエストを実行させ、攻撃者に送信することができます。
このケースでは、ブラウザが同じサーバーにインストールされていたために発生しました。つまり、ブラウザにサーバーのメタデータへのアクセスが許可されていました。HackerOne のハッカーオペレーションマネージャーである Ben Sadeghipour と、Verizon Media のシニアバグバウンティオペレーションリーダーである Chris Holt による AppSec California 2020 でのプレゼンテーション「Owning the cloud through SSRF and PDF Generators」によると、これは現在、よくあるシナリオです。
この場合、緩和策としてブロックリストの適用が優れているように思えるかもしれませんが、あらゆるケースを予測して網羅することは非常に困難なので、ブロックリストの使用は推奨されません。
URL http://169.254.169.254 がブロックされている場合でも、以下などが可能になります。
- 169.254.169.254 を指す DNS レコードを使用する
- HTTP リダイレクトを使用する
- たとえば、ブラウザの場合はリダイレクトを使用し、最初のフィルタをバイパスできます
- 標準 IPv4 以外の 表記を使用した IP エンコーディング
- 例 : http://2852039166/ => ドットのない小数
以上の例では、要求に対して返されたコンテンツがユーザーに表示される場合に悪用できますが、返されたコンテンツは常に表示できるとは限りません。以下の例ではブラインドシナリオでも、脆弱性を悪用して深刻な影響を与えることができることがわかります。
ブラインド攻撃
出力が制限されている場合、ファイルの内容または完全な Web ページを取得できないこともあります。ただし、内部サービスにクエリを実行したり、任意のコマンドを実行したりすることは可能です。オプションとして、以下のクエリを実行できます。
- 別のポートのサービス
- ネットワーク上でアクセス可能な他のサーバー
ファイルアップロード機能をテストする際の 1 つの手段は、「127.0.0.1：22」の要求を試すことで、サーバーはサーバーの OpenSSH バナーで応答する可能性があります。
この例は、アプリケーションが異なるステータスコードで応答する場合にも機能します。
- レスポンスコード「HTTP 200 OK」が返される場合 => ポート開
- レスポンスコード「HTTP 500 Internal Server Error」が返される場合 => ポート閉
ブラインド操作 (出力が受信されない) の場合、到達可能なサーバーを探すために内部 IP に侵入したり、別のポートでサーバー自体に接続される可能性があります。
リクエストの応答時間を分析することで、サービスにアクセスできるかどうかを判断できます。ブラインドスキャンでは、応答時間の長さは必ずしもポートの開閉を示すとは限らないため、まず、ネットワークがどのように機能するかを理解する必要があります。
- 応答時間が長い場合は、リクエストがその時点でルーティングまたはブロックされていないことを示している可能性があります。さらに、他のトラフィックからのネットワーク遅延により、応答時間が長くなる可能性があります。
- 応答時間が短い場合は、リクエストがブロックされている可能性があります。
ただし、興味深いサービスを探すためにネットワークを探索するには時間がかかる場合があります。たとえば、JBoss サーバーを識別すると、悪意のあるパッケージをデプロイするために使用できるクエリチェーンが可能になります。
出典 : https://blog.safebuff.com/2016/07/03/SSRF-Tips/
場合によっては、別のサービスの脆弱性を悪用して RCE を実行し、内部ネットワークに足場を仕掛けることも可能です。
たとえば、通常、内部でのみアクセス可能な OpenTSDB サービスの RCE の脆弱性である CVE-2020-35476 を悪用することもできます。
出典 : https://github.com/OpenTSDB/opentsdb/issues/2051
この概念実証は攻撃者がリバースシェルを確立できるシステムのファイルを作成します。
このブログ記事で取り上げる最後の攻撃シナリオでは、「gopher://」ラッパーを使用します。これは、ブラインド SSRF の場合に特に興味深いものです。簡単に説明すると、「gopher://」は分散ドキュメント配信サービスであり、今日のインターネットの代替となるものです。この特定のラッパーはデフォルトではアクティブ化されていませんが、サービスに命令を送信するために特定の URL を作成できます。つまり、このラッパーを使用すると、以下のことができます。
- MySQL/Redis/Zabbix サーバーと対話する
- SMTP 経由でメールを送信する
ただし、このラッパーを使用するには、クエリするサービスを知っている必要もあります。次に、いくつかのシナリオの例を示します。
- MySQL の場合、攻撃者は偽造クエリを作成する前にデータベースの識別子を知っている必要があります。
Redis の場合、送信される URL は、特定の形式 (RESP 配列) でなければなりません。以下は、Redis データベースと対話するためのペイロード gopher の例です。
場合によっては、攻撃を実行するために標的のオペレーティングシステムを知っている必要もあります。
Redis の場合、逆シェルを取得することは可能ですが、これは cron ファイルが変更されているため CentOS ホストでのみ機能します。Redis による変更後、cron ファイルのアクセス許可は「0600」から「0644」に変更されます。これは実行できないことを意味します。
さらに、この手法を使用すると、予期しない文字がファイルに挿入され、cron ファイルのアクセス許可を変更した場合でも、予期しない文字が原因で、Ubuntu および Debian ではこの攻撃は成功しないようです。
Ubuntu や Debian の場合のように、標的のアプリケーションが root として実行されている場合、攻撃者は SSH キーを挿入し、SSH 経由でサーバーにアクセスできる可能性があります。
予防措置と緩和策
SSRF のような脆弱性を回避し、Web アプリケーションとユーザーを保護するためには、以下のベストプラクティスに従う必要があります。
- ユーザーによる入力をサニタイズする。Web アプリケーションが識別され信頼されたアプリケーションにのみ要求を送信できる場合、対策の 1 つとして許可リストを適用することができます。
標的となるアプリケーションが不明な場合：
- フィルタのバイパスを回避するために、ブラウザレベルのリダイレクトを無効にします
- 入力検証を使用して、入力された文字列が期待される形式であることを確認します。
- 可能であれば、受信したデータが有効で期待される形式であるかどうかを確認します。複雑な形式の正規表現は保守が難しく、エラーが発生しやすいため、可能な場合は、利用可能なライブラリを介して検証を行う必要があります。
- 送信先を再確認する。IP アドレスの場合は、パブリック IP に対応していることを確認します。ドメイン名の場合は、DNS レベルで解決できることを確認します。
- URI スキーマを適用する。 「http://」や「https://」など、必要な URI スキーマのみを許可します
- クラウドサービスに堅牢な設定を適用する。 AWS やその他のクラウドベンダーは、SSRF の脆弱性に対する緩和策として、より堅牢な設定を適用するソリューションを提供しています。(例: コンテナが AWS メタデータにアクセスできないようにする)
- 一般的に、ID およびアクセス管理 (IAM) ポリシーの管理に関する堅牢なポリシーを設定し、API からさまざまなサービスとの通信に使用するために生成されたトークンのアクセス許可を必要最小限に制限する必要があります。
- AWS でインスタンスメタデータサービスバージョン 2 (IMDSv2) を使用している場合でも、ヘッドレス Web エンジン (Chromium など) を使用すると回避される可能性があるので、考えられる攻撃ベクトルと解決策を特定する必要があります。
- PDF を生成する場合は、ユーザー入力をフィルタリングして、HTML タグが含まれないようにします。
Tenable.io Web App Scanning を使用して、サーバー側要求偽造の脆弱性を検出する
Tenable.io Web App Scanning は、複数の機能を通じて SSRF の脆弱性を特定します。Web App Scanning には以下のプラグインが含まれています。
- プラグイン 112439 は一般的なSSRFの問題を検出し、CVE-2014-4210、CVE-2020-7616、CVE-2020-29444、CVE-2021-21311 など、一般的に SSRF と関連する脆弱性を特定します。
詳細情報
関連記事
Cybersecurity Snapshot: New Guide Explains How To Assess if Software Is Secure by Design, While NIST Publishes GenAI Risk Framework
May 10, 2024Is the software your company wants to buy securely designed? A new guide outlines how you can find out. Meanwhile, a new NIST framework can help you assess your GenAI systems’ risks. Plus, a survey shows a big disconnect between AI usage (high) and AI governance (low). And MITRE’s breach post-mortem brims with insights and actionable tips. And much more!
Cybersecurity Snapshot: Attackers Pounce on Unpatched Vulns, DBIR Says, as Critical Infrastructure Orgs Benefit from CISA’s Alert Program
May 3, 2024Verizon’s DBIR found that hackers are having a field day exploiting vulnerabilities to gain initial access. Plus, a CISA program is helping critical infrastructure organizations prevent ransomware attacks. In addition, check out what Tenable’s got planned for RSA Conference 2024. And get the latest on the Change Healthcare breach. And much more!
Tenable Bolsters Its Cloud Security Arsenal with Malware Detection
May 1, 2024Tenable Cloud Security is enhancing its capabilities with malware detection. Combined with its cutting-edge, agentless vulnerability-scanning technology, including its ability to detect anomalous behavior, this new capability makes Tenable Cloud Security a much more complete and effective solution. Read on to find out how.
Cybersecurity Snapshot: New Guide Explains How To Assess if Software Is Secure by Design, While NIST Publishes GenAI Risk Framework
May 10, 2024Is the software your company wants to buy securely designed? A new guide outlines how you can find out. Meanwhile, a new NIST framework can help you assess your GenAI systems’ risks. Plus, a survey shows a big disconnect between AI usage (high) and AI governance (low). And MITRE’s breach post-mortem brims with insights and actionable tips. And much more!
CVE-2024-21793, CVE-2024-26026: Proof of Concept Available for F5 BIG-IP Next Central Manager Vulnerabilities
May 9, 2024Researchers disclose multiple vulnerabilities in F5 BIG-IP Next Central Manager and provide proof-of-concept exploit code, which could lead to exposure of hashed passwords.
Cybersecurity Snapshot: Attackers Pounce on Unpatched Vulns, DBIR Says, as Critical Infrastructure Orgs Benefit from CISA’s Alert Program
May 3, 2024Verizon’s DBIR found that hackers are having a field day exploiting vulnerabilities to gain initial access. Plus, a CISA program is helping critical infrastructure organizations prevent ransomware attacks. In addition, check out what Tenable’s got planned for RSA Conference 2024. And get the latest on the Change Healthcare breach. And much more!
- Cloud
- Risk-based Vulnerability Management
- Threat Intelligence
- Threat Management
- Vulnerability Management
- Vulnerability Scanning