Les composants tiers sont omniprésents dans les applications web. En effet, librairies, frameworks et autres composants système sont de plus en plus utilisés car ils permettent de réduire les coûts et de faciliter les développements.
Cependant, comme tout système, ces composants tiers peuvent contenir des vulnérabilités exploitables lors d’attaques sur des applications web. De plus, les exploits découverts, et souvent rendus public, peuvent avoir un effet boule de neige et ainsi compromettre l’intégralité d’une application web, les serveurs, les systèmes de base de données, etc.
Dans cet article, nous vous présentons ce type de vulnérabilités à travers le prisme de l’OWASP Top 10, et ce via des scénarios d’attaques. Nous y détaillons également les bonnes pratiques et les mesures à mettre en œuvre pour s’en prémunir.
Petit rappel sur l’OWASP et l’OWASP Top 10
L’OWASP est une fondation à but non lucratif qui a pour mission d’améliorer la sécurité des logiciels. Elle est composée d’une communauté active qui participe à la création de diverses ressources comme des guides ou des normes de sécurité pour un large panel de technologies et de contextes différents.
L’OWASP propose également différents projets comme le proxy d’interception open source ZAP (une alternative à Burp) ou l’OWASP Top 10.
OWASP Top 10 et catégorie sur les composants vulnérables
L’OWASP Top 10 est un classement des 10 types de vulnérabilités les plus courantes sur les applications web. Ce classement est mis à jour régulièrement depuis sa première publication en 2013 jusqu’à sa dernière version en 2021.
Ci-dessous, la comparaison entre la version de 2017 et de 2021 et les différentes catégories de vulnérabilités recensées :
Par ailleurs, même si l’OWASP Top 10 ne fournit pas une liste exhaustive de toutes les vulnérabilités web, il donne de bonnes bases aux développeurs et aux professionnels de la cybersécurité pour tester et sécuriser une application web.
Et, comme nous pouvons le voir sur le graphique ci-dessus, la catégorie « composants vulnérables et obsolètes » a gagné 3 places (passant de la 9ème à la 6ème position). Cette tendance peut s’expliquer par :
- L’omniprésence des composants tiers dans les applications web aujourd’hui. On retrouve une multitude de composants pour une infinité de cas d’usages et énormément de langages différents. Il est donc possible de lancer des attaques d’envergure avec des chances de succès élevés.
- La facilité d’exploitation de ce type de vulnérabilités par les attaquants. En effet, comme indiqué en préambule, lorsque des exploits sont découverts sur un composant spécifique, ces derniers sont souvent rendus publics avec toutes les informations sur les failles et exploitations possibles, ce qui facilite grandement la tâche aux attaquants (même des novices).
Quels sont les principaux risques liés aux composants tiers ?
Les développeurs ne sont généralement pas au courant de la mise à disposition de mises à jour. De fait, certains composants vulnérables peuvent ainsi rester sur un serveur de production pendant des semaines, voire des mois ou des années.
Aussi, le turnover dans les équipes techniques et le manque de documentation n’arrangent pas le sort de ces composants tiers, qui ont tendance à devenir obsolètes. En conséquence, les applications web qui utilisent ces composants tiers héritent de failles de sécurité plus ou moins dangereuses.
La nature exacte de ces vulnérabilités et l’impact concret dépend du composant affecté, de la façon dont il est intégré à l’application et du contexte métier.
L’OWASP nous fournit quelques pistes pour nous indiquer si vous êtes potentiellement vulnérables :
- Vous ne connaissez pas les versions de tous les composants que vous utilisez, aussi bien côté serveur que client. Également, si vous ne connaissez pas les versions des composants utilisés par d’autres composants.
- Les composants ne sont pas à jour, ou dépréciés.
- Vous ne procédez pas un scan de vulnérabilités régulier.
- Les composants sont mis à jour uniquement périodiquement et non pas en fonction des risques du moment. Ainsi, une entreprise peut rester vulnérable plusieurs semaines ou plusieurs mois en attendant la date définie pour mettre à jour ses composants.
- Vos développeurs ne testent pas la compatibilité des composants mis à jour ou corrigés.
Les conséquences résultantes de l’utilisation d’un composant vulnérable peuvent être très lourdes et peuvent aboutir à une simple attaque XSS, à un accès complet à distance sur le serveur en exploitant une RCE. Voyons cela plus en détail.
Exemples d’exploitations de composants vulnérables sur des applications web
Swagger UI
Swagger UI est une librairie très utilisée pour afficher une documentation interactive d’une API.
Cette librairie propose une fonctionnalité, plutôt intéressante, qui permet à l’utilisateur de spécifier une url pointant sur un fichier yaml ou json et qui retournera à l’utilisateur les spécificités de l’API, indiquées dans le fichier.
Pour cela, l’utilisateur doit simplement ajouter le paramètre url ou configUrl à la fin de l’url de son Swagger :
- https://my-swagger.com?url=https://evil/spec.yaml
- https://my-swagger.com?configUrl=https://evil/spec.yaml
Malheureusement, cette fonctionnalité est vulnérable à des injections XSS reflétées sur les versions 3.14.1 à 3.38.0 de Swagger UI. La cause : Swagger UI utilise elle-même une librairie afin d’assainir les inputs utilisateurs qui s’appelle DOMPurify.
Cette librairie a justement été créée pour aider les développeurs à se protéger contre certaines attaques comme les XSS. Cependant, les versions de Swagger UI entre la 3.14.1 et 3.38.0 utilisent des versions de DOMPurify pour lesquels des contournements ont été trouvés.
Exploitation d’une faille XSS reflétée
Pour notre exemple, nous avons une version vulnérable de Swagger UI qui est en 3.14.2. Nous hébergeons sur notre serveur, un fichier yaml malveillant renommé en « xss.yaml » dont voici ci-dessous son contenu :
On peut voir dans le rectangle rouge, le payload malveillant JavaScript qui sera exécuté. Le scénario est donc le suivant : après avoir hébergé son fichier malveillant sur son serveur, l’attaquant envoie l’url du Swagger de la victime à la victime en ajoutant en paramètre l’url pointant vers son serveur.
Ainsi, le payload XSS sera exécuté et la victime sera piégée. On peut voir sur l’image ci-dessous, dans le premier rectangle rouge, l’url du Swagger de la victime, http://127.0.0.1, suivie du paramètre « url » qui n’est autre que l’url pointant sur le fichier yaml malveillant de l’attaquant.
Avec le deuxième rectangle rouge, on voit bien que le payload a été exécuté. Pour cet exemple, le payload fait simplement apparaître une alerte avec le numéro 1, mais dans un cas réel nous pourrions faire beaucoup plus de dégâts comme voler le token d’authentification de la victime.
Correction de la vulnérabilité
Pour corriger cette vulnérabilité, il suffit de mettre à jour Swagger UI à la dernière version. Cependant si cela n’est pas possible, il faut impérativement mettre à jour la libraire DOMPurify utilisée par Swagger UI également à la dernière version.
Apache Struts 2
Apache Struts 2 est un framework open source qui permet de développer des applications Web Java EE. Les versions entre 2.3.32 et 2.5.10.1 sont vulnérables à des attaques RCE, c’est-à-dire à de l’exécution de code à distance sur le serveur.
La faille serait causée par le parser Multipart de Jakarta utilisé par Apache Struts 2. Celui-ci est d’ailleurs un framework très utilisé et la vulnérabilité qui l’affecte est extrêmement facile à reproduire, ce qui rend cette faille très critique.
Exploitation d’une RCE (Remote Code Execution)
Pour ce scénario, nous avons déployé une version vulnérable d’Apache Struts 2 (2.3.12) sur un serveur Apache Tomcat 7 comme nous pouvons le voir ci-dessous :
Grâce à un script python d’exploitation très facilement trouvable su Internet, nous pouvons exécuter des commandes sur le serveur qui héberge l’application en spécifiant l’url de l’application Web et la commande que nous voulons exécuter.
Cela aura pour effet d’envoyer une requête HTTP à l’application. La commande est contenue dans une expression OGNL (Object Graph Notation Language), qui est elle-même injectée dans le header Content-Type de la requête envoyée.
Lorsque la requête est reçue par le serveur, le header Content-Type avec le payload est analysé par le parser Multipart de Jakarta, ce qui déclenchera une erreur.
La fonction utilisée pour construire l’erreur interprétera le payload OGNL malveillant et la commande système envoyée par l’attaquant sera exécutée.
Ci-dessous, grâce au script, nous récupérons l’utilisateur et le contenu du fichier /etc/passwd :
Nous avons tout simplement le contrôle du serveur.
Comment corriger cette vulnérabilité ?
Comme pour le cas Swagger UI, la façon la plus efficace pour corriger cette vulnérabilité est de mettre à jour le framework à la dernière version. Si cela est trop coûteux pour l’entreprise, il est également possible de changer de parser avec le parser Multipart Jason Pells.
Aussi, il est judicieux de mettre en place un WAF permettant de filtrer et d’analyser les requêtes faites au serveur. Ainsi, des injections d’expressions OGNL pourront être détectées et bloquées avant d’arriver au serveur.
GLPI
GLPI (Gestionnaire Libre de Parc Informatique) est une application web open source – écrite en PHP – permettant, comme son nom l’indique, de gérer le parc informatique d’une entreprise.
Outre la possibilité d’inventorier toutes les ressources de l’entreprise, comme les logiciels utilisés ou encore les équipements réseau, GLPI offre par exemple une solution de suivi du support et de gestion financière.
En septembre 2022, plusieurs vulnérabilités critiques ont été découvertes sur GLPI dont une liée à l’utilisation de la libraire tierce htmLawed ayant pour but de standardiser le code HTML de l’application. Dans les versions 9.5.4 à 10.0.2 de GLPI, La version de la librairie htmLawed utilisée embarque en effet un fichier de test htmLawedTest.php permettant à un utilisateur non authentifié d’exécuter du code arbitraire sur le serveur.
Exploitation de la RCE
Afin d’illustrer la vulnérabilité (CVE-2022-35914), nous avons déployé une version vulnérable de GLPI :
Le fichier htmLawedTest.php mentionné précédemment est accessible sans authentification et permet à un attaquant d’exécuter du code arbitraire en manipulant le paramètre hook directement dans l’interface rendant la vulnérabilité facilement exploitable :
La commande spécifiée en entrée par l’attaquant s’exécute sur le serveur vulnérable aussi simplement que cela :
Cette faille RCE permet entre autres à l’attaquant de lire des fichiers potentiellement sensibles sur le serveur comme des fichiers de configuration contenant des mots de passe. Par exemple, l’attaquant peut facilement récupérer le mot de passe d’accès à la base de données utilisée par GLPI. Comme rencontré lors de tests d’intrusion, ce mot de passe est bien souvent le même que le mot de passe root pour accéder au serveur en SSH.
Comment contrer cette attaque ?
GLPI ayant corrigé cette vulnérabilité dans la version 10.0.3, mettre GLPI à jour vers cette version ou une version supérieure est la marche à suivre. Dans le cas où la mise à jour n’est pas possible dans l’immédiat, il est recommandé de supprimer le fichier htmLawedTest.php ou a minima d’en restreindre l’accès.
Par ailleurs et plus généralement, certaines applications – comme GLPI – destinées à un usage interne ne devraient pas être exposées publiquement au risque d’augmenter inutilement la surface d’attaque de l’entreprise.
De même pour une application exposée directement sur Internet, il est nécessaire de restreindre l’accès à certaines parties non publiques de l’application. Par exemple, les droits d’accès au dossier /vendor/ de GLPI peuvent être restreints pour empêcher qu’il soit accessible publiquement (à supposer que GLPI doivent être exposé sur Internet).
Comment se prémunir de ce type de vulnérabilités ?
De manière générale, afin d’éviter d’être exposés à des vulnérabilités causées par des composants vulnérables et obsolètes, il est essentiel de développer des processus de gestion des correctifs (patch management).
Ces processus consistent à :
- Supprimer les composants non utilisés ;
- Régulièrement faire l’inventaire des versions de tous vos composants, et de leurs dépendances, donc des composants qu’ils utilisent ;
- Continuellement être au courant des dernières vulnérabilités majeures et mettre à jour les composants concernés ;
- N’utiliser que des composants de sources fiables et officielles ;
- Monitorer les composants qui ne sont plus maintenus ou qui ne possèdent pas de correctifs pour des anciennes versions ;
Ainsi, grâce au patch management, la sécurité d’une application sera garantie tout au long de sa durée de vie.
Auteurs : Lorenzo CARTE & Benjamin BOUILHAC – Pentesters @Vaadata