Dans quelles situations peut se produire une vulnérabilité path traversal ? Comment détecter cette faille et s’en protéger ?
C’est ce que nous allons détailler dans cet article.
Définition d’une attaque path traversal
Une attaque path traversal ou directory traversal vise à accéder et lire des fichiers stockés en dehors de l’arborescence exposée directement par le service web.
Il s’agit de modifier des paramètres d’une requête pour naviguer dans l’arborescence. Le but de l’attaquant est de parcourir les répertoires afin d’atteindre des fichiers sensibles auxquels l’accès est normalement refusé (fichiers de configuration, code source…)
Dans certaines situations, l’attaquant a même parfois accès à des fonctionnalités non autorisées, comme l’écriture de fichiers sur le serveur. Cela peut l’amener à prendre le contrôle du serveur et la vulnérabilité devient alors une RCE.
Comment se produit la vulnérabilité path traversal ?
La plupart des applications web utilisent des ressources stockées localement (images, scripts, fichiers texte…) pour réaliser leurs tâches. Parfois, ces ressources sont intégrées dans d’autres pages via des paramètres manipulables par un utilisateur.
La faille path traversal survient lorsque les paramètres utilisateurs ne sont pas sécurisés (sanitized) et/ou qu’il y a un manque de contrôle d’accès aux ressources.
Il est alors possible pour un attaquant de modifier les paramètres de la requête pour demander de retourner d’autres ressources.
L’impact de cette faille est généralement critique. En effet, selon le contexte, l’attaquant peut
- obtenir la lecture de fichiers, potentiellement :
- des fichiers de configuration où il y a régulièrement des secrets (identifiants, clés…), qui permettent ensuite d’exploiter de nouvelles failles,
- des fichiers sensibles du système d’exploitation,
- lire le code source,
- analyser l’organisation du serveur,
- parfois, écrire sur le serveur, ce qui peut conduire à :
- une modification du comportement de l’application
- voire à la prise du contrôle du serveur
Comment identifier la faille directory traversal ?
Pour trouver une faille path traversal, il faut répertorier rigoureusement tous les endroits où les utilisateurs peuvent envoyer des données.
L’OWASP Testing Guide détaille des points à regarder :
- y a-t-il des paramètres qui sont reliés à des opérations nécessitant des fichiers ?
- y a-t-il des extensions de fichiers inhabituelles qui sont acceptées ?
- y a-t-il des noms de variables intéressants ? (item, file, home…)
- y a-t-il des cookies utilisés pour la génération des pages ou templates ?
Une fois les points identifiés, il s’agit de tout d’abord tester différentes techniques pour exploiter la vulnérabilité. Vous pouvez ensuite essayer des techniques pour bypasser les contrôles en place.
La méthode la plus courante est de vérifier s’il est possible de remonter dans d’autres répertoires :
- directement avec ../
- via de l’encodage, ce qui donne par exemple %2e%2e%2f
- via les notations unicode, ce qui donne par exemple %u2216%u2216
- avec file:
- via des wrappers
- …
Ces différentes techniques peuvent être à combiner, car certaines protections peuvent être en place tandis que d’autres non.
Vous pouvez vous appuyer sur PayloadsAllTheThings, qui répertorie une grande variété de payloads.
Une deuxième possibilité est d’inclure directement des ressources externes dans les paramètres d’appel, dans les cookies ou d’autres vecteurs.
Exemples de failles path traversal rencontrées
Durant les tests d’intrusion d’application web que nous réalisons, nous rencontrons régulièrement cette faille.
Certaines vulnérabilités découvertes sont des situations classiques, par exemple le paramètre utilisé dans une fonction include n’est pas protégé. Ou alors il est possible de manipuler un paramètre passé à une fonction curl dans laquelle il est possible d’utiliser file://.
D’autres failles sont plus subtiles. Par exemple, nous avons testé une application qui avait un générateur de pdf. Le générateur reprenait les données personnelles de l’utilisateur dans le pdf.
Pour exploiter la faille, nous avons modifié le champ « adresse » de l’utilisateur en y mettant une <iframe src=’file:///etc/passwd’></iframe>. Le générateur interprétait le HTML. Le problème était que la librairie était autorisée à aller chercher des fichiers via file://.
En générant le pdf, l’iframe était interprétée et allait afficher les ressources que nous avions demandées. L’impact d’une faille de ce style est alors critique.
Comment se protéger des failles path traversal ?
Pour éviter ces failles, plusieurs mesures doivent être mises en place :
- Ne pas utiliser les entrées utilisateurs directement pour appeler un fichier.
- Les données utilisateurs ne doivent pas être interprétées. Elles doivent être encodées, échappées et nettoyées.
- Elles doivent être validées par rapport à une liste d’expressions autorisées. Si ce n’est pas possible, alors la validation doit confirmer qu’il n’y a que du contenu autorisé (par exemple que des caractères alphanumériques).
Dans le cas de notre exemple du générateur de pdf, la correction est que le HTML ne soit pas interprété et le file: pas autorisé. De plus, il ne doit pas être possible de charger des fichiers locaux dans les iframe, ni des ressources web locales (SSRF).