はじめに
― XXE はファイル読み取りだけでは終わらない。
内部ポートスキャン・内部 API への不正アクセスも可能 ―
XXE（XML External Entity）脆弱性は、
単に /etc/passwd を読み取るだけの脆弱性ではありません。
攻撃者は 外部エンティティ（SYSTEM）に任意 URL を指定することで、
サーバー自身に HTTP リクエストを送らせることができます。
この性質を悪用すると、
XXE → SSRF（Server-Side Request Forgery） という強力な攻撃チェーンが成立します。
今回は、TryHackMe のタスク内容に沿って
XXE を利用して 内部ポートスキャン & 内部サービスの情報取得 を行う手順を
記事としてまとめます。
SSRF（Server-Side Request Forgery）とは？
SSRF攻撃とは：
攻撃者がサーバーを強制的に “代理で” 外部 or 内部にリクエストさせる攻撃
サーバーが送信元となるため：
- 外向き（Out-of-Band）通信
- 内部ネットワーク通信
- localhost や 127.0.0.1
- VPC 内部の AWS Metadata
- k8s API
- 開発用コンソール
- 認証不要の内部管理画面
など、攻撃者が普通はアクセスできない領域に到達できます。
XXE は、この SSRF を引き起こす最もシンプルな入り口です。
XXE → SSRF の仕組み（図解）
- XML に悪意ある外部エンティティを仕込む
- XML パーサーが
<name>&xxe;</name>の中身を展開 -
SYSTEM "http://localhost:8080"などへサーバー自身がアクセス - 内部サービスの内容がレスポンスに含まれる
- 攻撃者がそれを読み取り、内部情報を入手
サーバーを内部情報スキャナーとして強制労働させる、という構造。
実例：XXE を使って内部ネットワークをスキャンする
まず、以下の XXE payload を Burp Intruder に送ります：
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "http://localhost:§10§/" >
]>
<contact>
<name>&xxe;</name>
<email>test@test.com</email>
<message>test</message>
</contact>
ポイント：
-
localhost:§10§
→ この部分を Intruder の パラメータ化（番号範囲で総当たり） -
&xxe;
→ XML パーサーが外部 URL を参照する起点
手順①：Burp Intruder でポートを総当たり
- In-Band XXE のタスクで取得したリクエストを Intruder に送る
- Port
8080の部分を選択し Add § - Intruder → Payloads
- Payload type: Numbers
- Range:
1〜65535 - Start Attack
手順②：レスポンスの長さ（Length）でスキャン結果を判定
通常の応答はサイズがほぼ同じですが、
内部サービスが実際に応答した場合だけレスポンスサイズが異なるため、
Length カラムをソートすると「変化があったポート」が一気にわかります。
例（実際の TRYHACKME 画面）：
| Port | Length | 状況 |
|---|---|---|
| 21 | 248 | × |
| 23 | 248 | × |
| 81 | 322 | ←応答あり（怪しい！） |
この 81 番が内部サービス。
クリックすると…
内部サービスが返してきたデータの例
内部アプリケーションがレスポンスを返すと、
XXE によって そのまま外部（攻撃者）に漏洩します。
例：
Flag: THM{0O8_xx3!!}
そのままフラグが丸見え。
このように、SSRF は“内部の宝物を外へ流出させる”攻撃です。
Server がこの攻撃をどう処理しているか？
XML の <name>&xxe;</name> をパースすると、
&xxe;（外部エンティティ）が展開されます。
<!ENTITY xxe SYSTEM "http://localhost:8080">
↓
サーバーは localhost:8080 に HTTP GET を送る
↓
内部サービスが応答する
↓
その内容が XML パーサーの返り値になり、
最終的にレスポンスに含まれて攻撃者へ渡る。
攻撃による潜在的リスク
内部ネットワークの Reconnaissance（偵察）
- ポートスキャン
- サービス名の特定
- バージョン推測
- 技術スタック推測
内部サービスの内容の外部漏洩
- 環境変数
- API keys
- Secret tokens
- アプリケーションログ
- 管理者画面の HTML
Privilege Escalation（特権悪用）
内部サービスに以下が存在すると危険：
- Debug console
- Jenkins / Admin UI
- Redis / Elasticsearch / Kibana
- Docker API
- AWS Metadata (169.254.169.254)
- k8s API
SSRF は、
“外から見えない内部の扉” を開けてしまう攻撃。
対策（XXE と SSRF 両方の視点）
-
DOCTYPE / 外部エンティティ禁止（最重要）
XML パーサーで以下を disable:
- DTDLOAD
- NOENT
- External Entities
-
SSRF を防ぐアウトバウンド制限
- localhost/127.0.0.1 へのアクセス禁止
- RFC1918 (10., 172.16., 192.168.*) のアクセス拒否
- VPCメタデータの遮断
- ファイアウォールによる送信先制限（egress control）
-
ホワイトリスト方式の URL フィルタリング
-
JSON へ移行（XML が不要な場合）
まとめ
- XXE には「SSRF 起点」としての側面がある
- XML の外部エンティティは任意 URL にアクセス可能
- Burp Intruder を使えば内部ポートスキャンもできる
- 応答サイズの差でポートの開閉を判断できる
- 内部サービスがそのままレスポンスに漏洩する
- これは単なるファイル読み取りよりはるかに危険
- 対策は XML パーサーの安全設定 + SSRF 制御