JSSI 2012 - XML et sécurité

Nicolas Grégoire (Agarri)

« XML et sécurité »
edit: slides
@Agarri_FR

Petit rappel sur les technologies XML et leur fonctionnement pour ceux qui ne connaissent pas, puis on va plonger dans le sujet.

Le rendu fait par les navigateurs dépend fortement du namespace, ça permet par exemple d’étendre les fonctionnalités d’une balise donnée. Ainsi, il est possible d’intégrer un namespace PHP pour appeler des fonctions php depuis XML, et avec d’autres namespaces on peut appeler des commandes etc… (cf présentation SSTIC2011).

Homo-iconicité : De même apparence (XML) mais de fonctionnalité très différentes. Ainsi le comportement vis à vis du document XML dépend de l’application et de son comportement.

Il est ainsi possible de tout mélanger avec une DTD, du XML, du XSL pour transformer le XML et du SVG !!!

Les cas d’usages : Images, Web Services, Web, Signature, programmation en XSL, Playlist en XSPF, RSS avec Atom… Bref XML est partout, mais on ne le voit pas.

Un grand nombre d’applications permettent d’uploader du contenu XML sur le serveur et de lancer des traitements associés. Et parfois on trouve certains sites qui utilisent directement des codes d’exemples pour faire des transformations XSL sur des fichiers XML, les deux étant fournis en paramètres, paramètres manipulables par l’attaquant.

Bien sur, il est possible de déterminer à distance quel type de traitement est effectué en envoyant des fichiers de tests qui passeront ou pas dans le traitement coté serveur.

Démonstration avec un lecteur de flux Atom, en Perl, Java et PHP.

On passe au vif du sujet : l’encapsulation.

XDP : XML Data Package, format Adobe, qui peut contenir du PDF et du XFA, sachant que du PDF peut embarquer du XDP. On à donc un effet poupées russes qui offre une solution d’offuscation très puissante.

En prenant un vieil exploit PDF metasploit, on à une détection de 24/43, lorsqu’on embarque le PDF en base64 dans un XDP dans un PDF, on évade toute forme de signatures.

Le déni de services est aussi possible avec une bombe XML, ou l’attaque aux milliards de LOL, on prend un élément XML contenant LOL, avec 10 éléments LOL1 qui font référence à LOL et ainsi de suite, s’en suit une explosion combinatoire qui défonce la mémoire du serveur. 1 milliard de LOL, 3GO en mémoire…

Une passerelle XML-DSIG supporte parfois XSLT, le problème c’est que la norme précédente disait qu’il fallait implémenter XSLT dans XML-DSIG, et dans la nouvelle norme c’est proscrit alors dans le doute les éditeurs le font.

Ainsi en transformant un simple chiffre en chiffres romains avec XSLT, on peut générer des centaines de milliers de M si l’on choisit un gros chiffre avec exposant 🙂

L’attaque aux milliards de LOL fonctionne aussi sur Firefox qui fait ce qu’il peut pour décoder le XML. La grammaire est la vulnérabilité la plus courante en XML, car il est possible de spécifier dans une DTD une entité (TAG) dont la valeur est un fichier donné (et boum le /etc/passwd). Beaucoup pensent que la lecture de fichier textes est la seule fonction accessible… cependant ça fonctionne aussi avec du HTTP, il est donc possible de requêter des sites avec http:// et de voler des hash Windows avec smb://.

Le rendu de l’URL est dépendant du système, de l’interpréteur etc… et ce n’est pas les handlers qui manquent (notamment en PHP). php:// qui permet d’appeler du code PHP à chaque appel au fichier, si ce n’est pas fait pour implémenter des attaques, on se demande à quoi ça sert…

Nouvelles démonstrations de ces usages… et boum 🙂

http://xhe.myxwiki.org/xwiki/bin/view/Main/WebHome pour plus d’information 😀

Une dernière démo avec un reverse shell java. Alors il n’y a pas de moyen de porter le code en XSLT, mais il est possible d’encoder du bytecode java en base64 et de l’exécuter.