A case history: CTF Necromancer – Parte 1
You can create art and beauty on a computer
C’è stato un tempo in cui questa frase, nell’underground dell’hacking, faceva parte di una filosofia culturale. Rappresentava un valore morale umanamente condivisibile, simile a una forma d’arte dove creta o argilla, marmo o gesso, prendevano forma per divenire qualcosa di più. Così 0 e 1 rappresentavano l’espressione di una filosofia di libertà, condivisione e pari diritti. Ora che il termine hacker viene associato a criminali che sfruttano una pandemia per rubare soldi o attaccare il sistema sanitario in un momento di crisi, criptando device e strumenti che stanno salvando la vita a diverse centinaia di persone, il caos che gli stessi mass media hanno contribuito a fomentare imperversa celando l’essenziale differenza che separa le due facce della stessa medaglia.
I Capture The Flag (CTF) sono giochi, a volte competizioni, in cui singoli o team di hacking tentano di “catturare la bandiera”, ricercando una vulnerabilità in un dato sistema o in un 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 e DiGiOne, nello specifico con i Proff. Stefano Bistarelli e Francesco Santini, in occasione dell’evento di Cyber Challenge [1], ho avuto il piacere di svolgere in un’aula (virtuale, dati i tempi) una delle CTF che preferisco: The Necromancer, ideata da @xerubus[2]. La mia preferenza nasce sia dal fatto che essa offre l’opportunità di discutere e spaziare fra molti argomenti, sia dall’affascinante ambientazione narrativa. È composta da 11 flag da scovare, in un contesto narrativo “fantasy”. La missione finale? Semplice… distruggere il Necromante!
Quindi, senza indugiare oltre, direi di preparare l’inventario e partire.
FLAG – 01. Intro
“Le prime sparizioni ebbero luogo nelle plumbee giornate di novembre, dove gli astri allineati presagivano orribili e indicibili rituali sulle montagne più a nord del villaggio. Nessuno osava pronunciare il nome dell’antico Re che una volta sedeva sul trono ma che ora asserviva terribili orrori nascosti fra le viscere di quei monti. Ti guardi alle spalle mentre lasci il villaggio ormai quasi abbandonato, dirigendoti verso il sentiero acciottolato che conduce alle montagne. La tua missione: distruggere il Necromante.” |
L’ambiente virtuale creato per l’evento era composto da una macchina attaccante e dalla nostra macchina “target”, Necromancer. La macchina attaccante era una versione dell’ormai celebre Kali Linux e Oracle Virtual Box, l’ambiente di virtualizzazione scelto.
La prima cosa che feci fu utilizzare il comando arp-scan –l (Fig. 2) al fine di identificare i miei dispositivi sulla rete:
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.37?» Riposta: «La macchina è mia! Mi chiamo 08:00:27:28:8c:2b». 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 “Necromante” all’interno della rete: 192.168.178.37.
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 (Figura 3).
La mia fu una ricognizione veloce. Non diedi nessun’altra opzione al comando e il mio port scanning diede esito negativo. Nmap assolve prevalentemente questa funzione: individuare, su un dato dispositivo bersaglio, quali sono le porte aperte e quali servizi di rete ad esse associate sono disponibili. Il comando permette anche di eseguire determinati script, test di vulnerabilità e molto altro. Per il momento, mi limitai a dare una fugace occhiata al nascondiglio del Necromante.
Nessuna porta aperta, almeno apparentemente… nessun ingresso.
A questo punto, non potendo contare sulla “vista”, decisi di ricorrere all’“udito”, ascoltando le strane voci che sibilavano nell’aria.
Wireshark[3] poteva fare al caso mio, e utilizzai la versione da command line (Fig. 4).
Scelsi la mia interfaccia di rete ed effettuai la cattura del traffico dei pacchetti. Tutti i dati che attraversavano la mia rete da un punto di origine ad una destinazione, sarebbero stati catturati e analizzati.
- tshark : mi permetteva di mettermi in ascolto;
- -i : identificava l’interfaccia con cui volevo effettuare il “packet captures”;
- eth0 : il nome dell’interfaccia;
- > ascolto.txt : l’intero output del comando veniva ridirezionato su un file di testo chiamato ascolto.txt.
Infine, una volta che il contatore arrivò a segnare un numero di pacchetti catturati che ritenni sufficiente, effettuai con control+C la terminazione del processo.
Per fare un paragone, l’operazione equivaleva a mettersi in ascolto in un’area affollata di gente e sentire che cosa veniva detto, di cosa si parlava…
Analizzando il file ascolto.txt (Figura 5) tutto pareva alquanto normale (“i soliti rumori di sottofondo”, “il vento che ulula”, “il frascheggiare delle fronde dei rami”) tranne che per un messaggio di broadcast inviato a tutte le macchine della rete, sulla porta 4444, proveniente dal Necromante.
Non mi rimaneva che seguire quella voce e scoprire che cosa dicesse.
Così feci, mettendomi in ascolto sulla porta 4444 (Fig. 6). Per farlo utilizzai netcut: conosciuto come il “coltellino svizzero” nelle reti di calcolatori, esso permette di stabilire una comunicazione remota sia attraverso il protocollo TCP, che UDP.
Quindi esplicitai il mio intento con le opzioni –nlvp:
- -n : esclusivamente da indirizzi IP e non da DNS;
- l : in modalità listening (ascolto);
- v : fornisce dettagli aggiuntivi nell’output del comando;
- p: porta da utilizzare;
- 4444 : la porta da cui volevamo “ascoltare”, da cui giungevano i messaggi.
Il messaggio (Fig. 6) era codificato base64, un sistema di codifica che consente la traduzione di dati binari in stringhe di testo nell’American Standard Code for Information Interchange (ASCII)[4]. Viene usato principalmente nella codifica di dati binari nelle e-mail, per convertire dati nel suddetto formato.
Decodificai il messaggio utilizzando il comando base64 –d (Figura 7), seguito dal file di testo: messaggio4444.txt dove avevo copiato ed incollato il testo codificato (Figura 6).
La decodifica ebbe successo e apparve la mia prima Flag! Con lei, alcuni indizi.
“Benvenuto! Ti ritrovi a fissare l’orizzonte, con nient’altro che silenzio attorno. Guardi ad est, poi a sud, poi ad ovest, tutto ciò che puoi vedere è una grande terra desolata. Girandoti verso nord, noti uno sfarfallio di luce in lontananza. Ti dirigi verso lo sfarfallio, solo per essere fermato da un qualche tipo di barriera invisibile. L’aria intorno a te inizia a diventare più densa e il tuo cuore inizia a battere contro il petto. Ti giri a sinistra…poi a destra! Sei intrappolato! Armeggi nelle tasche…niente! Abbassi lo sguardo e vedi che sei in piedi nella sabbia. Cadendo in ginocchio inizi a scavare freneticamente. Mentre scavi, noti che la barriera si estende sotto terra! Continui freneticamente a scavare e scavare, fino a quando le tue unghie non si impigliano improvvisamente su un oggetto. Scavi ulteriormente e scopri una piccola scatola di legno. flag1 {e6078b9b1aac915d11b9fd59791030bf} è inciso sul coperchio. Apri la scatola e trovi una pergamena con la scritta seguente. “Invoca la stringa: flag1 – u666” |
FLAG – 02
A quanto pare eravamo finiti in trappola…
La Flag 1 recava con sé un hash di qualche tipo: flag1 {e6078b9b1aac915d11b9fd59791030bf} .
Quindi, la prima cosa che feci fu identificare di che tipo di hash si potesse trattare (Fig.8).
Gli algoritmi di hash mappano una stringa di lunghezza arbitraria in una stringa di lunghezza predefinita. A differenza della codifica e della cifratura, sono processi irreversibili. Ad esempio, nel nostro caso, la funzione crittografica di hash prende in input una stringa di lunghezza arbitraria e ne produce un’altra in output a 128 bit. L’output è noto anche come “MD5 Checksum o MD5 Hash”.
Ad esempio la codifica MD5 della frase: “mi ritrovai per una selva oscura, ché la diritta via era smarrita” è: cecd668227b837e56f326beffea802a3
Qualsiasi modifica alla frase (sia essa anche di un solo spazio o di una virgola) produrrebbe un hash completamente differente.
In teoria, se volessimo risalire da un hash alla password, potremmo ipotizzare di prendere un elenco di parole (wordlist) che potrebbero rappresentare la mia password, tradurlo nel corrispondente hash e qualora l’hash della mia password fosse uguale a uno degli hash della mia wordlist, allora avremmo trovato la password.
Per fare ciò utilizzai hashcat, scaricabile all’indirizzo: https://hashcat.net/hashcat/ (Fig. 9).
hashcat64.exe -a 0 -m 0 c:\hashcat_5.1.0\hashflag1.txt c:\hashcat_5.1.0\rockyou.txt -r c:\hashcat_5.1.0\rules\rockyou-30000.rule
- exe : è il comando per lanciare hashcat;
- -a 0 : indica la modalità con cui voglio procedere nell’attacco dell’hash, nel mio caso tramite una wordlist, una lista di parole;
- -m 0 : identifica il tipo di hash che voglio craccare. In accordo con le opzioni di hashcat il formato MD5 è identificato come “0”;
- c:\hashcat_5.1.0\hashflag1.txt : il file .txt che contiene il mio hash (Fig. 8);
- c:\hashcat_5.1.0\rockyou.txt : la lista di parole con cui voglio effettuare il cracking (le mie possibili password);
- -r : identifica che sarà specificato un elenco di regole5, utilizzate come criteri di matching per la mia wordlist, in modo da incrementare le mie possibilità di successo;
- c:\hashcat_5.1.0\rules\rockyou-30000.rule : il file delle regole.
In pochi secondi la password fu craccata (Figura 9 – 10) e il verdetto fu:
Bene, non mi rimaneva che utilizzare il secondo indizio (Figura 7): “Invoca la stringa: flag1 – u666”.
U666 molto probabilmente indicava: “U” stava per User Datagram Protocol (UDP) e 666 era il numero della porta.
Il protocollo UDP consente il trasporto di pacchetti di dati da un Host A ad un Host B ed è utilizzato principalmente per stabilire connessioni a bassa latenza, “tolleranti” alla perdita di pacchetti. Ad esempio, nei giochi online i comandi inviati ad un personaggio per fargli compiere determinate azioni, come quella di muoversi, prescindono dalla ricezione del dato, nel senso che potremmo vedere il nostro alter ego saltare da una zona all’altra senza continuità, perché molti pacchetti UDP inviati sono andati persi.
Ancora una volta mi venne in soccorso netcut, ma questa volta lo utilizzai per connettermi alla posta UDP (Fig. 11):
- -u : connessione ad una porta UDP;
- 168.178.37 : L’IP della macchina a cui desideravo connettermi, quella del Necromante (la mia CTF);
- 666 : Infine, la porta che avevo trovato nell’indizio.
“You gasp for air! Time is running out!” Così, mentre mi affannavo alla ricerca dell’aria, digitai la password che avevo appena craccato: “opensesame” (Fig. 12).
Un forte rombo di tuono echeggia mentre sei in piedi! Stordito, inizi a sentire aria fresca entrare nei tuoi polmoni. Sei libero! Di fronte a te, scritte sulla sabbia, ci sono le parole: flag2 {} c39cd4df8f2e35d20d92c2e44de5f7c6 Mentre ti alzi in piedi, noti che non riesci più a vedere lo sfarfallio della luce in lontananza. Ti giri freneticamente guardando in tutte le direzioni fino a quando, all’improvviso, uno stormo di corvi appare all’orizzonte. Man mano che si avvicinano, puoi vedere uno dei corvi afferrare un oggetto. Nel riverbero del suo riflesso, frammenti di luce si irradiano dalla sua superficie. Lo stormo si avvicina sempre più. Osservando lo stormo di corvi noti la loro particolare formazione. Accecato dalla luce dell’oggetto, strizzi gli occhi, riesci ad identificare la formazione come il numero 80. Appena gli uccelli scompaiono, sei ancora una volta…solo…torturato dal suono assordante del silenzio. 666 è chiusa. |
Scampata per un pelo! Ma ne era valsa la pena, avevo appena conquistato la seconda flag2!
FLAG – 03
Avevo adesso a disposizione un altro hash, simile al precedente, e un numero: 80.
Il numero 80 identifica una celebre porta che utilizziamo di consueto: HTTP – HyperText Transfer Protocol (WWW).
Un altro nmap sulla macchina mi confermò la direzione (Fig. 13):
A differenza della prima volta in cui avevo eseguito l’nmap sul “Necromante” (Figura 3), il risultato fu diverso. La porta 80 risultava “open”.
Senza indugiare oltre, aprii il mio browser e digitai sulla barra degli indirizzi 192.168.178.37 (Figura 14):
Sono passate ore da quando hai iniziato a seguire i corvi. Il silenzio continua ad avvolgerti mentre cammini verso una catena montuosa all’orizzonte. Il tempo passa e ora ti ritrovi di fronte ad un grande abisso. Dall’altra parte del baratro puoi vedere un Necromante in piedi nella bocca di una grotta, che fissa verso il cielo i corvi in cerchio. Mentre ti avvicini all’abisso, una roccia si sposta da sotto i tuoi piedi e cade nelle profondità oscure. Il Necromante ti guarda con occhi vuoti che possono essere descritti solo come morte. Lui sorride nella tua direzione e improvvisamente una luce intensa ti acceca momentaneamente. Il silenzio è interrotto da uno stridio agghiacciante di mille uccelli, seguito dalle risate del Necromante che svaniscono mentre scende nella caverna! I corvi interrompono la loro formazione, alcuni volano senza meta nell’ aria; altri ora sono immobili sul terreno. La grotta è ora protetta da una foschia blu gassosa ed un mucchio organizzato di piume giace davanti a te. |
Fu così che mi trovai dinanzi a un altro enigma…
To be continued…
Riferimenti
- https://cyberchallenge.it/
- https://twitter.com/xerubus
- https://it.wikipedia.org/wiki/Wireshark
- https://it.wikipedia.org/wiki/ASCII
- https://hashcat.net/wiki/doku.php?id=rule_based_attack
Articolo a cura di Vincenzo Digilio
Ha lavorato come Network System Administrator, Security Auditor, System Integrator, Penetration Tester per importanti client, enti governativi ed agenzie spaziali. Seguendo progetti come calcolo distribuito, security resource implementation in aree nuclearizzate, adeguamenti di security policy e Security Engineering per la selezione d’importanti fornitori al fine d’implementare sistemi di sicurezza per diverse Multinazionali. Ha tenuto corsi di tecniche Hacking, studiando in contemporanea per il corso di Laurea in Sicurezza delle reti Informatiche. È attualmente impiegato in progetti classificitati in ambito spaziale di Cyber Sicurezza; nella ricerca di vulnerabilità, sviluppo di exploit e whitebox / black box Penetration Testing. Coordina, inoltre il RedTeam della società Cyber Division di cui e’ uno dei fondatori. È consulente in materia di Global Security Policy Statement, Risk management e Data Breach Investigation. È intervenuto in diversi casi di compromissione dati, analisi forensi, system breach e attacchi hacking al fine di mitigare la situazione. Crede nella libertà d’informazione e nel diritto alla privacy.