Exécution de code via l'inclusion XSL dans un script PHP vulnérable

Par Rédaction, secuobs.com
Le 04/02/2009

---

Résumé : Un chercheur de la société Acunetix propose une technique permettant l'exécution de code Javascript/PHP via l'inclusion de fichiers XSL dans un script PHP vulnérable. Avec cette méthode, il est également possible de lire des fichiers arbitraires. - Lire l'article



Bogdan Calin, un chercheur en sécurité travaillant pour la société Acunetix ( lien ), vient de publier un article portant sur une vulnérabilité qu’il décrit comme une inclusion à distance de fichiers XSL ( Extensible Stylesheet Language - lien ), une technique qu’il a pu être amené à découvrir lors d'un audit de sécurité réalisé sur un code développé à l’aide du langage PHP ( Hypertext Preprocessor - lien ). A savoir que ce langage supporte les transformations XSL en utilisant la classe XSLTProcessor ( lien ) et plus particulièrement l’importation XSL via la méthode XSLTProcessor->ImportStylesheet() ( lien ).

Plus concrètement, le code PHP disponible dans l’article doit charger un document donné au format XML ( Extensible Markup Language - lien ) et lui faire subir différentes transformations à travers un traitement contrôlé depuis un fichier XSL ; c'est ce fichier XSL qui contient initialement les règles de transformation nécessaires au traitement des données. Bogdan Calin a en fait simplement modifié un code qui provenait à la base d’une page PHP reposant sur la méthode XSLTProcessor::transformToXML ( lien ) afin de pouvoir y inclure les éléments nécessaires à l'exploitabilité de la vulnérabilité dont il est ici question.

Cette vulnérabilité intervient lorsque le fichier XSL est chargé dans le processus de traitement depuis une source extérieure, qui peut alors s’avérer être contrôlée par un attaquant. Dans l’exemple fourni, cet attaquant peut spécifier l’emplacement d'un fichier XSL à charger via une valeur spécifique qui sera fixée puis passée vers le script de traitement à l'aide d'un paramètre de formulaire. Le passage des données malicieuses est ici effectué en utilisant l'exploitation classique de la méthode GET des formulaires. Dans ce contexte, il est donc possible d'inclure un fichier XSL en manipulant une URL avec une valeur pointant vers un fichier stocké sur un site Web distant.

Contrairement à la méthode POST qui envoie les données sans les passer dans l’URL d’appel au script de traitement, la méthode GET passe ces données directement dans l’URL en séparant l’adresse (du script) et les données via un point d’interrogation. Cette vulnérabilité pourrait tout d’abord permettre à un attaquant de conduire des attaques de type Cross Site Scripting XSS ( lien ). Un exemple de fichier XSL permettant d’exécuter du code Javascript ( lien ) est fourni en tant que Preuve de Concept ( PoC - lien ) dans l’article.

Via l’exploitation de cette vulnérabilité, il est également possible d’envisager l’exécution de code PHP à la seule condition que la fonction registerPHPFunctions ( lien ) soit activée. La classe XSLTProcessor propose en effet la fonction registerPHPFunctions afin d’autoriser l’utilisation des différentes fonctions du langage PHP en tant que fonctions XSLT, celles-ci seront directement embarquées à l’intérieur des feuilles de style XSL. Le fichier XSL, permettant l’exécution de code PHP, est lui aussi fourni en exemple dans l'article écrit par Bogdan Calin.

Il existe une troisième exploitation permettant de lire des fichiers arbitraires. Cependant des restrictions sont de mises, il n’est possible de lire dans leur entièreté que les données des fichiers formatés en HTML ( Hypertext Markup Language - lien ). Néanmoins, on peut lire la première ligne de n’importe quel autre type de fichier, ce qui peut s’avérer intéressant pour un « .htpasswd » ( voir notre dossier - lien ) contenant les informations de connexion aux services fournis par un serveur Apache ( lien ) et demandant une authentification via un « .htaccess ».

Un exemple de fichier XSL est là aussi mis à disposition afin de s’assurer de la faisabilité de l’exploitation. Comme on peut le constater dans l’exemple donné, XSLTProcessor::transformToXML trouve initialement des erreurs dans la première ligne du fichier ciblé, mais il l'affiche tout de même dans sa globalité. Afin de se protéger des différents impacts liés à cette vulnérabilité d’inclusion de fichiers XSL, il est impérativement nécessaire de s’assurer du fait que le fichier XSL à traiter n’est pas issu d’une source pouvant être manipulée facilement par un attaquant aux intentions malveillantes.

Une solution intermédiaire, pour s’assurer de la bonne provenance du fichier XSL, pourrait consister en la mise en place préalable d’un système de restriction via une liste de filtrage portant sur les noms des fichiers acceptables dont on souhaite à l’avenir autoriser le chargement au sein du processus du traitement. Il est par ailleurs possible pour les développeurs de tester l’exploitabilité d’une application particulière, face aux risques que représente cette vulnérabilité, en utilisant la version gratuite du scanner ( lien ) de vulnérabilités Web de la société Acunetix

Source : Security Bloggers Network & Acunetix Blog ( lien ).