Test di penetrazione black-box contro HackSudo Thor: RCE Shellshock CVE-2014-6271 tramite Apache mod_cgi, combinata con configurazione errata di sudo e injection di bash eval per la completa escalation dei privilegi. Include strumenti di brute force personalizzati consapevoli di CSRF e automazione RPC di Metasploit.
heventafese/penetration-testing-walkthrough-hacksudo-thor
Target: HackSudo Thor da VulnHub
Obiettivo: Ottenere l'accesso root e leggere/root/proof.txt
Ambiente: Laboratorio VirtualBox isolato segmentato da un firewall pfSense
Questo repository documenta un penetration test black-box parziale condotto su HackSudo Thor, una macchina virtuale volutamente vulnerabile pubblicata su VulnHub da Vishal Waghmare. L'obiettivo era simulare un attacco del mondo reale in cui un attaccante esterno tenta di compromettere un sistema interno isolato, con l'obiettivo primario di ottenere l'accesso root e leggere il contenuto di /root/proof.txt.
La valutazione segue l'intero ciclo di vita del penetration testing: ricognizione passiva, scoperta della rete, enumerazione, valutazione delle vulnerabilità, exploitation, privilege escalation, post-exploitation e copertura delle tracce.
Gli strumenti principali utilizzati sono stati Nmap per la scansione della rete, Nessus per la valutazione delle vulnerabilità e il Metasploit Framework come piattaforma principale per l'exploitation e la post-exploitation. John the Ripper, Hashcat e Rainbow Tables online sono stati utilizzati durante la fase di cracking delle password, anche se tutti i tentativi sono risultati infruttuosi a causa della robustezza dell'algoritmo di hashing utilizzato.
Il laboratorio virtuale è stato costruito interamente in VirtualBox e progettato per simulare una rete aziendale realistica con tre zone di sicurezza distinte, tutte gestite da un firewall pfSense 2.7.2. Le tre reti NAT sono state configurate come segue: una zona WAN che simula la Internet pubblica in cui risiede la macchina attaccante Kali, una zona DMZ che ospita la macchina target e una zona LAN interna contenente macchine fuori scope.``` Internet Zone — NatNetwork (10.0.2.0/24) │ │ Kali Linux 2025.4 [attacker] — 10.0.2.9 │ pfSense WAN interface — 10.0.2.8 │ ├── pfSense Firewall (boundary device) │ ├── DMZ Zone — DMZnat (10.0.4.0/24) │ ├── HackSudo Thor [TARGET] — 10.0.4.3 │ └── DVWA — 10.0.4.4 (out of scope) │ └── LAN Zone — LANnat (10.0.3.0/24) ├── Metasploitable 2 — 10.0.3.5 (out of scope) └── Windows XP Cyberlab — 10.0.3.4 (out of scope)
*Zone di sicurezza della topologia logica di rete gestite da pfSense*
L'interfaccia WAN ha ricevuto `10.0.2.8/24` tramite DHCP, l'interfaccia LAN è stata impostata su `10.0.3.1/24` e l'interfaccia OPT1 (DMZ) su `10.0.4.1/24`. Per introdurre una deliberata misconfigurazione nel laboratorio, la porta 80 è stata intenzionalmente lasciata esposta sull'interfaccia WAN di pfSense, simulando una comune esposizione di pannello di amministrazione riscontrabile nel mondo reale, che ha rappresentato il punto di ingresso primario nella rete interna.
---
## Riepilogo della catena di attacco```
[Kali Linux — 10.0.2.9]
│
│ CSRF-aware Python brute force → admin / pfsense
▼
[pfSense webConfigurator — 10.0.2.8:80]
│
│ Firewall rules disabled → DMZ and LAN now reachable
▼
[HackSudo Thor — 10.0.4.3]
│
│ Shellshock RCE (CVE-2014-6271)
│ Apache mod_cgi → /cgi-bin/shell.sh
▼
[Meterpreter shell — www-data]
│
│ sudo -u thor /home/thor/hammer.sh
│ Command injection via eval → bash -i payload
▼
[Interactive shell — thor]
│
│ GTFOBins: sudo service ../../bin/bash
▼
[Root shell]
│
├── /root/proof.txt captured ✅
├── /etc/shadow + /etc/passwd exfiltrated
└── SSH RSA backdoor planted
Prima di effettuare qualsiasi contatto con l'ambiente target, le informazioni sono state raccolte esclusivamente da fonti pubbliche. Le due fonti principali erano la pagina ufficiale di VulnHub per HackSudo Thor e il profilo GitHub pubblico dell'autore.
La pagina di VulnHub confermava che il target era un sistema basato su Linux, con difficoltà facile-media, con l'obiettivo di trovare il flag proof.txt. La revisione del profilo GitHub dell'autore ha fornito ulteriori indizi. Vishal Waghmare progetta costantemente macchine Linux boot-to-root con l'escalation dei privilegi come sfida centrale in tutta la serie HackSudo. Questo ha plasmato il modello di minaccia in vista delle fasi attive: i servizi HTTP e SSH erano la superficie di attacco più probabile, e si prevedeva che il percorso di escalation coinvolgesse una errata configurazione di sudo, l'abuso di binari SUID o lo sfruttamento di un servizio personalizzato.
Questo tipo di analisi dei modelli dell'autore è importante anche in un impegno reale. Comprendere come il sistema è stato probabilmente progettato e quali categorie di debolezza è probabile che il suo amministratore ripeta fornisce una direzione prima che venga inviato un singolo pacchetto.
| Campo | Dettaglio |
|---|---|
| Target | HackSudo Thor |
| Autore | Vishal Waghmare (@hacksudo) |
| Rilascio | 3 agosto 2021 |
| Difficoltà | Facile-Media |
| OS | Linux (Debian) |
| Formato | VirtualBox OVA |
| DHCP | Abilitato |
| Superficie di attacco prevista | HTTP, SSH, probabile errata configurazione di sudo |
Questa fase ha comportato un contatto attivo diretto con l'ambiente. L'obiettivo era identificare tutti gli host attivi, comprendere il confine di rete e costruire un quadro completo della superficie di attacco prima di concentrare l'attenzione sul target principale.
È stato prima eseguito un ping sweep Nmap leggero (-sn) contro la subnet WAN (10.0.2.0/24) per scoprire host attivi con il minimo rumore. Sono stati identificati tre host: 10.0.2.1 e 10.0.2.2 erano indirizzi infrastrutturali standard di VirtualBox, lasciando 10.0.2.8 come unico host non infrastrutturale. Quella macchina è diventata l'attenzione immediata.
Una scansione SYN stealth completa contro 10.0.2.8 non ha restituito alcun risultato. Era un comportamento previsto, non un errore. I firewall enterprise sono progettati per non rispondere alla scansione delle porte, scartando silenziosamente i pacchetti invece di rispondere. L'assenza di risultati era di per sé la conferma che questo era un dispositivo di confine che filtrava attivamente il traffico.