Capture The Flag: così i team di hacking individuano le vulnerabilità in software e sistemi

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
• Boot2Root

Capture The Flag: l’universo di Game of Thrones

In collaborazione con l’Università di Perugia (e 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 Capture The Flag 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
• Sitemap.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.

Capture The Flag: iniziano i giochi

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.

Figura 1.

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.

La macchina attaccante era una versione dell’ormai celebre Kali Linux e Oracle Virtual Box, l’ambiente di virtualizzazione scelto.

Figura 2.

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

Figura 3.

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 a identificare il mio obiettivo all’interno della rete: 192.168.178.80.

Da segnalare, comunque, che lo stesso risultato poteva essere ottenuto, ad esempio, con il comando netdiscover.

Studiamo il nostro obiettivo

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
  • 192.168.178.80 : il mio target

Figura 4.

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.

Figura 5.

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) e, 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

Figura 6.

Utilizzai l’editor di testo vim per visualizzarne il contenuto.

vim index.html

Le regole dalla Capture The Flag

All’interno del nostro HTML scoprimmo le regole della CTF. Ed alcuni indizi:

Figura 7.

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:

<source src=”music/game_of_thrones.wav” type=”audio/wav”>

<source src=”music/game_of_thrones.mp3” type=”audio/mp3″>

Figura 8.

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 il tool exiftool che consente di leggere, scrivere e manipolare metadati di immagini, audio, video e PDF:

exiftool game_of_thrones.mp3

E così, proprio all’interno del campo commenti del nostro file MP3, avevamo scovato la nostra prima flag segreta SAVAGES.

Figura 9.

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 a indicare che la richiesta è andata a buon fine (nel nostro caso che la pagina esiste).

Figura 10.

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

La funzione dei file robots

Il primo URL che decisi di visitare fu http://192.168.178.80/robots.txt.

Figura 11.

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 sovraccaricamento. Il problema? È un file pubblico.

All’interno del file, due percorsi erano settati come “disallow” per i crawler:

Disallow: /secret-island/

Disallow: /direct-access-to-kings-landing/

Decisi subito di dare un’occhiata a http://192.168.178.80/secret-island/.

Figura 12.

Bene: qualcuno <<voleva essere nostro amico>>, 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.

Figura 13.

Analizzando la mappa è emerso che:

• le 7 flag principali erano associate ai regni, ogni regno era rappresentato da un servizio su una specifica porta (come avevamo visto anche dall’nmap). Ricapitolando:

Vi erano anche 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 (figura 9).

Ed inoltre, vi era un “EXTRA”, la battaglia finale:

• Final Battle – SSH

Presi nota della mappa e mi diressi verso il secondo link presente nel file robots.txt (figura 11): http://192.168.178.80/direct-access-to-kings-landing/ ma senza fortuna. La strada era sbarrata.

Figura 14.

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” (figura 9) che avevamo già fatto nostra.

Tornai quindi sul file robots.txt (figura 11) e decisi di recarmi all’ultimo URL presente al suo interno: http://192.168.178.80/the-tree/.

Ma non pareva fossimo i benvenuti:

Figura 15.

Decisi, come fatto in precedenza, di dare un’occhiata alla pagina premendo il tasto F12.

Difatti, osservando il file robots.txt (figura 11), 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

Figura 16.

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.

Figura 17.

All’interno della nostra pagina (figura 16 o 17) 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 (figura 10) e proseguire verso il secondo link: http://192.168.178.80/sitemap.xml.

Figura 18.

sitemap.xml è un file in formato xml che funge da “roadmap” del sito. Esso contiene un elenco di URL che si intende inviare ai motori di ricerca, affinché vengano indicizzate. Per URL è possibile specificare immagini presenti, data di aggiornamento, frequenza e via dicendo.

Al suo interno vi era indicato l’URL: <loc>raven.php</loc> e difatti, quando mi recai all’indirizzo http://192.168.178.80/raven.php mi si parò dinanzi un corvo, con un messaggio (per visualizzarlo ispezionai ancora una volta la pagina del browser con F12).

Figura 19.

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.

Figura 20.

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 (figura 13), 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 (figura 16/17) che la password (figura 20). Ovvero:

• username: oberynmartell
• password: A_verySmallManCanCastAVeryLargeShad0w

Una volta digitati entrai finalmente a Dorne, ottenendo la corrispettiva flag del regno.

Figura 21.

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 comando ls, apparvero sul terminale due file:

• problems_in_the_north.txt
• the_wall.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…