I Capture The Flag (CTF) sono giochi, a volte competizioni, in cui singoli utenti o team di hacking tentano di “catturare la bandiera”: lo scopo è quello di ricercare le vulnerabilità in un dato sistema o software, messo a disposizione dagli organizzatori. Il primo che colleziona tutte le flag nascoste sul sistema bersaglio, vince la competizione. Ne esistono di vari tipi: Attacco e Difesa, Jeopardy e Boot2Root
(per approfondimenti: https://cyberdivision.net/2020/03/13/universita-perugia-ctf/).
In collaborazione con l’Università di Perugia, nello specifico con i Proff. Stefano Bistarelli e Francesco Santini, in occasione dell’evento di Cyber Challenge, ho avuto il piacere di svolgere in un’aula (virtuale, dati i tempi) una delle CTF fantasy che preferisco, basata sull’universo di Game of Thrones (GOT) e ideata da Óscar Alfonso. La mia preferenza nasce sia dal fatto che essa offre l’opportunità di discutere e spaziare fra molti argomenti, sia dall’intrigante ambientazione narrativa.
È composta da 7 flag più 4 extra, per un totale di 11 flag da catturare in un contesto narrativo “fantasy”. La CTF ci permette di trattare diversi temi, di seguito ve ne riporto alcuni (evitando gli spoiler):
- Web Server File Exploitation
- Encryption
- Docker Daemon Privilege Escalation
- FTP
- HTTP
- DNS
- IMAP
- xml
- Weak Hashing Function
- Hosts File
- SQL Injection
- Port Knocking
- GitList Exploitation
La nostra missione? Conquistare i sette regni e distruggere nello scontro finale il Re della Notte.
Senza indugiare oltre, mi addentro nel racconto di quello che è stato il nostro viaggio in questa CTF.
Dopo aver preparato l’inventario, eravamo pronti a partire.
L’ambiente virtuale creato per l’evento era composto da una macchina attaccante e dalla nostra macchina “target”, Game of Thrones, scaricabile al seguente indirizzo: https://www.vulnhub.com/entry/game-of-thrones-ctf-1,201/
La macchina attaccante era una versione dell’ormai celebre Kali Linux e Oracle Virtual Box, l’ambiente di virtualizzazione scelto.
La prima cosa da fare: localizzare il nostro obbiettivo all’interno della rete. Utilizzai il comando
arp-scan –l al fine di mappare tutti i dispositivi:
- arp-scan : comando
- –l ( –localnet) : genera il range di indirizzi partendo da quello dell’interfaccia di rete e dalla netmask
Il protocollo Address Resolution Protocl (ARP) opera al secondo livello del modello ISO/OSI, Data Link (sotto di esso c’è solo il layer fisico). Qualsiasi host che all’interno di una rete voglia conoscere l’indirizzo fisico di un altro host (il MAC Address), invia una “richiesta ARP” in broadcast sulla rete (ad ogni device). In questo modo, tutti i device all’interno della rete ricevono una richiesta con il MAC della macchina da cui essa è stata originata e l’indirizzo IP della macchina del destinatario. L’host che riconosce il proprio IP, risponderà con un “ARP Reply” contenente il proprio MAC, inviandolo direttamente al mittente.
Sostanzialmente, equivale ad urlare in una stanza affollata: «Chi è il proprietario della macchina targata 192.168.178.80?» Riposta: «La macchina è mia! Mi chiamo 08:00:27:a1:26:6a». Se la richiesta venisse eseguita per tutte le auto nel parcheggio, sapremmo a chi appartiene ogni singola macchina.
Analogamente, il comando
arp-scan –l faceva proprio questo, aiutandomi ad identificare il mio obiettivo all’interno della rete: 192.168.178.80.
Nota: lo stesso risultato avrei potuto ottenerlo, ad esempio, con il comando netdiscover.
Una volta identificato il mio obbiettivo, potei cominciare ad “aggirarmici attorno”, studiandolo con nmap:
nmap -p- -sV 192.168.178.80
- nmap : comando
- -p- : tutte le porte
- -sV : rileva, o almeno tenta di rilevare, la versione dei servizi in esecuzione
- 168.178.80 : il mio target
La nostra ricognizione si dimostrò alquanto fruttuosa. nmap individuò sul nostro obbiettivo sia le porte aperte, che i servizi di rete disponibili e ad esse associate (il comando permette anche di eseguire determinati script, test di vulnerabilità e molto altro).
Decisi di partire dalla porta 80, utilizzata come di consueto per il servizio HyperText Transfer Protocol (HTTP).
Quindi lanciai il browser preinstallato sulla mia Kali Linux (firefox) in modalità “private”, con il comando:
firefox - private
Sulla barra degli indirizzi, digitai l’ip della macchina virtuale GOT (il mio target): 192.168.178.80 per giungere sull’ home page della nostra CTF.
Dovevamo adesso ispezionare la pagina.
Creai la mia cartella con mkdir ctf_uni (che da quel momento in poi avremmo usato come repository per tutti i nostri indizi/artefatti) ed una volta al suo interno, scaricai la pagina con il comando wget:
wget http://192.168.178.80/
- wget : comando
- http://192.168.178.80/ : pagina da scaricare
Utilizzai l’editor di testo vim per visualizzarne il contenuto.
vim index.html
All’interno del nostro html scoprimmo le regole della CTF. Ed alcuni indizi:
Stando all’indizio appena trovato potevamo “interagire con tutto, anche la magia o la musica”. In effetti, all’interno del codice HTML, vi era il percorso di due file audio:
Procedetti scaricandoli entrambi e aggiungendo all’Uniform Resource Locator (URL) della pagina home, il loro percorso.
wget http://192.168.178.80/music/game_of_thrones.wav
wget http://192.168.178.80/music/game_of_thrones.mp3
Una volta scaricati utilizzai un tool che consente di leggere, scrivere e manipolare metadati di immagini, audio, video e PDF : exiftool
exiftool game_of_thrones.mp3
E così, proprio all’interno del campo commenti del nostro file mp3, abbiamo scovato la nostra prima flag segreta “SAVAGES”!
Sulla nostra porta 80 poteva celarsi altro, quindi decisi di avanzare facendo un brute-force all’URL, per verificare se all’interno dell’indirizzo http://192.168.178.80/ fossero presenti altre pagine/indirizzi.
Utilizzai per lo scopo un “Content Scanner” basato su “dictionary-attack” contro il nostro web server, la word list preconfigurata era quella presente su Kali al percorso: /usr/share/dirb/wordlists/common.txt
Sostanzialmente, il tool prova tutti i percorsi e sotto percorsi presenti nella wordlist, partendo dal nostro URL target:
dirb http://192.168.178.80/
Il numero 200 è uno dei “codici di stato HTTP”, che sta ad indicare che la richiesta è andata a buon fine (nel nostro caso che la pagina esiste).
Il risultato fu molto proficuo ed evidenziò una serie di sotto URL presenti, fra cui:
- http://192.168.178.80/robots.txt
- http://192.168.178.80/sitemap.xml
- http://192.168.178.80/h/i/d/d/e/n/index.php
Il primo URL che decisi di visitare fu http://192.168.178.80/robots.txt
Il file robots.txt è un file di testo, scritto in ASCII oppure UTF-8 e contenuto nella directory principale del sito, usato per indicare ai crawler dei motori di ricerca (bot) quali pagine o file sono autorizzati a richiedere o non richiedere al sito, per evitare il sovraccarimaneto. Il problema? È un file pubblico.
All’interno del file, due percorsi erano settati come “disallow” per i crawler:
Decisi subito di dare un’occhiata a http://192.168.178.80/secret-island/
Bene! Qualcuno <>, sotto l’immagine era presente un hyperlink che conduceva alla pagina http://192.168.178.80/imgs/map_to_westeros.jpg
Contenente l’intera mappa della nostra CTF
Bene! Qualcuno <>, sotto l’immagine era presente un hyperlink che conduceva alla pagina http://192.168.178.80/imgs/map_to_westeros.jpg
Contenente l’intera mappa della nostra CTF
REGNO | SERVIZIO |
- Dorne | FTP |
- The Wall & The North | HTTP |
- Iron Islands | DNS |
- Stormlands | WEBMIN |
- Mountain and the Vale | POSTGRESSQL |
- The Reach | IMAP |
- Rock and King’s Landing | GITLIST e MYSQL |
Inoltre, vi erano altre 3 flag segrete:
– Secret FLAG : Savages
– Secret FLAG : City of Braavos
– Secret FLAG : Dragonglass Mine
Di queste, una era già stata trovata (SAVAGES) all’interno del file .mp3.
Ed un “EXTRA”, la battaglia finale: Final Battle – SSH
Presi nota della mappa e mi diressi verso il secondo link presente nel file robots.txt: http://192.168.178.80/direct-access-to-kings-landing/ ma senza fortuna. La strada era sbarrata.
Prima di abbandonare il nostro indirizzo, diedi un’occhiata al contenuto dell’HTML, questa volta utilizzando il tasto F12 che permette di richiamare la suite di strumenti per sviluppatori del browser per ispezionare una data pagina. All’interno dell’HTML trovai un indizio:
L’indizio si riferiva alla flag “SAVAGES” che avevamo già fatto nostra.
Tornai quindi sul file robots.txt e decisi di recarmi all’ultimo URL presente al suo interno: http://192.168.178.80/the-tree/
Ma non pareva fossimo i benvenuti:
Difatti, osservando il file robots.txt, lo User-agent per accedere alla pagina /the-tree/ era “Three-eyed-raven”, a differenza delle precedenti dove l’accesso era permesso a chiunque dal parametro asterisco.
User-agent: Three-eyed-raven Allow: /the-tree/
Utilizzai quindi il tool curl (dalla macchina Kali) per identificarmi come “Three-eyed-raven” e visualizzare il contenuto dell’indirizzo: http://192.168.178.80/the-tree/
curl -A "Three-eyed-raven" http://192.168.178.80/the-tree/
- curl : comando
- -A : invia lo user agent al server
- “Three-eyed-raven” : lo user agent
- http://192.168.178.80/the-tree/ : il nostro URL
Curl è un tool (che utilizza le librerie libcurl) a linea di comando, per prelevare o inviare dati (inclusi file) utilizzando la sintassi Uniform Resource Locator (URL).
Una strada alternativa, sarebbe stata quella di editare nei settings del browser la configurazione, aggiungendo un nuovo elemento come “Stringa”: general.useragent.override . Oppure installare un qualsiasi plug-in per effettuare lo switch dello user agent e “re-freshare” la pagina. Il risultato sarebbe stato il medesimo.
All’interno della nostra pagina erano presenti tre importanti indizi:
Dunque, a questo punto, non ci rimaneva che segnare gli indizi sul nostro diario e rimetterci in cammino.
Decisi di tornare al risultato del nostro dirb e proseguire verso il secondo link:
http://192.168.178.80/sitemap.xml
mcrypt è il successore del tool Unix crypt, un encryption tool che usava un algoritmo simile al famoso codice ENIGMA della seconda guerra mondiale, adesso utilizza algoritmi di criptazione più moderni, come AES.
Ma ancora non avevamo trovato nulla da decriptare… Quindi, tenni conto anche di questo nuovo indizio e continuai verso il nostro ultimo indirizzo URL, che dirb aveva scovato e che sembrava essere la “giusta direzione”:
http://192.168.178.80/h/i/d/d/e/n/index.php
All’intento della pagina un nuovo messaggio:
Ottimo! A questo punto avevamo ottenuto anche la password per entrare a Dorne che, come visto dalla mappa, corrisponde al servizio FTP.
Non restava che verificare. Dal terminale della macchina Kali, utilizzai il comando:
ftp 192.168.178.80
Un messaggio mi accolse appena la connessione fu stabilita:
Ma avevo sia lo username che la password! Ovvero:
username: oberynmartell
password: A_verySmallManCanCastAVeryLargeShad0w
Una volta digitati entrai finalmente a Dorne, ottenendo la corrispettiva flag del regno.
Prima di lasciare Dorne però, decisi di fare un breve giro in città per verificare se ci fosse qualcosa di utile per il proseguo della nostra missione. In effetti, digitando il comandols, apparvero sul terminale due file:
- txt
- txt.nc
Uno pareva essere un normale file di testo, l’altro aveva tutta l’aria di essere un file criptato…
Così, prima di avventurarmi oltre, presi una stanza a pochi denari nella città di Dorne per trascorrere la notte e dirimere l’enigma…
To be continued…
