A10:2021 OWASP – SSRF

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

OWASPで略されるSSRFは、熟練したハッカーが既に存在するサーバーの脆弱性を利用して攻撃を行うサイバー攻撃の一種です。ハッカーの意図により、攻撃者はSSRFを使い、重要なサーバーデータ（保存中または転送中のもの）に不正なコードやリンクを挿入して改ざんする場合があります。

‍

SSRFの影響

長期間放置すると、SSRF攻撃は想定以上の問題を引き起こす可能性があります。主な影響は以下の通りです：

• 攻撃者は侵害されたサーバーをIPスキャナーやポートとして利用し、フロントエンドやバックエンドのシステムから情報を収集できる
• 対象サーバでGopherなどの内部プロトコルが有効なら、ハッカーは偵察のための経路を容易に構築できる
• SSRF攻撃が成功すると、リバースプロキシ背後の隠れたIPアドレスを把握できる
• XCEの可能性を作ることで、マルウェア、ウイルス、ランサムウェアなどの悪意あるプログラムの侵入の温床となる

このように、SSRFは被害者に大きな問題を引き起こす可能性があります。 

‍

SSRFとOWASP Top 10 2021

この脆弱性が成功すると、サーバーや関連システムの悪用、ホスト認証やIPホワイトリストの回避、サーバ上のファイルアクセス、ユーザーデータの流出、認証済みの相互作用、サーバ側APIへのアクセスなど、多岐にわたる問題が発生します。

これを踏まえると、なぜSSRFがOWASP Top 10に含まれているのかも不思議ではありません。最初のリストから最新のものまで、SSRFは常に潜在的なセキュリティ脅威として定義されてきましたが、今回は独自のカテゴリーが設けられました。

報告されたCVEの総数に基づき、SSRFはOWASPリストで10位にランクされました。Wallarmは既にOWASP Top 10 2021 予測で同様の見解を示しており、膨大なデータベースと詳細な分析により、SSRF脆弱性を重大に受け止める必要性を強調しています。 

OWASP Top 10 2022の予測が気になる場合は、こちらをご覧ください。

‍

実際のSSRF攻撃例

SSRFの仕組みとその影響を理解する最善の方法は、攻撃例に目を通すことです。以下にいくつか例を示します：

例 1 - セグメント化されていないネットワーク構成は、攻撃者が内部サーバーのポートが開いているかを確認する好機となります。ポートが開いていれば、容易にSSRF接続を試みることができます。

例 2 - 'http://localhost:28017/' や 'file:///etc/passwd' のようなURLを用いることで、攻撃者は内部サービスやローカルファイルにアクセスし、機密情報を盗む可能性があります。

例 3 - 'http://169.254.169.254/' のようにメタデータを保存しているクラウドソリューションは、攻撃者が容易にアクセスでき、重要な情報に触れる足掛かりとなります。

例 4 - レスポンスを改変することで、攻撃者はDoSやRCEの足掛かりを作ることが可能です。

SSRF攻撃の例

攻撃者は、単純なGETリクエストを用いることでSSRF攻撃を成功させることができます。また、エンドポイントやサーバーのフォルダ構造を推測できれば、ローカルシステムの資源にアクセスしたりリモートコード実行を行ったりすることも可能です。以下に例を示します。

以下のGETリクエストを確認し、なぜSSRF攻撃の脆弱性があるのかを考えてみてください。

http:/localhost/?link=http://example.arm.com/images/header.gif

ご不明な場合は、このリクエストを実行するPHPコードを詳しくご覧ください。

<?php

//verify if the variable ‘link’ has a value

if (isset($_GET['link'])) {
    $link = $_GET['link'];
    $img = fopen($link, 'rb'); // Forwards a ‘open’ request for image/binary-file; no checks.
    header("Content-Type: image/png");  // Sends back the response-header directly.
    fpassthru($img); // Returns the image contents.
}

?>

このコードを読むと、GET入力の検証が行われていないことが理解でき、通常のペイロードも悪意あるペイロードも渡すことが可能となると分かります。

具体的には、上記の例で攻撃者は『link』変数を完全に制御できるか確認するため、短時間のランダムなGETリクエストを実行し、サーバの応答により脆弱性が確認されました。

その後、攻撃者は任意のGETリクエストを続け、より重要な資源へアクセスすることができます。以下はその一例です：

GET /?url=http://example.arm.com/server-status HTTP/1.1
Host: http://example.arm.com

このリクエストでは、mod_statusが有効な状態で送信され、Apache HTTPサーバはサーバ性能やアクティブな接続情報を漏洩し、攻撃者が対象のエコシステムに関する追加情報を得る手助けとなります。

また、攻撃者はSSRFを利用し、通常はアクセスできない内部サーバ資源に侵入するなど、さらに深刻な攻撃も試みることができます。ポートスキャンの実施や、クラウドサービスのインスタンスメタデータを取得するなど、この脆弱性を自由に悪用可能です。以下に例を示します：

GET /?link=http://169.253.167.244/latest/meta-data/ HTTP/1.1
Host: http://example.arm.com

ウェブ上のサーバ資源だけでなく、オフラインの物理サーバ資源、つまりシステムのローカルファイルも、SSRF攻撃が成功すれば危険にさらされます。http:// や https:// の他に、file:///といったURLスキーマを利用することで、ネットワークのエンドポイントやサーバ自体の安全でないローカルデータにアクセス可能です。以下に例を示します：

GET /?link=file:///etc/passwd HTTP/1.1
Host: http://example.arm.com

攻撃者の成功や悪用の程度は、アプリが攻撃者の操作をどこまで許容するかによって異なり、中にはcURLリクエストを試みるハッカーもいます。これにより、dict://などさらに多くのURLスキーマを利用し、被害システムを通じて任意のポート経由でリクエストを送ることが可能となり、攻撃者がカスタマイズしたデータが含まれる場合があります。 

GET /?link=dict://arm.com:11211/stat HTTP/1.1
Host: http://example.arm.com

上記のリクエストにより、攻撃者は11211（Memcachedのデフォルトポート）など公開されていないポートやその他の資源に迅速にアクセスでき、状況はさらに危険な方向に進展する恐れがあります。

‍

SSRF脆弱性の主な種類

サーバ側環境には、サーバ本体およびその内部コンポーネントと、サーバとバックエンドシステムという2側面が存在します。この脆弱性が影響する側により、2種類に分類されます：

サーバに対する攻撃

いわゆる基本的なSSRFで、攻撃結果が直接攻撃者に表示されるものです。サーバが攻撃者指定のURLにアクセスし、情報やデータ、レスポンスを取得して返す仕組みです。

多くの場合、攻撃者は実際のURLを『localhost』やIP 127.0.0.1に置き換え、重要なデータへ直結する経路を特定します。このタイプの攻撃は一般的で、適切に調査されれば攻撃者の特定に繋がる可能性があります。

バックエンドシステムに対する攻撃

この場合、攻撃者はサーバに直接アクセスせず、サーバのバックエンドシステムを制御下に置いて、重要なレスポンスや情報を取得します。そのため、ブラインドSSRFとも呼ばれます。

サーバが侵害されたバックエンドシステムにデータを送信すると、攻撃者はそれを取得し、自由に利用できます。多くのバックエンドシステムはセキュリティが弱いため、攻撃者は手間をかけず悪用することが可能です。 

‍

基本的SSRF攻撃とブラインドSSRF攻撃の比較

前述の例では、攻撃者はリクエスト送信時にサーバの抜け穴を利用し、その結果を見ることができました。こうした非ブラインド（基本的）なSSRF攻撃では、攻撃者はサーバから出力やフィードバックを受け取り、攻撃の成功か否かを判断できます。 

さらに理解を深めるために、別の例をご覧ください：

http: //localhost/ ?link=http: //example.arm.com/ images/ footer_bg.gif

この例では、サーバが『footer_bg.gif』ファイルを返せば攻撃は成功し、返さなければ失敗となります。

一方、ブラインドSSRF攻撃はその名の通り、成功しても失敗してもデータが返りません。ここでの焦点は、データの取得ではなく不正な操作の実行にあります。 

ユーザー権限の変更、重要な業務データの改変、サーバパラメータの変更など、ブラインド攻撃はあらゆる対象を狙い得ます。たとえば、以下をご覧ください：

http: //localhost/ ?link=http://external_site.com/ 1GB_gif.gif

この例では、攻撃者が外部から1GB近くの大容量GIFファイルを繰り返し取得し、サーバの処理を遅延させたりクラッシュさせたりしようと試みます。

‍

SSRFによる被害の種類

正直なところ、被害の程度はシステム構成、APIのセキュリティ対策、攻撃の深刻度に依存するため一概には言えません。しかし、SSRF攻撃が成功すれば、以下のような典型的な危険性が伴うことは確かです：

• ‍リモートコード実行 (RCE)

これはSSRF攻撃成功時に発生する可能性がある危険で、多くの現代アプリは多数のHTTPリクエストを使用しているため、不適切な管理はRCEの機会を与えます。特にRedisなどのコアサーバが狙われ、貴重な情報が攻撃者に渡る恐れがあります。

• ‍ポートスキャンまたはクロスサイトポート攻撃 (XSPA)

SSRF攻撃では必ずしもレスポンスが攻撃者に返る必要はなく、オープンポートを利用してアプリサーバのネットワークスキャンを迅速に実施できます。これをXSPAと呼びます。

また、ネットワーク接続のタイムアウトは元の設定を維持し、ポートやホストの状態に左右されません。熟練の攻撃者はこの特性を利用し、適切なリクエストで将来の接続タイミングを操作することが可能です。 

リクエストが受理されると、攻撃者は対象ネットワーク上のサービス情報を記録し、プロトコル・スマグリング攻撃を実施できるようになります。

• ‍データ漏洩

攻撃が成功すると、SSRF脆弱性により攻撃者はサーバおよびバックエンドシステム内のデータに、管理者並みの権限でアクセスできるようになります。実際、Amazon EC2が被害に遭い、さまざまなインスタンスの認証情報が流出した事例があります。 

また、漏洩するデータ量はIAMロールに与えられた権限に左右され、過剰な権限がある場合、顧客アカウント全体の情報が危険にさらされる可能性があります。

• ‍偵察活動

企業は外部脅威の範囲を限定するため、公開サーバの利用を制限することがあります。SSRFはこれらのサーバを利用して内部ネットワーク上の情報を収集し、他のサーバの監視に利用することが可能です。これが偵察活動であり、一度の成功で内部全体が危険に晒される恐れがあります。

• ‍サービス拒否攻撃 (DoS)

ご存知の通り、DoS攻撃は正当なユーザが特定の資源にアクセスするのを妨げるものです。SSRFでは対象はサーバとなり、大量のリクエストにより内部サーバが本来より低い帯域幅で設計されているため、攻撃者が大量のトラフィックを送り込むとDoS攻撃に繋がります。

しかし、熟練の攻撃者は内部サーバに大量のトラフィックを送り込み、サービス拒否状態を引き起こす可能性があります。

SSRF脆弱性の見極め方

早期発見は、SSRF対策成功の第一歩です。注意深ければ脆弱性を見抜くのは難しくありません。以下の対策を採用するとよいでしょう：

• リクエスト内の部分URLに注目する

アプリはリクエスト転送時にURLやホスト情報の一部を保持することが一般的です。サーバで受け取る際に完全なURLに組み込まれるため、GET形式のフォーム入力やURLの存在を注意深く確認し、SSRF攻撃の兆候を探す必要があります。

• データ形式に注意する

データがリッチな形式で送信されると、解析に必要なURLが含まれる場合があります。例えばXMLは構造化されたデータを扱うため、XXE攻撃やSSRFの足掛かりとなりえます。URL内でデータ形式を利用している場合は、十分なSSRF対策を講じる必要があります。

• Refererヘッダーの存在

サーバ訪問者を解析するソフトを利用していれば、リクエスト内のRefererヘッダーが記録されるのは当然です。これは受信リンクの追跡に重要な情報となります。

また、解析ソフトが第三者のURLにアクセスし、その情報がRefererヘッダーに現れる場合もあり、こうした場合はSSRF攻撃が起こりやすい環境と言えます。

‍

攻撃の緩和と防止

SSRFは適切な対策がなければ重大な被害をもたらす恐れがあります。したがって、最適なSSRF対策技術を学ぶことが重要です。対策は最新かつ効果的で、SSRF攻撃を無効にできるようにしておく必要があります。以下に、攻撃の可能性を低減するための主要な4つの方法を紹介します：

• レスポンス処理

サーバまたはクライアントのレスポンスが、不正なユーザにアクセスされないように、適切なリクエスト・レスポンス処理を実施することが重要です。例えば、不審なレスポンスや生のレスポンスボディは決してそのまま扱ってはいけません。

• ホワイトリストとDNS解決

ブラックリストの代わりに、IPやDNS名のホワイトリストを利用する方法は、SSRF対策として有効です。これにより、アプリがアクセスできるIPアドレスやDNS名を制限できます。また、ユーザー入力の認証を適切に行い、非ルーティング可能なプライベートIPへのアクセスを禁止する対策も重要です。

• 不要なURLスキーマの無効化

リクエスト開始にはHTTPSまたはHTTPのURLスキーマを使用し、その他の不要なスキーマは排除することで、SSRF攻撃の範囲を狭めることが可能です。使用するスキーマが多いほど、攻撃者にとって攻撃のチャンスが増えます。

• 内部サービスへの適切なアクセス制限

MongoDB、Memcached、Redisなどのサービスを利用している場合は、強固な認証を実施することが不可欠です。これらのサービスはデフォルトで認証が無いため、攻撃者はSSRF攻撃の足掛かりとする可能性があります。しっかりと認証対策を講じることで安全に利用できます。

WallarmがSSRF脆弱性から守る

SSRFは大きな混乱を引き起こす恐れがありますが、適切な支援と迅速な対応により早期対策が可能です。Wallarmは有名なAppSecプラットフォームとして、SSRFを防ぐ幅広いセキュリティツールを提供しています。

• Cloud WAF

APIやサーバレスワークロード、サーバ上に保存されたアプリなどの資源を守るCloud WAFは、わずかなDNS変更で動作します。自動調整とほぼゼロの誤検知により、SSRF関連の脅威から確実に守ります。自動インシデント分析を初めて搭載した点も評価に値します。

• API脅威防止

WallarmのAPI脅威防止機能を利用すれば、サーバ側APIをSSRFから守ることが容易になります。主要なAPI全般に対応し、IBM Cloud、AWS、Service Meshなど、さまざまな環境で利用可能です。

SSRFだけでなく、その他多くのサイバー脆弱性（OWASP Top 10を含む）も初期段階で対処可能です。