LFI Log Poison

Le Local File Inclusion (LFI) combiné au log poisoning est une chaîne d'attaque puissante qui peut escalader de la divulgation d'informations à l'exécution de code à distance. Les vulnérabilités LFI surviennent lorsque les applications web incluent des fichiers du système de fichiers du serveur basés sur des entrées contrôlées par l'utilisateur sans validation appropriée. Lorsque les attaquants chaînent le LFI avec des techniques de log poisoning, ils peuvent injecter du code malveillant dans les fichiers de log du serveur puis inclure ces logs via la vulnérabilité LFI pour exécuter du code.

Comprendre le Local File Inclusion

Les vulnérabilités LFI surviennent lorsque les applications utilisent des entrées utilisateur pour construire des chemins de fichier pour les inclusions dynamiques. Un schéma courant implique un paramètre de page comme page=dashboard que l'application traduit en chemin de fichier pour l'inclusion. Si l'application ne sanitise pas correctement cette entrée, les attaquants peuvent utiliser des séquences de traversée de répertoires (../) pour sortir du répertoire prévu et lire des fichiers arbitraires sur le serveur, tels que /etc/passwd, les fichiers de configuration de l'application ou les logs du serveur.

Comment fonctionne le log poisoning

Le log poisoning exploite le fait que les serveurs web enregistrent les détails des requêtes - y compris les en-têtes User-Agent, les URLs et d'autres données contrôlées par le client - dans des fichiers de log. Un attaquant envoie une requête avec du code malveillant (comme du code PHP) injecté dans l'en-tête User-Agent. Le serveur web écrit ce code dans son fichier de log d'accès. Lorsque l'attaquant utilise ensuite la vulnérabilité LFI pour inclure le fichier de log, le serveur web traite le code injecté, réalisant l'exécution de code à distance. Cette technique transforme une inclusion de fichier en lecture seule en compromission complète du serveur.

Chaîne d'attaque en pratique

Une attaque typique LFI vers RCE par log poisoning suit un processus méthodique : d'abord, l'attaquant confirme la vulnérabilité LFI en lisant des fichiers connus. Ensuite, il identifie l'emplacement des fichiers de log du serveur (couramment /var/log/apache2/access.log ou /var/log/nginx/access.log). Puis il injecte une charge utile de code via un en-tête HTTP qui est enregistré. Enfin, il inclut le fichier de log empoisonné via la vulnérabilité LFI pour exécuter son code. Cette chaîne d'attaque démontre comment des vulnérabilités apparemment mineures peuvent être chaînées pour un impact dévastateur.

Prévention et détection

La défense contre le LFI et le log poisoning nécessite plusieurs couches de sécurité. Les applications devraient utiliser des listes blanches pour les inclusions de fichiers plutôt que de s'appuyer sur des listes noires ou la sanitisation. La validation des entrées doit empêcher les séquences de traversée de répertoires. Les configurations du serveur web devraient empêcher le moteur PHP de traiter les fichiers de log. Les permissions de fichiers devraient limiter les fichiers que le processus de l'application web peut lire. La surveillance de sécurité devrait alerter sur les schémas d'accès aux fichiers inhabituels et les entrées de log suspectes contenant des motifs de type code.