はじめに

― 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 制御