Disclaimer
Questo articolo non vuole essere una guida passo passo sulle operazioni da effettuare per terminare con successo la CTF anche se, tuttavia, sarò obbligato a spoilerare certi passaggi fatti. Come ho già scritto in passato Internet è pieno di tutorial, guide e video sicuramente meglio fatti di quanto potrei fare io.
Lo scopo di questo articolo è duplice:
- porre l’accento sulle fasi da me eseguite
- rileggere i passaggi per ricordarmi e migliorare le tecniche utilizzate
- dare uno spunto aggiuntivo a chi si vuole imbattere in questa box
Fase 1, enumeration
La fase di scansione perimetrale mostra due porte aperte: una Secure Shell e un Apache sulla porta 80.
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
L’apache espone un sito WordPress il quale, dopo una prima fase di enumeration, mostra che ha installato un plugin che presta il fianco ad una vulnerabilità di tipo directory traversal con la quale è possibile scaricare arbitrariamente file dal file system della macchina.
Il primo file scaricato è stato /etc/passwd per enumerare gli utenti presenti, successivamente ho scaricato il file wp-config.php, il file di configurazione del WordPress.
I successivi tentativi non sono andati a buon fine
- tentativo di collegarsi al pannello di controllo del sito mediante le combinazioni di utente / password trovate fino a questo momento
- tentativo di scaricare il file /etc/shadow
- tentativo di scaricare il file .id_rsa dalla home dell’utente (per accedere via SSH)
- brute force sulla Secure Shell (nessun dizionario da me provato ha dato esito positivo)
Trovandomi davanti a un punto morto e non sapendo come procedere ho deciso di passare ad un altro approccio andando a scaricare l’elenco dei servizi in ascolto sulla macchina (/proc/net/tcp) per capire se ci fosse un processo sfuggito alla prima fase di enumerazione. Come volevasi dimostrare il file scaricato mostrava questa stringa
00000000:0539 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000 0 729079 1 0000000000000000 100 0 0 10 0
Stando alla documentazione, il valore 0539 indica in esadecimale il socket in ascolto. Convertendo il valore in decimale il risultato è 1337.
Testando la raggiungibilità della porta remota, questa risultava effettivamente in ascolto.
Per individuare quale servizio fosse in ascolto sulla porta 1337 ho per prima cosa scaricato il file /proc/sched_debug (il quale ha rilevato esserci un servizio chiamato gdbserver in esecuzione su di uno specifico PID) e successivamente, ho scaricato il file /proc/PID/cmdline il quale restituisce in formato esadecimale il comando in esecuzione (e quindi il processo) in ascolto sul socket individuato al passo precedente.
Fase 2, exploitation
Dopo una fase di documentazione e ricerca ho trovato un possibile exploit il quale ha permesso la creazione di una reverse shell sull’host remoto (è stato sufficiente copiarsi lo script python in locale, eseguirlo e seguire le indicazioni).
Qui era presente la prima flag per completare la CTF.
La parte di privilege escalation è risultata essere più semplice del previsto: la procedura che ho seguito consisteva nell’andare ad enumerare tutti gli eseguibili presenti a sistema, di proprietà dell’utente root con flag SUID abilitato che potessero lanciare un processo con i suddetti permessi (consiglio la lettura di questo articolo introduttivo).
Terminato il comando ecco come si mostrava la shell
Considerazioni personali
Dal mio punto di vista la parte complessa di questa CTF è stata la fase di enumeration dei servizi che ha permesso di scoprire il socket sul quale il processo gdbserver era in ascolto.
Sicuramente una scansione massiva di tutte le porte avrebbe rivelato anche la 1337 ma, normalmente, essendo una tecnica che prende parecchio tempo, non la uso mai. Magari quando mi troverò in fase di stallo (o magari durante altre operazioni lunghe) potrei eseguirlo in background.
EOF