Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

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 つの異なる脆弱性です。

次の例を考えてみましょう。

How to identify Server Side Request Forgery (SSRF) vulnerabilities using Tenable

GET“ returnUrl” パラメータがユーザーにより指定された場合、Web サイトは指定された値にリダイレクトします。したがって、この場合、攻撃者から URL “http://domain.tld/?returnUrl=https://evil.org“ が提供されると、ブラウザは HTTP リクエストを送信し、ユーザーを “https://evil[.]org” にリダイレクトします。

How to identify Server Side Request Forgery (SSRF) vulnerabilities using Tenable

上記の例では、リダイレクトはサーバー自体ではなくクライアント側で実行されます。したがって、ブラウザから直接社内サーバーにアクセスしようとするので、内部リソースにアクセスすることはできません。これは、パブリック IP アドレスがない場合は技術的に不可能です。

次の例を見てみましょう。

How to identify Server Side Request Forgery (SSRF) vulnerabilities using Tenable

GET “url” パラメータが攻撃者により指定された場合、curl リクエストが行われ、結果が表示されます。したがって、任意の URL を渡すと、コードがページのコンテンツを取得して表示します。

How to identify Server Side Request Forgery (SSRF) vulnerabilities using Tenable

前の場合と同様に、HTTP リクエストがリソースに対して行われます。ただし、この場合、要求はサーバー自体から送信され (サーバー側の要求)、ブラウザからは送信されません (クライアント側の要求)。

How to identify Server Side Request Forgery (SSRF) vulnerabilities using Tenable

この特定のケースでは、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 攻撃の標的になっています。次の表は、デフォルトでファイルラッパーを有効にするラッパーを示しています。

How to identify Server Side Request Forgery (SSRF) vulnerabilities using Tenable

出典: https://cheatsheetseries.owasp.org/assets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet_SSRF_Bible.pdf

前述のケースの例として、次の脆弱なアプリケーションを見てみましょう。予想される URL の代わりに「file:///etc/passwd」を使用して、ファイルラッパーを使用すると passwd ファイルを取得できます。

How to identify Server Side Request Forgery (SSRF) vulnerabilities using Tenable

この脆弱性に対する 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 アカウントに関連付けられたリソースにアクセスできます。

How to identify Server Side Request Forgery (SSRF) vulnerabilities using Tenable

これを防ぐために、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 エンコーディング

以上の例では、要求に対して返されたコンテンツがユーザーに表示される場合に悪用できますが、返されたコンテンツは常に表示できるとは限りません。以下の例ではブラインドシナリオでも、脆弱性を悪用して深刻な影響を与えることができることがわかります。

ブラインド攻撃

出力が制限されている場合、ファイルの内容または完全な Web ページを取得できないこともあります。ただし、内部サービスにクエリを実行したり、任意のコマンドを実行したりすることは可能です。オプションとして、以下のクエリを実行できます。

  • 別のポートのサービス
  • ネットワーク上でアクセス可能な他のサーバー

ファイルアップロード機能をテストする際の 1 つの手段は、「127.0.0.1:22」の要求を試すことで、サーバーはサーバーの OpenSSH バナーで応答する可能性があります。

How to identify Server Side Request Forgery (SSRF) vulnerabilities using Tenable

この例は、アプリケーションが異なるステータスコードで応答する場合にも機能します。

  • レスポンスコード「HTTP 200 OK」が返される場合  => ポート開
  • レスポンスコード「HTTP 500 Internal Server Error」が返される場合 => ポート閉

ブラインド操作 (出力が受信されない) の場合、到達可能なサーバーを探すために内部 IP に侵入したり、別のポートでサーバー自体に接続される可能性があります。

リクエストの応答時間を分析することで、サービスにアクセスできるかどうかを判断できます。ブラインドスキャンでは、応答時間の長さは必ずしもポートの開閉を示すとは限らないため、まず、ネットワークがどのように機能するかを理解する必要があります。

  • 応答時間が長い場合は、リクエストがその時点でルーティングまたはブロックされていないことを示している可能性があります。さらに、他のトラフィックからのネットワーク遅延により、応答時間が長くなる可能性があります。
  • 応答時間が短い場合は、リクエストがブロックされている可能性があります。

ただし、興味深いサービスを探すためにネットワークを探索するには時間がかかる場合があります。たとえば、JBoss サーバーを識別すると、悪意のあるパッケージをデプロイするために使用できるクエリチェーンが可能になります。

How to identify Server Side Request Forgery (SSRF) vulnerabilities using Tenable

出典 : https://blog.safebuff.com/2016/07/03/SSRF-Tips/

場合によっては、別のサービスの脆弱性を悪用して RCE を実行し、内部ネットワークに足場を確立することも可能です。

たとえば、通常、内部でのみアクセス可能な OpenTSDB サービスの RCE の脆弱性である CVE-2020-35476 を悪用することもできます。

How to identify Server Side Request Forgery (SSRF) vulnerabilities using Tenable

出典 : https://github.com/OpenTSDB/opentsdb/issues/2051

この概念実証は攻撃者がリバースシェルを確立できるシステムのファイルを作成します。

このブログ記事で取り上げる最後の攻撃シナリオでは、「gopher://」ラッパーを使用します。これは、ブラインド SSRF の場合に特に興味深いものです。簡単に説明すると、「gopher://」は分散ドキュメント配信サービスであり、今日のインターネットの代替となるものです。この特定のラッパーはデフォルトではアクティブ化されていませんが、サービスに命令を送信するために特定の URL を作成できます。つまり、このラッパーを使用すると、以下のことができます。

  • MySQL/Redis/Zabbix サーバーと対話する
  • SMTP 経由でメールを送信する

ただし、このラッパーを使用するには、クエリするサービスを知っている必要もあります。次に、いくつかのシナリオの例を示します。

  • MySQL の場合、攻撃者は偽造クエリを作成する前にデータベースの識別子を知っている必要があります。

Redis の場合、送信される URL は、特定の形式 (RESP 配列) でなければなりません。以下は、Redis データベースと対話するためのペイロード gopher の例です。

How to identify Server Side Request Forgery (SSRF) vulnerabilities using Tenable

場合によっては、攻撃を実行するために標的のオペレーティングシステムを知っている必要もあります。

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 には以下のプラグインが含まれています。

How to identify Server Side Request Forgery (SSRF) vulnerabilities using Tenable

詳細情報

関連記事

最新のエクスプロイトに対して脆弱ですか?

下にメールアドレスをご記入ください。最新の情報が確認できる Cyber Exposure アラートがインボックスに送信されます。

Tenable.io を 30 日間無料でお試しください

最新のクラウドベースの脆弱性管理プラットフォームの全機能にアクセスし、これまでにない精度で全ての資産を確認し、追跡しましょう。 今すぐサインアップしてください。

Tenable.io を購入する

最新のクラウドベースの脆弱性管理プラットフォームの全機能にアクセスし、これまでにない精度で全ての資産を確認し、追跡しましょう。 年間サブスクリプションをご購入ください。

65 資産

サブスクリプションオプションを選択してください。

今すぐ購入

Nessus Professionalを無料で試す

7日間無料

Nessus® は、最も包括的な脆弱性スキャナーです。Nessus Professional は脆弱性のスキャンプロセスを自動化し、コンプライアンスサイクルを短縮し、お客様の IT チームが専念して活動できるようにします。

Nessus Professionalを購入する

Nessus® は、最も包括的な脆弱性スキャナーです。Nessus Professional は脆弱性のスキャンプロセスを自動化し、コンプライアンスサイクルを短縮し、お客様の IT チームが専念して活動できるようにします。

複数年ライセンスをご購入いただくと割引が適用されます。拡張サポートを追加すると、24 時間x365 日、電話、コミュニティ、チャットサポートにアクセスできます。

ライセンスをお選びください

複数年ライセンスをご購入いただくと割引が適用されます。

サポートとトレーニングを追加

Tenable.io Web Application Scanningを試す

30 日間無料

Tenable.ioプラットフォームの一部として最新のアプリケーション用に設計された、最新のWebアプリケーションのスキャンサービスの全機能にアクセス可能です。手作業による労力や重大なWebアプリケーションの中断なしに、脆弱性のオンラインポートフォリオを安全に高精度でスキャンします。 今すぐサインアップしてください。

Tenable.io Web Application Scanningを購入する

最新のクラウドベースの脆弱性管理プラットフォームの全機能にアクセスし、これまでにない精度で全ての資産を確認し、追跡しましょう。 年間サブスクリプションをご購入ください。

5 FQDNs

3,578ドル

今すぐ購入する

Tenable.io Container Securityを試す

30 日間無料

脆弱性管理プラットフォームに統合された唯一のコンテナセキュリティ製品の全機能にアクセス可能です。コンテナイメージの脆弱性、マルウェア、ポリシー違反を監視継続的インテグレーション/継続的デリバリー(CI / CD)システムと統合し、DevOps プラクティス、セキュリティ強化、および企業のポリシーコンプライアンスをサポート

Tenable.io Container Securityを購入する

Tenable.ioのContainer Securityは、ビルドプロセスと統合することにより、コンテナイメージのセキュリティ(脆弱性、マルウェア、ポリシー違反など)を可視化し、シームレスかつ安全なDevOpsプロセスを実現します。

Tenable Lumin を試用する

30 日間無料

Tenable Lumin を使用して、Cyber Exposure を可視化および調査し、リスクの軽減を追跡し、競合他社に対してベンチマークしましょう。

Tenable Lumin を購入する

Tenableの担当者にお問い合わせいただき、組織全体に対するインサイトを得て、サイバーリスクを管理する上で Lumin がいかに役立つかについて、Tenable の営業担当者までお問い合わせください。