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.
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.
Per confermare quali servizi fossero effettivamente in esecuzione senza fare affidamento sulla scansione dei pacchetti, è stata effettuata una richiesta HTTP diretta tramite curl. Questo approccio è stato adottato perché una richiesta web standard ha molte meno probabilità di essere filtrata rispetto a uno strumento di scansione. La risposta è arrivata come HTTP/1.1 200 OK con Server: nginx e un titolo di pagina pfSense, confermando che il webConfigurator era direttamente accessibile sulla porta 80 dall'interfaccia WAN.
Con la pagina di login confermata, il passo successivo era tentare di recuperare le credenziali. Hydra è stato inizialmente selezionato come strumento di brute force, ma questo tentativo è fallito per due motivi. Il primo era pratico: rockyou.txt contiene oltre 14 milioni di voci, rendendolo impraticabile nell'arco di tempo di questa valutazione. Il secondo era tecnico e più significativo: pfSense 2.7.2 implementa la protezione tramite token CSRF, generando un token crittografico univoco a ogni caricamento della pagina, che deve essere inviato insieme alle credenziali. Il modulo HTTP POST di Hydra invia un corpo di richiesta statico e non dispone di alcun meccanismo per recuperare dinamicamente un nuovo token per ogni tentativo, quindi ogni invio veniva rifiutato prima ancora che la password venisse controllata.
Per aggirare il problema, è stato scritto uno script Python personalizzato per replicare l'intero processo di login del browser. Per ogni tentativo di password, lo script apre una nuova sessione, carica la pagina di login, estrae il token CSRF corrente dal modulo HTML e poi invia le credenziali insieme al token esattamente come farebbe un browser. È stata creata una wordlist personalizzata utilizzando CeWL per eseguire il crawling della pagina di login di pfSense ed estrarre termini pertinenti, poi integrata con fasttrack.txt per coprire le credenziali predefinite note.
Lo script ha recuperato le credenziali: admin / pfsense, il default invariato.
Script Python personalizzato che recupera le credenziali di pfSense
Una volta ottenuto l'accesso alla dashboard, la configurazione dell'interfaccia di pfSense è stata esaminata per comprendere l'intera topologia interna. Sono emerse due subnet rimaste invisibili dalla WAN: una LAN su 10.0.3.0/24 e una DMZ su 10.0.4.0/24. Le regole del firewall WAN sono state quindi disabilitate tramite l'interfaccia web e sono state aggiunte due regole di passaggio per consentire il traffico dall'IP dell'attaccante verso entrambe le subnet.
I ping sweep Nmap su entrambe le subnet hanno identificato sei host attivi. Quattro di essi sono stati enumerati ulteriormente, escludendo 10.0.4.1 e 10.0.3.1, che appartenevano alle interfacce gateway di pfSense. È stata eseguita una scansione combinata di enumerazione dei servizi con rilevamento della versione, script NSE predefiniti e fingerprinting dell'OS contro tutti e quattro contemporaneamente. Incrociando i risultati con la ricognizione passiva è stata identificata ogni macchina nella topologia:
Il target è stato confermato come 10.0.4.3. Tutte le attività successive sono state focalizzate esclusivamente su questa macchina.
Identificato il target, è stata eseguita un'analisi più approfondita dei suoi servizi per mappare la superficie di attacco e determinare i possibili percorsi di sfruttamento. Il Metasploit Framework è stato utilizzato come piattaforma principale per questa fase, in particolare perché il suo backend PostgreSQL conserva tutti i risultati delle scansioni tra sessioni, host, servizi e vulnerabilità, tutti memorizzati nel database e disponibili per riferimenti nelle fasi successive senza dover eseguire nuovamente la scansione.
Prima di iniziare, Metasploit è stato inizializzato con msfdb init, la connessione al database è stata verificata con db_status e tutto il lavoro successivo è stato condotto dall'interno di msfconsole.
Il comando db_nmap è stato utilizzato per eseguire una scansione completa contro 10.0.4.3 con scansione SYN stealth, rilevamento delle versioni dei servizi, script NSE predefiniti, fingerprinting dell'OS e tutte le 65.535 porte TCP. I risultati sono stati memorizzati automaticamente nel database e recuperati con hosts e services. Sono stati confermati tre servizi aperti: FTP sulla porta 21 con Pure-FTPd, SSH sulla porta 22 con OpenSSH 7.9p1 e HTTP sulla porta 80 con Apache 2.4.38.
Ogni servizio è stato poi enumerato ulteriormente utilizzando moduli ausiliari Metasploit mirati. Il servizio HTTP ha ricevuto la maggiore attenzione. I moduli dir_scanner e http_crawler sono stati utilizzati per mappare tutti i percorsi e gli endpoint accessibili sul server web. Il risultato più significativo è stata la directory /cgi-bin/ e uno script chiamato shell.sh. Separatamente, una revisione manuale del codice sorgente HTML di news.php ha rivelato un commento nascosto dell'autore che faceva riferimento alla directory /cgi-bin/, un indizio volutamente lasciato per puntare verso una vulnerabilità basata su CGI. Il servizio FTP è stato verificato per l'accesso anonimo (disabilitato) e la stringa di versione è stata annotata per il cross-referencing con le CVE. Il banner SSH è stato recuperato per lo stesso scopo.
Con la superficie di attacco completamente mappata, è stata eseguita una valutazione strutturata delle vulnerabilità utilizzando due approcci: una scansione Nessus automatizzata e il ragionamento manuale dell'attaccante applicato a ciascun servizio.
È stata creata una policy Nessus personalizzata con la scansione CGI e i test delle applicazioni web esplicitamente abilitati, prendendo di mira le porte 21, 22 e 80. Queste impostazioni non sono abilitate per impostazione predefinita e sono state fondamentali in questo contesto; senza di esse, l'endpoint CGI non sarebbe stato testato. La scansione è durata circa 11 minuti e ha restituito 41 risultati complessivi. I risultati sfruttabili erano:
I due riscontri Shellshock su /cgi-bin/shell.sh erano immediatamente la priorità. La CVE-2014-6271 ha un punteggio CVSS di 9.8 e consente l'esecuzione remota di codice non autenticata, il riscontro con il maggiore impatto nella scansione. La CVE-2014-6278 rappresenta una patch incompleta della stessa vulnerabilità, il che significa che anche i sistemi parzialmente aggiornati rimangono sfruttabili. La debolezza Terrapin SSH è stata valutata come non sfruttabile senza una posizione man-in-the-middle. I restanti riscontri non avevano un valore di sfruttamento significativo in questa attività.
Prima di passare allo sfruttamento, il riscontro Shellshock è stato verificato in modo indipendente utilizzando lo script NSE http-shellshock di Nmap mirato direttamente su /cgi-bin/shell.sh. La verifica indipendente prima dello sfruttamento è un passaggio importante della metodologia, poiché conferma che la vulnerabilità è reale e non un falso positivo dello scanner, ed evita di sprecare tempo nel tentare un exploit che non funzionerà. Lo script NSE ha confermato che l'endpoint era vulnerabile e la CVE-2014-6271 è stata selezionata come vettore di attacco principale.
Confermato Shellshock, è iniziata la fase di sfruttamento. La vulnerabilità esiste perché il modulo Apache mod_cgi passa gli header delle richieste HTTP come variabili d'ambiente a Bash quando viene invocato uno script CGI. In una versione non aggiornata di Bash, una definizione di funzione appositamente costruita in una variabile d'ambiente fa sì che qualsiasi comando aggiunto dopo la definizione venga eseguito immediatamente. Iniettando questo payload nell'header User-Agent di una richiesta a /cgi-bin/shell.sh, era possibile eseguire comandi arbitrari sul server senza alcuna autenticazione.
Il modulo Metasploit exploit/multi/http/apache_mod_cgi_bash_env_exec automatizza l'intero processo. Il modulo è stato configurato con RHOSTS impostato su 10.0.4.3, TARGETURI impostato su /cgi-bin/shell.sh, il payload impostato su linux/x86/meterpreter/reverse_tcp e il listener puntato verso la macchina Kali sulla porta 4444. L'esecuzione del modulo ha inviato la richiesta malevola, il server ha eseguito il payload e Metasploit ha ricevuto la connessione in arrivo, stabilendo una sessione Meterpreter come www-data.
Exploit Shellshock eseguito e reverse shell Meterpreter stabilita come www-data
Partendo da www-data, l'entità dell'accesso al sistema era inizialmente sconosciuta. La priorità immediata era comprendere la posizione attuale: chi era l'utente attivo, quali altri account esistevano e quali percorsi erano disponibili verso privilegi più elevati.
La sessione Meterpreter è stata trasformata in una shell di sistema grezza e un pseudo-terminale è stato generato utilizzando il modulo pty di Python per creare un terminale interattivo adeguato. La lettura di /etc/passwd e l'elenco di /home/ hanno confermato la presenza di un utente chiamato thor sul sistema. Un primo ls -la /home/thor/ ha restituito permesso negato, quindi il filesystem è stato cercato per eventuali file di proprietà di thor indipendentemente dai permessi delle directory utilizzando find / -user thor 2>/dev/null. Questo ha individuato un binario anomalo in /usr/local/sbin/ls, un file chiamato ls che non era il binario di sistema standard. Il suo contenuto ha rivelato che si trattava di uno script personalizzato di proprietà di Thor, annotato per un'indagine successiva.
Il passaggio standard post-exploitation di verifica dei permessi sudo dell'utente corrente è stato eseguito con sudo -l. Questo ha rivelato che a www-data era consentito eseguire /home/thor/hammer.sh come utente thor senza richiedere password, una regola NOPASSWD senza alcuna giustificazione operativa legittima.
sudo -l conferma che www-data può eseguire hammer.sh come thor senza password
L'accesso diretto per leggere hammer.sh era bloccato dai permessi delle directory, quindi è stato prima eseguito con sudo -u thor /home/thor/./hammer.sh per osservarne il comportamento. Lo script presentava due prompt interattivi: una "Secret Key" e un "Secret Message". Il primo prompt restituiva l'input come saluto. Il secondo elaborava l'input e poi usciva. La distinzione tra questi due comportamenti era significativa: se entrambi i prompt avessero semplicemente restituito l'input, nessuno dei due sarebbe stato interessante. Il fatto che il secondo prompt elaborasse l'input prima di rispondere suggeriva che stesse passando il valore a un comando shell, un pattern coerente con un'istruzione eval, una superficie di attacco ben documentata per l'iniezione di comandi.
In una seconda esecuzione, è stato inserito un input vuoto al primo prompt. Il payload di iniezione bash -i è stato fornito al secondo. Questo ha generato una shell interattiva come thor.
Payload bash -i iniettato in hammer.sh
sudo -l è stato eseguito di nuovo come thor. Questo ha rivelato accesso NOPASSWD senza restrizioni sia a /usr/bin/cat che a service come root. La regola service era la più significativa. La tecnica sudo service di GTFOBins consente di passare una stringa di path traversal come argomento del nome del servizio. Fornendo ../../bin/bash, il binario service risolve il traversal e invoca /bin/bash con privilegi di root.```bash
sudo service ../../bin/bash
This produced a full root shell.
*Shell di root ottenuta tramite GTFOBins sudo service, path traversal confermato*
## Fase 7: Post-Exploitation
Con l'identità di root confermata, la fase di post-exploitation si è concentrata su tre aree: comprendere l'ambiente di sistema, estrarre dati sensibili e stabilire un accesso persistente.
### Informazioni di sistema e flag
La enumerazione di base del sistema è stata eseguita per prima cosa per confermare l'identità del target e creare il contesto per le raccomandazioni di remediation, inclusi la versione del kernel, la release del sistema operativo e la configurazione di rete. Il sistema è stato confermato come Debian GNU/Linux 10 (Buster) con kernel 4.19.0-17-686-pae su `10.0.4.3`.
È stata elencata la home directory di root, che ha rivelato `proof.txt` e `root.txt`. Il file `proof.txt` è stato letto per catturare la flag primaria, l'obiettivo dichiarato di questo incarico.
*Contenuto di proof.txt: flag primaria catturata*
### Estrazione delle credenziali e cracking delle password
I file `/etc/shadow` e `/etc/passwd` sono stati copiati in `/tmp` e scaricati sulla macchina dell'attaccante tramite Meterpreter. Questi due file insieme forniscono gli account utente del sistema e gli hash delle password necessari per il cracking offline.
Sono stati provati diversi approcci di cracking. John the Ripper ha identificato entrambi gli hash come SHA-512crypt con un fattore di costo di 5.000 iterazioni. Un primo tentativo usando `rockyou.txt` è stato interrotto dopo ore di esecuzione senza risultati. Il costo computazionale di SHA-512crypt rende gli attacchi di dizionario esaustivi molto lenti senza accelerazione GPU. Un secondo tentativo con una wordlist personalizzata e mirata costruita con le informazioni raccolte durante il reconnaissance è terminato rapidamente ma senza corrispondenze.
CrackStation è stato provato successivamente come servizio online di rainbow table, ma ha restituito un formato hash non riconosciuto per entrambe le voci. Questo era previsto: SHA-512crypt aggiunge un salt casuale univoco a ciascun hash prima dell'hashing, il che significa che la stessa password produce un hash diverso per ogni account. Le rainbow table funzionano precalcolando gli hash per password note, ma sarebbe necessaria una tabella separata per ogni possibile valore di salt, rendendo l'approccio del tutto impraticabile contro hash salati.
Hashcat è stato usato per i tentativi finali, con tre wordlist in successione: `fasttrack.txt` (esaurita in 4 secondi), una lista personalizzata mirata (esaurita senza corrispondenze) e le prime 100.000 voci di `rockyou.txt` (fallita dopo 3 minuti). Tutti i tentativi di cracking delle password non hanno avuto successo. L'uso di SHA-512crypt salato con un elevato numero di iterazioni è il motivo l'algoritmo è progettato per essere computazionalmente costoso, proprio per resistere a questo tipo di attacco offline.
### Ricerche di chiavi SSH
È stata inoltre condotta una ricerca nel filesystem per file di chiave privata RSA e certificati PEM usando `find`. Qualsiasi chiave privata trovata avrebbe potuto concedere l'accesso ad altri sistemi che si fidano della corrispondente chiave pubblica, una preziosa opportunità di movimento laterale. Non sono state trovate chiavi private appartenenti ad altri sistemi.
### Distribuzione della backdoor
L'accesso persistente è stato implementato iniettando una chiave pubblica RSA nel file `authorized_keys` dell'account root. L'autenticazione basata su chiave SSH è stata scelta perché non si affida alle password ed è difficile da rilevare a meno che il file `authorized_keys` non venga specificamente controllato. Una coppia di chiavi RSA da 4096 bit è stata generata sulla macchina Kali e la chiave pubblica è stata aggiunta a `/root/.ssh/authorized_keys` sul target con i permessi di directory e file corretti. È stata stabilita una connessione al target usando la chiave privata per verificare che la backdoor fosse funzionante.
*Accesso root persistente confermato tramite autenticazione con chiave privata*
### Automazione
È stato inoltre sviluppato uno script Python personalizzato per l'API RPC di Metasploit (`thor_full_chain.py`) per automatizzare l'intera catena di post-exploitation. Lo script si connette a una sessione RPC di Metasploit live e gestisce l'intera sequenza: stabilizzazione della shell `www-data`, iniezione di `hammer.sh` per escalare a thor, escalation GTFOBins a root, cattura della flag, estrazione delle credenziali e distribuzione della backdoor, con registrazione timestampata salvata in un file locale. Questo è stato un ulteriore deliverable che dimostra la capacità di automazione della catena di attacco tramite l'API RPC di Metasploit. Vedere `scripts/thor_full_chain.py` per l'implementazione completa.
## Fase 8: Copertura delle tracce
La fase finale ha comportato la rimozione delle prove dell'intrusione sia dal sistema target che dalla macchina attaccante Kali. Sul target, il log di accesso di Apache era il file più critico da cancellare, poiché conteneva la richiesta HTTP Shellshock grezza che ha innescato lo sfruttamento iniziale. Il log di autenticazione è stato cancellato, poiché memorizzava ogni comando sudo usato durante la fase di escalation. Il syslog, i file binari di login (`wtmp`, `btmp`, `lastlog`) e la cronologia bash sia per `root` che per `www-data` sono stati sovrascritti e verificati vuoti.
Su Kali, il workspace Metasploit è stato eliminato con `workspace -d default`, i file di credenziali scaricati sono stati rimossi, la coppia di chiavi SSH è stata cancellata e la cronologia bash è stata pulita. Ogni passaggio è stato verificato prima di passare al successivo.
È stata fatta un'eccezione deliberata per la backdoor SSH: i suoi file di chiave associati sono stati conservati sul target e non rimossi in questa fase, poiché erano necessari per scopi dimostrativi nella presentazione della valutazione.
## Vulnerabilità sfruttate
| Vulnerabilità | CVE | CVSS | Componente | Metodo |
|--------------|-----|------|-----------|--------|
| Shellshock RCE | CVE-2014-6271 | 9.8 | Apache mod\_cgi + Bash non aggiornato | Metasploit con header User-Agent malevolo |
| Credenziali predefinite | — | — | pfSense webConfigurator | `admin / pfsense` invariate dopo l'installazione |
| Errata configurazione di sudo (www-data) | — | — | `/etc/sudoers` | NOPASSWD `hammer.sh` eseguibile come thor |
| Iniezione di comandi in hammer.sh | — | — | Script bash personalizzato | Iniezione `eval` tramite payload `bash -i` |
| Errata configurazione di sudo (thor) | — | — | `/etc/sudoers` | NOPASSWD `service` senza restrizioni come root |
---
## Strumenti utilizzati
| Strumento | Scopo |
|------|---------|
| Nmap | Scoperta degli host, scansione delle porte, fingerprinting del sistema operativo, verifica Shellshock NSE |
| Metasploit Framework | Enumerazione basata su database, exploitation, Meterpreter, post-exploitation |
| Nessus Essentials | Valutazione strutturata delle vulnerabilità con scansione CGI e di applicazioni web |
| Hydra | Tentativo iniziale di brute force su pfSense non riuscito a causa della protezione CSRF |
| CeWL | Generazione di wordlist personalizzate tramite il crawling della pagina di login pfSense |
| Python 3 + BeautifulSoup | Script di brute force per pfSense in grado di gestire il CSRF |
| pymetasploit3 | Client API RPC di Metasploit per l'automazione completa della catena di attacco |
| John the Ripper | Cracking offline degli hash SHA-512crypt |
| Hashcat | Tentativi di cracking SHA-512crypt accelerati via GPU |
| CrackStation | Ricerca online nelle rainbow table |
| GTFOBins | Riferimento per la tecnica di escalation dei privilegi sudo service |
| curl | Verifica del servizio HTTP contro la WAN di pfSense |
---
## Raccomandazioni
**Applicate la patch a Bash immediatamente.** La vulnerabilità Shellshock esiste perché Bash non è mai stato aggiornato su questo sistema Debian 10. Eseguire `apt-get update && apt-get upgrade bash` rimuove la vulnerabilità. Oltre alla patch, se gli script CGI non sono operativamente necessari, la directory `/cgi-bin/` dovrebbe essere disabilitata completamente nella configurazione di Apache, rimuovendo la superficie di attacco indipendentemente dalla versione di Bash.
**Controllate e indurite le regole sudo.** Due regole sudo NOPASSWD hanno formato l'intera catena di escalation dei privilegi. Nessuna delle due regole ha una giustificazione legittima. Il file `/etc/sudoers` dovrebbe essere rivisto ed entrambe le voci rimosse. Il principio del minimo privilegio dovrebbe governare qualsiasi futura configurazione sudo; gli account dovrebbero avere solo l'accesso specifico di cui hanno realmente bisogno, niente di più.
**Rimuovete eval dagli script di shell.** Lo script `hammer.sh` passava l'input dell'utente direttamente a un'istruzione `eval` senza alcuna validazione o sanificazione. È questo che ha reso possibile l'iniezione di comandi. L'uso di `eval` dovrebbe essere evitato del tutto negli script di shell che accettano input utente, poiché è quasi sempre una superficie di attacco. L'input dovrebbe essere validato rispetto a una lista consentita rigorosa prima che avvenga qualsiasi elaborazione.
**Cambiate le credenziali predefinite di pfSense e limitate l'accesso.** Il webConfigurator era esposto sull'interfaccia WAN usando le credenziali predefinite invariate `admin / pfsense`. Le credenziali predefinite dovrebbero essere cambiate immediatamente dopo l'installazione. Il webConfigurator non dovrebbe mai essere raggiungibile dalla WAN; l'accesso dovrebbe essere limitato alla LAN o a un'interfaccia di gestione dedicata.
**Implementate il logging centralizzato.** Nella Fase 8, tutti i log locali sono stati cancellati nel giro di minuti, senza lasciare traccia dell'intrusione sul sistema target. Questo ha dimostrato che il target non aveva una gestione centralizzata dei log. In un ambiente di produzione, i log dovrebbero essere inoltrati in tempo reale a un SIEM remoto. Questo garantisce che, anche se un attaccante cancella i log localmente, le prove siano già state preservate fuori sistema e non possano essere manomesse.
---
## Struttura del repository```
hacksudo-thor-pentest/
│
├── README.md
├── report.pdf ← Full penetration testing report
│
├── scripts/
│ ├── pfsense_brute.py ← CSRF-aware pfSense brute force script
│ └── thor_full_chain.py ← Metasploit RPC attack chain automation
│
└── screenshots/
├── network.PNG
│
├── Discovery/
│ └── pfsenselogin.png
│
└── exploit/
├── sheellockexploit.PNG
├── sudol.PNG
├── hammer.bash-i.PNG
├── privilage escaltiontoroot.PNG
├── proof.PNG
└── backdoor.PNG
Questo test di penetrazione è stato condotto esclusivamente all'interno di un ambiente di laboratorio virtuale isolato e autocontenuto realizzato in Oracle VirtualBox. HackSudo Thor è una macchina CTF volutamente vulnerabile pubblicata su VulnHub con lo scopo esplicito di formazione e pratica sulla sicurezza informatica.
| 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 |
| Indirizzo IP | Servizi chiave | OS | Identificata come |
|---|
| 10.0.4.3 | SSH 7.9p1, Apache 2.4.38, FTP | Linux (Debian) | HackSudo Thor |
| 10.0.4.4 | Apache 2.4.29, DVWA v1.10 | Linux (Ubuntu) | DVWA |
| 10.0.3.4 | Microsoft IIS 5.1 | Windows XP/2003 | WinXP Cyberlab |
| 10.0.3.5 | vsftpd 2.3.4, SSH, Apache 2.2.8 | Linux (Ubuntu) | Metasploitable 2 |
| Gravità | Riscontro | CVE | CVSS v3 |
|---|
| CRITICA | Shellshock RCE | CVE-2014-6271 | 9.8 |
| CRITICA | Shellshock Fix Incompleto | CVE-2014-6278 | 8.8 |
| MEDIA | Debolezza SSH Terrapin | CVE-2023-48795 | 5.9 |
| MEDIA | Directory Web Navigabili | — | 5.3 |
| MEDIA | Clickjacking / Nessuna X-Frame-Options | CWE-693 | 4.3 |
| BASSA | Divulgazione Timestamp ICMP | CVE-1999-0524 | 2.1 |