Que sont les attaques Local File Intrusion (LFI) et devriez-vous vous inquiéter ?

Les serveurs Web hébergent les fichiers (pages Web, images, vidéos, formulaires, etc.) qui composent votre application Web et servent ces fichiers lorsque quelqu’un visite votre site Web. Certains serveurs sont plus avancés et contrôlent également le degré d’accès des visiteurs Web. Ils peuvent empêcher les visiteurs réguliers d’accéder aux comptes ou aux tableaux de bord administratifs d’autres utilisateurs. Bien que les serveurs Web soient efficaces dans ce qu’ils font – et ils le font de manière plutôt sécurisée – les attaquants peuvent exploiter les erreurs qui résultent d’une erreur humaine ou d’une logique défectueuse dans la façon dont un serveur sert les fichiers qu’il héberge.

Qu’est-ce qu’une attaque LFI ?

Une attaque Local File Intrusion (LFI) se produit lorsque des attaquants exploitent des vulnérabilités dans la façon dont un serveur Web stocke, sert, valide ou contrôle l’accès à ses fichiers. Cette vulnérabilité est commune aux sites Web basés sur PHP.

Contrairement à de nombreuses formes de cyberattaques où les attaquants s’appuient sur des logiciels malveillants pour corrompre une application, les attaquants des LFI s’appuient principalement sur des astuces intelligentes et des lignes de code courtes. Cela nécessite rarement des outils sophistiqués ou des scripts complexes ; les attaques se produisent généralement sur le navigateur Web. L’astuce la plus courante utilisée par les attaquants consiste à modifier la chaîne d’URL avec du code, des chemins de fichiers ou des noms de fichiers.

Comment les attaques LFI se produisent-elles ?

Les attaques LFI se déroulent généralement en quatre étapes.

Tout d’abord, l’attaquant identifie un site Web PHP exécutant une application Web vulnérable, généralement en exécutant un code de base dans l’URL du navigateur pour voir si l’application Web (c’est-à-dire le site) gère la commande. Pensez-y comme en appuyant sur des combinaisons de touches sur votre contrôleur de jeu pour déverrouiller un œuf de Pâques, disons, par exemple, en appuyant sur la touche bas pour entrer dans des tunnels dans Super Mario. Mais les commandes exécutées par les attaquants dans les attaques LFI sont plus cohérentes que la vérification de chaque tunnel dans Super Mario.

Une application Web ou un serveur mal configuré ou qui ne parvient pas à valider les entrées exécutera le code malveillant. À partir de là, le pirate peut obtenir l’accès et les privilèges dont il a besoin pour lire les fichiers vulnérables ou télécharger des fichiers malveillants sur le serveur.

La plupart des attaques LFI permettent à l’attaquant d’accéder à des informations sensibles. La possibilité de télécharger des logiciels malveillants est rarement couronnée de succès car il n’y a aucune garantie que l’application Web enregistrera le fichier sur le même serveur où la vulnérabilité LFI existe. C’est souvent le cas si l’application Web se trouve dans un environnement multiserveur.

Ainsi, si la vulnérabilité LFI existe sur le serveur qui héberge les images mais pas sur le serveur qui stocke les informations d’identification des employés ou les mots de passe des utilisateurs, l’attaquant n’aurait accès qu’aux fichiers image sur ce serveur vulnérable. Quoi qu’il en soit, des cyber-événements comme l’attaque de LastPass montrent que les pirates peuvent faire des ravages avec un niveau d’accès apparemment le plus insignifiant.

Comment prévenir les attaques LFI

Les attaques LFI sont assez courantes, selon l’ Open Web Application Security Project (OWASP). Naturellement, les pirates seraient favorables à cette attaque puisque, comme le rapporte W3Techs , près de huit sites Web sur 10 exécutent PHP comme langage de programmation côté serveur – une abondance de victimes, pour ainsi dire. Il est possible d’empêcher une attaque LFI en adoptant les meilleures pratiques de sécurité Web.

Liste blanche des fichiers du serveur public

Les applications Web utilisent souvent des chemins de fichiers comme entrées d’URL. Les pirates peuvent exploiter ce système de fichiers en modifiant la partie de l’URL qui sert également de chemin de fichier. Par exemple, un attaquant peut remplacer https://dummywebsite.com/?module=contact.php par https://dummywebsite.com/?module=/etc/passwd. Un serveur vulnérable avec un filtrage médiocre et une logique défectueuse affichera le contenu du fichier stocké dans le chemin /etc/passwd.

Bien sûr, les pirates utilisent des variantes de noms de fichiers courants et des combinaisons de caractères de requête pour augmenter les chances de réussite d’une attaque. L’objectif est d’inciter l’application Web à exécuter un script ou à afficher les fichiers sur un serveur Web.

Vous pouvez bloquer cette vulnérabilité en créant une liste blanche de documents publics sur votre serveur et en demandant à l’application Web d’ignorer les requêtes pour tous les autres documents ou chemins de fichiers. Ainsi, si un attaquant essaie de manipuler l’URL pour demander ou exécuter des codes demandant un privé, il obtiendra une page d’erreur à la place.

Testez fréquemment les vulnérabilités

Vous pouvez utiliser des outils d’analyse Web pour rechercher et corriger les vulnérabilités qui pourraient vous exposer à des attaques LFI. Les analyseurs d’applications Web sont des outils automatisés qui analysent votre application comme un attaquant et vous alertent des vulnérabilités potentielles. Il existe plusieurs scanners Web open source comme OpenVAS et Wireshark, mais la plupart des scanners de vulnérabilité sont des logiciels propriétaires et nécessitent des plans payants pour être utilisés.

Mais, bien sûr, vous n’obtenez pas un scanner Web uniquement pour les attaques LFI. Ces outils recherchent également des vulnérabilités de sécurité plus larges telles que l’inclusion de fichiers distants, les scripts intersites, l’injection SQL et les mauvaises configurations de serveur. Alors, ils en valent la peine.

Restreindre les privilèges des visiteurs du site

Les pirates exécutent souvent des attaques LFI avec succès parce que les applications Web ne parviennent pas à compartimenter les privilèges des utilisateurs et, ce faisant, permettent aux visiteurs d’accéder à des fichiers qui ne devraient être visibles que par les administrateurs. Cette mesure fonctionne comme une liste blanche : configurez votre application Web et votre serveur afin qu’ils servent des fichiers publics et ignorent les demandes non autorisées lorsqu’un visiteur interagit avec l’application Web. Ceci est particulièrement important pour les requêtes portant sur des chemins de fichiers contenant des fichiers sensibles.

À cette fin, vous devrez peut-être empêcher la modification directe des chemins d’accès aux fichiers. L’application Web ne doit servir que des documents à partir d’une liste de chemins codés en dur. De plus, configurez l’application Web pour traiter les requêtes avec une concaténation de chemin dynamique (les URL doivent contenir des caractères alphanumériques) au lieu des fonctions base64 ou bin2hex.

Si vous envisagez de mettre des noms de fichiers sur liste noire, ne le faites pas. Les pirates ont généralement une liste croissante de noms de fichiers qu’ils peuvent utiliser pour exécuter une attaque LFI. De plus, il est pratiquement impossible (et une perte de temps colossale) de mettre sur liste noire une liste de sources d’attaque en constante augmentation.

Utiliser un environnement multi-serveur

Un environnement multi-serveurs vous permet d’isoler les documents importants et sensibles des fichiers publics, réduisant ainsi votre risque en cas de violation. Les serveurs dédiés sont moins vulnérables aux attaques LFI car, bien qu’ils fonctionnent ensemble, leurs configurations diffèrent.

Outre cette sécurité, plusieurs serveurs sont également fiables (avec des risques d’indisponibilité réduits), rapides et efficaces. Certes, l’utilisation d’un environnement multi-serveurs n’est pas rentable si votre site Web est petit. Dans ce cas, envisagez de répartir l’accès aux données de votre application Web entre une base de données pour les données privées et un serveur pour les fichiers publics.

Devriez-vous vous inquiéter des attaques LFI ?

La possibilité d’une attaque LFI existe, surtout si votre site fonctionne sur PHP, mais vous pouvez réduire votre exposition en configurant les applications Web et les serveurs conformément aux meilleures pratiques de sécurité Web.

De plus, vous devriez envisager de faire des vérifications de sécurité de routine pour trouver des vulnérabilités. Les choses se cassent tout le temps, d’autant plus que l’architecture du site devient complexe. Les outils dont vous aurez besoin pour vous protéger sont automatisés et nombre d’entre eux ne nécessitent pas une configuration élaborée ni un savoir-faire technique avancé.