Introduction

Je suis récemment tombé sur une vulnérabilité intéressante d'inclusion de fichiers locaux dans un site web privé que j'ai pu mettre à niveau vers une exécution de code à distance. Donc, basiquement cette faille s'exploite à l'aide de la faille LFI (Local File Inclusion).

• LFI (Local File Inclusion) est un type de vulnérabilité trouvé le plus souvent sur des sites web. Il permet à un attaquant d'inclure un fichier distant, généralement par le biais d'un script sur le serveur web.

🤓 Objectifs

✅ Comprendre les bases du fonctionnement d'un code PHP. ✅ Comprendre la vulnérabilité de type LFI (Local File Inclusion) et son pivot vers une exécution de commande.

Démonstration et mise en place

Je vais mettre en place un script PHP qui contiendra un code qui permettra d'inclure des fichiers à distance depuis le paramètre file.

<?php echo include($_REQUEST["file"]); ?>

J'utilise la fonction include(); pour inclure des fichiers, et ensuite avec la méthode "requests" $_REQUEST qui prend en compte à la fois la méthode POST et GET.

Dans le cas ou je décide d'appeler le paramètre depuis mon navigateur WEB, en spécifiant un nom de fichier comme /etc/passwd, je serais capable de le lire.

Je peux maintenant contacter mon site depuis mon navigateur en mettant l'adresse IP de ma machine locale. J'ai mis le paramètre file en mettant comme valeur le nom du fichier que je souhaite inclure, donc dans notre cas, j'ai inclus le fichier /etc/passwd.

On peut également voir les permissions que j'ai dans le système, en incluant le fichier /proc/self/status. Donc, il s'avère que d'après le screen, mon UID est 33 et GID 33, cela signifie que le serveur PHP est exécuté en tant que www-data (utilisateur par défaut).

Je peux également, par exemple, voir les groupes des utilisateurs dans le système distant en incluant le fichier /etc/group dans le serveur WEB. Ici, il y a quelque chose de très intéressant c'est que l'utilisateur www-data a le groupe adm, cela signifie que je peux techniquement lire les fichiers logs, cela peut me ramener à une exécution de commande dans le serveur.

• adm: le groupe adm est utilisé pour les tâches de surveillance du système. Les membres de ce groupe peuvent lire de nombreux fichiers journaux dans /var/log et peuvent utiliser xconsole. Historiquement, /var/log était /usr/adm (et plus tard /var/adm), donc le nom du groupe.

Donc, je peux techniquement inclure un fichier log dans le serveur par exemple le fichier log de Apache (/var/log/apache2/access.log).

Imaginons que je souhaite lui envoyer dans l'UA (User-Agent) un code PHP. Lorsque je tenterai d'inclure le fichier access.log, il interprétera mon code PHP et le traitera également. Je vais par exemple intercepter la communication entre le client et le serveur à l'aide d'un Proxy (je vais utiliser l'outil BurpSuite) et changer l'UA par un code PHP.

Dans l'exemple ci-dessous, je lui ai envoyé le code PHP :

User-Agent: <?php echo 'Mon code PHP'; ?>

Ensuite, lorsque je tenterai d'inclure mon fichier access.log, il m'interprètera le code PHP, car lors de l'inclusion, il l'a reconnu comme un code PHP et il a interprété ce que je lui ai envoyé dans l'UA. Maintenant, je peux techniquement exécuter des commandes en utilisant la fonction system();.

💪 Challenge

• Utilise le Docker DVWA (https://hub.docker.com/r/vulnerables/web-dvwa/), faire docker run --rm -it -p 80:80 vulnerables/web-dvwa pour le démarrer et y accéder sur votre port 80.
• Essaye d'exploiter la faille LFI (menu "File Inclusion"), ensuite de pivoter vers une exécution de commande et avoir un reverse shell.
• Fais une capture d'écran du reverse shell et de la commande exécutée sur le service HTTP.
• Copie-colle tes captures dans un Gist. Partage ton lien public dans la partie solution de cette quête.

Critère de validation :

• Réussir à avoir un reverse shell en exploitant les fichiers logs.