1. Reconnaissance

J'ai commencé par récupérer l'adresse IP de la machine cible, Pour cela, j'ai utilisé la commande suivante : netdiscover –r 192.168.56.0

Voici le résultat de reconnaissance :

j'ai rapidement identifié la machine cible à l'adresse IP 192.168.56.114 grâce à sa réponse ARP et son adresse MAC.

2. Scanning des ports

J'ai effectué un scan de ports complet avec la commande nmap –sS –O — A 192.168.56.114.

Les informations recueillies à partir du scan :

3. Exploitation des vulnérabilités

· Port 8080

J'ai accédé à l'interface web via navigateur : http://192.168.59.114, Lorsque j'ai exécuté cette commande, le résultat affiché était le suivant :

Donc, j'ai utilisé l'outil Dirb pour analyser les répertoires du site web. Cet outil permet de détecter à la fois les répertoires visibles et ceux qui sont cachés.

Suite à l'analyse des répertoires, j'ai identifié le fichier /robots.txt. J'ai ensuite poursuivi l'exploration en accédant à ce répertoire pour examiner son contenu.

La page était vide, mais j'ai remarqué quelques indices, notamment les symboles * et /. En poursuivant l'analyse, j'ai ajouté (/*) dans l'URL. Cette action a provoqué l'apparition d'une page d'erreur qui a, de manière inattendue, révélé un nouveau chemin : /mercuryfacts.

Lorsque j'ai accédé au répertoire /mercuryfacts, j'ai trouvé deux liens hypertexte. J'ai ensuite cliqué sur l'option « load a fact » pour afficher son contenu.

En accédant au lien proposé, j'ai observé une page affichant Fact id: 1. Cette observation m'a laissé penser que les informations provenaient d'une base de données. Sur cette base, j'ai envisagé la possibilité d'une vulnérabilité de type SQL injection et j'ai entrepris d'examiner cette piste plus en profondeur.

Étant donné que je soupçonnais une vulnérabilité à l'injection SQL, j'ai utilisé la command sqlmap –u http://192.168.56.144:8080/mercuryfacts/1/ -dbs –batch. J'ai ajouté les options -dbs, qui permet d'énumérer les bases de données, et -batch, qui autorise SQLMap à s'exécuter automatiquement sans demander d'interaction ou de confirmation.

Après l'extraction réussie des données, deux bases de données ont été identifiées :information_schema et mercury.

Après avoir confirmé la vulnérabilité de la page à l'injection SQL, j'ai procédé à l'extraction de l'ensemble des données disponibles de la base mercury en utilisant la commande suivante : sqlmap -u http://172.30.0.108:8080/mercuryfacts -D mercury — dumpall — batch

L'extraction a révélé quatre entrées dans une table nommée "users". En utilisant l'option — dumpall, j'ai pu obtenir la liste complète des bases de données, le contenu des tables, ainsi que les noms d'utilisateurs et leurs mots de passe.

· Port 22

En poursuivant l'analyse, les résultats du scan des ports effectué au début ont révélé deux ports ouverts, dont un service SSH. J'ai essayé de me connecter en tant que les trois premiers utilisateurs, mais l'accès m'a été systématiquement refusé.

Enfin, j'ai essayé de me connecter en tant que l'utilisateur webmaster.

Pour confirmer mon accès, j'ai utilisé la commande whoami afin de vérifier le nom de l'utilisateur.

Ensuite, j'ai exécuté la commande ls -all pour afficher tous le contenu du répertoire. Cela a permis de repérer un fichier nommé user_flag.txt.

J'ai alors consulté son contenu à l'aide de la commande cat user_flag.txt, ce qui a révélé le premier flag utilisateur.

Après cela, j'ai accédé au répertoire mercury_proj/ à l'aide de la commande cd mercury_proj/, puis j'ai listé tous son contenu avec ls -all. Enfin, j'ai consulté le fichier notes.txt en utilisant la commande cat, afin d'afficher le contenu.Le résultat montre qu'il y a un autre utilisateur qui est linuxmaster.

Je vais ensuite décoder la chaîne encodée en Base64 afin d'obtenir sa version en texte clair. Pour ce faire, j'ai utilisé la commande echo. Une fois le décodage effectué, le mot de passe de l'utilisateur linuxmaster s'est affiché en clair.

4. Escalade des privilèges

J'ai ensuite utilisé le mot de passe précédemment récupéré pour me connecter avec succès en tant qu'utilisateur linuxmaster.

Après l'authentification, j'ai vérifié les privilèges sudo associés à ce compte. L'analyse a révélé que l'utilisateur linuxmaster peut exécuter un script Bash spécifique, /usr/bin/check_syslog.sh, avec des privilèges root.

Il est également important de noter que cette exécution se fait dans un environnement préservé grâce à l'attribut SETENV. Cette configuration pourrait potentiellement être exploitée pour une élévation de privilèges.

J'ai ensuite utilisé la commande cat afin de lire le contenu du script. Celui-ci était conçu pour exécuter le programme tail dans le but d'afficher les 10 dernières entrées du fichier syslog.

Le script check_syslog.sh peut être exécuté dans un environnement préservé, ce qui ouvre une possibilité d'exploitation de la variable d'environnement PATH. Mon approche a consisté à créer un lien symbolique vers l'éditeur vim en le nommant tail, puis à modifier la variable d'environnement en conséquence.

L'étape suivante consistait à lancer check_syslog.sh en mode préservation de l'environnement. Cela permet d'associer le binaire tail à vim, entraînant l'ouverture du script syslog.sh dans l'éditeur vim.

J'ai exécuté la commande sudo — preserve-env=PATH /usr/bin/check_syslog.sh afin de vérifier le comportement normal du script. Mais je n'ai réussi pas.

Donc, J'ai créé un programme tail dans le répertoire /tmp. Ce script contenait un shebang et une commande permettant d'ouvrir un shell Bash root. Après lui avoir donné les droits d'exécution avec chmod +x, j'ai modifié la variable d'environnement PATH et lancé le script check_syslog.sh pour exploiter la vulnérabilité.

Grâce à l'exploitation réussie du PATH hijacking, j'ai obtenu un shell en tant que root. J'ai immédiatement vérifié mon identité avec les commandes whoami et id et listé le contenu du répertoire racine avec ls -all.

J'ai ensuite navigué dans le répertoire /root, listé son contenu pour identifier le fichier root_flag.txt, puis j'ai affiché son contenu avec la commande cat root_flag.txt.

Enfin, Le flag root a été récupéré.

5. Solutions proposées

1. Correction de l'injection SQL

· Utiliser des requêtes préparées (Prepared Statements)

· Éviter la concaténation directe des entrées utilisateur

· Implémenter un WAF (Web Application Firewall)

2. Sécurisation du service web

· Désactiver l'affichage des erreurs en production

· Restreindre les endpoints sensibles (/mercuryfacts)

· Mettre à jour le framework utilisé (WSGIServer)

3. Sécurisation SSH

· Désactiver l'authentification par mot de passe

· Utiliser uniquement les clés SSH

· Bloquer les tentatives de connexion répétées (fail2ban)

4. Correction des privilèges sudo (CRITIQUE)

· Supprimer SETENV

· Définir un secure_path strict

· Appliquer le principe du moindre privilège

5. Protection contre PATH Hijacking

· Ne jamais exécuter de commandes système sans chemin absolu

· Désactiver la modification de PATH via sudoers

· Vérifier les variables d'environnement avant exécution

6. Durcissement général système

· Mise à jour régulière du système

· Audit des fichiers SUID/SGID

· Monitoring des logs système

· Séparation des privilèges utilisateurs