APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

TryHackMe Advent of Cyber 2023から2024へ(7) SSRF(サーバサイド・リクエスト・フォージェリ)

自己紹介

こんにちは、エーピーコミュニケーションズiTOC事業部 BzD部 0-WANの田中と申します。
弊社でEDR製品を導入いただいたお客様のインシデント調査を主に担当しております。
その傍らプログラマーとしての経験と知識を生かしてセキュリティに関するウェブアプリケーションを設計構築するなどSOCチームのメンバーとして日々サイバーセキュリティと共に在るエンジニアです。

TryHackMeの「Advent of Cyber2023の復習と2024の予習」をテーマにした連載第7回目の今回は「SSRF(サーバサイド・リクエスト・フォージェリ)」の問題に挑戦してみましょう。

一般的なTryHackMeの使い方は以下にまとめてありますので参照してください。 techblog.ap-com.co.jp

過去のTryHackMe Advent of Cyber 2023に関する記事は以下の通りです。

タスク「SSRF(サーバサイド・リクエスト・フォージェリ)」

tryhackme.com

今回挑戦するタスクはこちらです。

[Day 22]Jingle Your SSRF Bells: A Merry Command & Control Hackventure(SSRF の鐘を鳴らしてみましょう: 楽しいコマンド & コントロールのハックベンチャー)

タスク28 [22日目]SSRF SSRF ベルを鳴らそう: 楽しいコマンド & コントロール ハックベンチャー

[ウォークスルービデオをみるにはここをクリックしてください!]の▲をクリックすると解説動画を表示できますので必要に応じてチェックしてみてください。

このタスクの学習目標は以下の通りです。

  • サーバー側リクエストフォージェリ ( SSRF )を理解する
  • 脆弱性を悪用するために どのような種類のSSRFが使用されるか
  • 脆弱性を悪用するための 前提条件
  • 攻撃の 仕組み
  • 脆弱性を悪用する方法
  • 保護のための緩和策

サーバー側リクエストフォージェリ ( SSRF Server-Side Request Forgery)

サーバー側リクエストフォージェリ ( 以降はSSRF )とは、攻撃者が脆弱性があるWeb アプリケーションを悪用して意図しない外部または内部のリクエストを送信させる攻撃手法です。 攻撃者は対象サーバーを経由して、攻撃者自身では直接アクセスできない他のシステムやサービスに対してリクエストを送信し、情報を盗み取ったり、内部ネットワーク内のシステムを攻撃することが可能になります。

参考:

SSRF攻撃の種類

SSRFには、いくつかの種類やバリエーションがあり、それぞれ異なる方法でサーバーを悪用します。主なSSRFの種類には以下のようなものがあります。

  • 従来型(クラシック)SSRF:従来型のSSRF攻撃は、攻撃者がリクエストのURLを操作し、内部ネットワークや特定の外部サービスにアクセスさせる手法です。内部ネットワーク攻撃クラウドメタデータ攻撃のような典型的な攻撃例があります。

  • Blind SSRF(ブラインドSSRF):ブラインドSSRFは、攻撃者がリクエストの結果を直接確認できないタイプの攻撃です。つまり、サーバーがリクエストを送信しているかどうかは攻撃者には見えないため、攻撃の成功を確認するのが難しいです。しかし、攻撃者はDNSログやDNSレゾルバーへのクエリーやその他の外部チャネルを通じて、攻撃が成功したかを間接的に確認できます。

  • Semi-Blind SSRF(セミブラインドSSRF):セミブラインドSSRFは、ブラインドSSRFとクラシックSSRFの中間に位置します。リクエストの結果は直接は見えないものの、何らかのフィードバックがサーバーから返される場合があります。例えば、サーバーのエラーメッセージやレスポンスのタイムアウトによって、攻撃が成功したかどうかが推測できることがあります。

これらのSSRF攻撃のバリエーションは、いずれもリクエスト先の操作によりサーバの持つ権限やネットワークアクセスを悪用するもので、対策を講じることが重要です。

悪用するための前提条件

SSRF攻撃を成功させるためには、攻撃者が以下のような特定の前提条件を満たす必要があります。

  • ターゲットのサーバ(被害サーバ)が外部へのHTTPリクエストやAPIコールなどを行う機能を持っている
  • ユーザからの入力値がサーバによって適切にバリデーション(検証)されていない
  • 外部からは直接アクセスできない内部ネットワークやローカルのサービスにアクセスできるネットワーク上に配置されている
  • サーバがリクエストのリダイレクトを無制限に許可していたりプロキシ経由のリクエストを許可している
  • クラウド環境でメタデータAPIへのアクセスが制限されていなかったり内部サービスやAPIが認証を要せずにアクセスできる
  • HTTP以外のプロトコル(例:file[://], ftp[://], gopher[://]など)が利用可能
  • サーバに対する過剰な権限やリソースへのアクセス権限がある

SSRF攻撃の仕組み

SSRF攻撃は以下のような流れで行われます。

  1. 脆弱な入力の特定 攻撃者は、サーバ側のリクエストをトリガーするために操作できるアプリケーション内の入力フィールド(WebフォームのURL パラメータ、 APIエンドポイント、リファラーなどのリクエストパラメータ入力など)を見つけます。

  2. 入力の操作 悪意のあるURL(内部サーバ、ループバックアドレス、攻撃者の制御下にある外部サーバを指すURL)またはその他のペイロードを入力します。

  3. 許可されていないリソースの要求 アプリケーションサーバは、悪意のある入力を認識しないまま指定されたURLまたはリソース(内部リソース、機密サービス、外部システム)に要求を行います。

  4. 応答の悪用 アプリケーションサーバは、内部サーバ データ、資格情報、システム資格情報、またはさらなる悪用への経路などの貴重な情報を返してしまいます。

SSRFはどのように機能しますか?

SSRF攻撃体験

攻撃者(McGreedy)を撃退するために、彼の脆弱性があるアプリケーションサーバ(C2サーバ)の管理画面にアクセスしてみましょう。

ターゲットマシンと自分のマシンを起動する

まずC2サーバの名前解決できるようにhostsファイルにドメイン情報を登録します。 Linuxの場合は/etc/hostsにC2サーバのIPアドレスとドメイン名を書きこみます。

Linuxの場合/etc/hostsにC2サーバの行を追加します

C2サーバの画面が表示されます

表示されたログイン画面の下にある「Accessing through API」をクリックします。 説明にはgetClientData.phpというエンドポイントにurlというパラメータを指定してアクセスするとファイルを表示できると書かれています。

APIの説明が書かれています

ここでurlに内部リソースであるfile:////var/www/html/index.php を指定してみると以下のようにファイルを表示できてしまいました。(注:////は//のエスケープ表現)

index.phpの内容が表示されます

設定ファイルに何かありそうなのでこれもSSRF攻撃で表示させてみましょう。

見てはいけないものが…

入手したログイン情報を使ってC2サーバの管理画面に入りましょう。

C2サーバのログイン画面からログインしましょう

C2サーバにログインできました

緩和策

SSRF攻撃を防ぐために、次の緩和策が推奨されます。

  • 悪意のある入力を防ぐために、厳格な入力検証とサニタイズを実装する
  • 許可リストを使用して、アプリケーションがアクセスできるドメインと IP を制御する
  • ネットワーク セグメンテーションを適用して、許可されたリソースへのリクエストを制限する
  • 最小権限の原則に従い、システム操作に必要な最小限の権限を付与する

問題に挑戦

では実際に問題を解いてみましょう。

問題1.SSRFは、攻撃者がサーバーを騙して外部リソースのみをロードさせるプロセスですか (賛成/反対)?

yeaか? nayか?

問題2.C2サーバのバージョンは何ですか?

管理画面のどこかにあります。

問題3.C2管理画面にアクセスするためのユーザー名は何ですか?

設定ファイルにありましたね。

問題4.C2管理画面にアクセスした後のフラグ値は何ですか?

管理画面のどこかにあります。

問題5.McSkidyのコンピュータからデータ流出を阻止した後のフラグ値は何ですか?

攻撃者を追い出そう!

まとめ

いかがでしたでしょうか? 「さーばさいど・りくえすと・ふぉーじぇり」 不思議な響きの言葉で初めて聞いた方もいらっしゃったかもしれませんね。 「ふぉーじぇり」とは偽造や詐欺を意味する言葉で、主に不正行為や偽造行為を指すそうです。 サーバをだまして不正行為を行う攻撃とご理解いただければよろしいかと存じます。

今回はSSRF(サーバサイド・リクエスト・フォージェリ)のテーマのもと以下について学ぶタスクをご紹介しました。

  • サーバー側リクエストフォージェリ ( SSRF )を理解する
  • 脆弱性を悪用するために どのような種類のSSRFが使用されるか
  • 脆弱性を悪用するための 前提条件
  • 攻撃の 仕組み
  • 脆弱性を悪用する方法
  • 保護のための緩和策

最後まで読んでいただきありがとうございました。次回もお楽しみに。

0-WANについて

私たち0-WANは、ゼロトラスト製品を中心とした、マルチベンダーでのご提案で、お客様の経営課題解決を支援しております。 ゼロトラストってどうやるの?製品を導入したけれど使いこなせていない気がする等々、どんな内容でも支援いたします。 お気軽にご相談ください。

問い合わせ先、0-WANについてはこちら。 www.ap-com.co.jp

一緒に働いて頂ける仲間も募集しています

今までの経験を活かして、私たちと一緒にゼロトラスト分野で活躍しませんか? www.ap-com.co.jp