【SSRF編】サーバに意図しない接続をさせる攻撃と守り方｜CTF思考フレームワーク #28

こんにちは、アンペンです！

前回までは「ネットワーク経路の安全」を扱ってきました。ここからは『サーバ自身の脆弱性』に入っていきます。

最初は#11でも触れたSSRFを、サーバ・クラウド視点で改めて深く見ていきます。サーバを内側の代理人にしてしまう攻撃と守り方を学びましょう。

SSRFって#11でやったやつだよね？また同じ話？

#11は『Webアプリ視点』。今回はサーバ・クラウド側から、内部APIやクラウドメタデータをどう奪われるかを深掘りしていくよ。

SSRFは#11のWeb編でも登場しました。『また同じ話？』と思うかもしれませんが、今回は視点が違います。#11は“Webアプリの便利機能が悪用される”という入口の話。今回はその先——サーバやクラウドの内側で、いったい何が奪われるのか、という“被害の広がり”が主役です。とくにクラウド時代のSSRFは、たった一つの穴が、ストレージ全体の流出につながることもある。その連鎖を見ていきましょう。

SSRFは「サーバを代理人にする」攻撃

多くのサーバアプリには、利用者の入力でURLを受け取り、その先のリソースを取りに行く機能があります(プレビュー・OAuth・Webhook・PDF生成など)。SSRFはこの機能を悪用して、サーバが内部や特殊IPアドレスへリクエストを送る状態を作り出します。

クラウド環境では、 169.254.169.254 のようなメタデータエンドポイント(IMDS)から認証情報まで奪われると、IAMロール経由でS3やデータベースまで連鎖する『被害連鎖型』のSSRFになります。

ここがクラウドSSRFの一番こわいところ。169.254.169.254 という内部アドレスに尋ねると、そのサーバが持つ“一時的な鍵束（クレデンシャル）”が返ってくることがあります。攻撃者はSSRFでサーバにこの鍵束を取ってこさせ、横取りする。するとサーバが本来持っていた権限——たとえばS3（ストレージ）やデータベースへのアクセス——を、そっくり乗っ取れてしまう。『URLを1つ取りに行かせただけ』が、クラウド資産全体の流出へ。これが“被害連鎖”です。

おさらいすると、SSRFが強力なのは『サーバは内側の住人』だから。外部の攻撃者は内部ネットワークに入れませんが、サーバは内部APIにも管理画面にも堂々とアクセスできます。その“内側の住人”を操って使い走りにできる——というのが基本でした。そしてクラウドでは、この内側に“とびきり危険なご近所さん”がいます。それが、次に出てくるメタデータエンドポイントです。

図解：通常URL取得 vs SSRFでメタデータ取得

外部Webサイトを取りに行く通常の使い方と、内部・メタデータ宛にすり替えられた場合を並べると、影響の大きさが見えてきます。

ここで朗報。この危険なメタデータには、IMDSv2という“鍵付き”の新しい版があります。v1は「尋ねれば誰でも答えてもらえる」状態でしたが、v2は「先に合言葉（トークン）を取ってからでないと答えない」方式。単純なSSRF（ただURLを取りに行かせるだけ）では、この合言葉の取得が難しいので、奪取がぐっと困難になります。クラウドを使うなら、まずv2を“強制”してv1を止める——これが現代の必須対策です。

サーバ視点で見たSSRF代表3シナリオ

サーバ視点のSSRFは、大きく3シナリオ。『外から見えない内部API・管理画面を叩く』『クラウドの鍵束（メタデータ）を奪う』『応答が返らなくても副作用で成功を確かめる（Blind SSRF）』。とくに3つ目のBlindは、画面に何も表示されないので“起きていることに気づきにくい”のが厄介です。だから守る側は、見える反応だけでなく、裏の通信の異常まで見張る必要があります。

よくある利用経路

• 内部API/管理画面の奪取：本番ネット内のみで使う内部URLを、外部からSSRF経由で叩く
• クラウドメタデータの取得：IMDSから一時クレデンシャルを取り、IAM権限の範囲でS3やDBに到達する
• Blind SSRF：応答が返らなくても、副作用(タイマー・DNSルックアップ・外部Webhook)で実行確認や情報送出

近年のクラウドインシデントでは、SSRFをきっかけにIAM権限を奪取され、ストレージ全体が漏洩する事例が複数報告されています。守る側は『SSRFが踏み台になる前提』で、その先で起きうる被害も含めて設計する必要があります。

実際、大きく報道されたクラウド情報漏洩の中には、「SSRFでメタデータの鍵を奪われ→その鍵でストレージに到達→大量の個人データが流出」という筋書きのものがあります。最初のきっかけは、ほんの小さなURL取得機能。それが鍵束の奪取、権限の悪用、データ流出……とドミノ倒しに広がっていきます。だから守る側は『SSRFは起こりうる』と認めたうえで、“起きた後にどこまで被害が及ぶか”まで設計に織り込むことが大切なんです。

練習は、自分のコードで『利用者が指定したURLを、サーバが取りに行く場所』を洗い出すことです。そこに行き先のチェックが入っているか、クラウドならIMDSv2が強制されているか。攻撃を仕掛けるのではなく“点検”ですね。もちろん、他人のクラウドのメタデータにアクセスするのは厳禁。自分のアカウント・自分のラボの中だけで確かめましょう。

CTFでやってみよう：URL受け取り処理を点検する

守りで“最後の砦”になるのが、IAM（クラウドの権限）の最小化です。

ホワイトリストやIMDSv2で防げるなら、IAMの権限まで絞る必要あるの？

それが大事なんだ。どんなに入口を固めても、“絶対に破られない”とは言い切れない。だから『万一SSRFで鍵束を奪われても、その鍵でできることを最小限にしておく』——これが効くんだよ。たとえばサーバに、本当に必要な1つのバケットへの読み取り権限しか与えていなければ、鍵を盗まれても被害はそこ止まり。入口を守る（予防）と、破られた後の被害を小さくする（限定）。この二段構えが、クラウドの鉄則だよ。

守る側なら、「行き先制限+IMDSv2+出口FW」

SSRFの守りは、「アプリ側の行き先制限」「クラウド側のIMDSv2強制」「ネットワーク側の出口制御」の3層で多層化します。

SSRFって、アプリだけでなくクラウド設計まで巻き込む話なんだね。

そう。最小権限IAM+IMDSv2+出口FWの3点が揃うと、SSRFが起きても被害が広がりにくくなるよ。

ここまでをひと言で言うと、クラウドSSRFの守りは『入口を絞り、破られても被害を限定する』。URLのホワイトリストとIMDSv2で予防し、最小権限IAMと出口FWで“万一の連鎖”を断つ。SSRFは単体の脆弱性に見えて、実は“被害がどこまで広がる設計か”を問う、総合力の試される攻撃なんです。

まとめ：SSRFは『被害連鎖』を前提に設計する

今日の持ち帰りは『URLを1つ取りに行かせるだけ、を侮らない』です。クラウドでは、その小さな機能がストレージ全体の流出へつながりえます。行き先を絞り、メタデータはv2で守り、鍵束を奪われても被害が広がらない権限設計にしておく。“起きる前提で、連鎖を断つ”——それが、クラウド時代のSSRF対策の核心です。

次回は、信頼できないデータの復元で起きるデシリアライズによるRCEを、サーバ視点で改めて整理します。Java/PHP/Pythonでの被害連鎖を見ていきましょう。

次に読みたい記事

参考資料