A case history: CTF Necromancer – Parte 2

Incipit

L’articolo tratta la seconda parte della CTF Necromancer, tenuta come lezione all’Università di Perugia in occasione dell’evento CyberChallenge: https://cyberchallenge.it/
La prima parte è stata pubblicata qui.

Seguendo i corvi in formazione all’orizzonte, al temine della prima parte eravamo giunti sull’orlo dell’abisso, circondati da nient’altro che il silenzio e le tenebre di un nuovo enigma.

Sulla sponda opposta… la grotta del Necromante.

FLAG – 03.

A una fugace occhiata, premendo F12, non scorsi nulla di particolare nella pagina web (Figura 15).

Ciò che invece attirò la mia attenzione fu l’immagine: pileoffeathers.jpg (Figura 16).

Utilizzai il comando wget per scaricare l’immagine:

• wget : comando
• 168.178.37/pics/pileoffeathers.jpg : il percorso all’immagine.

Una volta scaricata, effettuai l’analisi (Figura 17).

Utilizzai il tool binwalk richiamandolo con l’omonimo comando: esso permette di analizzare file binari per cercare file o codice eseguibile, inoculati all’interno. Difatti, questo tool trova il suo uso principale nell’estrazione del contenuto di immagini firmware.

• binwalk : comando
• jpg : nome dell’immagine da analizzare

Il tool rivelò che all’interno dell’immagine era stato nascosto un archivio .zip.

Sempre utilizzando binwalk procedetti all’estrazione del .zip (Figura 18):

• binwalk : comando
• –dd=’.*’ : estrai dall’immagine i file con una determinata estensione (l’asterisco identificava “ogni tipo di…”)
• jpg : nome dell’immagine da cui estrarre

L’output del comando fu una lista di quattro file (Figura 19). Utilizzando il comando file * (per listare tutti i tipi di file in una directory) mi si presentò l’archivio chiamato 9082.

Non mi rimaneva che procedere all’“unzip” del file (Figura 20).

• unzip : comando di estrazione
• 9082 : nome dell’archivio

Il risultato fu un file di testo “feathers.txt”. Visualizzai il suo contenuto con cat.

Apparve, ancora una volta, una stringa codificata “base64” (Parte I –  Figura 6).

Utilizzai, come avevo già fatto con il primo messaggio, il comando base64 (concatenandolo con il comando cat . (Figura 22).

• cat : visualizza il contenuto del file
• txt : nome del file
• |: operatore di concatenazione “pipe” che permette a due processi separati di comunicare fra di loro
• base64 : comando per la decodifica
• – d : opzioni di decodifica
• ; echo : al termine viene stampato a video il risultato dei comandi

Finalmente, ottenni la mia flag numero 3, seguita dall’ormai consueto hash MD5.

Come avevo già fatto in precedenza, “brut-forzai” l’hashcat, per risalire alla password (Parte I – Figura 9).

FLAG3: 9ad3f62db7b91c28b68137000394639f : 345465869 .

FLAG – 04.

Assieme all’hash c’era anche un altro indizio (Figura 22):

Attraversa l’abisso: /amagicbridgeappearsatthechasm

Aveva tutta l’aria di un percorso all’interno dell’URL conosciuto, così mi addentrai nell’oscurità, aggiungendo il percorso /amagicbridgeappearsatthechasm raggiunsi l’indizio successivo (Figura 23):

Ti fai strada cautamente attraverso l’abisso. Ti trovi su un altopiano innevato, circondato da scogliere di ghiaccio e pietra. La grotta davanti a te è protetta da una sorta di incantesimo lanciato dal Necromante. Allunghi la mano per toccare la foschia blu gassosa e più ti avvicini, più percepisci la vita scorrerti dentro, la tua anima. Immediatamente fai qualche passo indietro dall’ingresso della grotta. Ci deve essere un oggetto magico che potrebbe proteggerti dall’incantesimo del negromante.

L’ispezione alla pagina e l’analisi dell’immagine questa volta non produssero nessun risultato. Dovevo trovare “l’oggetto magico per proteggermi dal Necromante”.

Decisi di provare facendo un brute-force all’URL, per verificare se all’interno di /amagicbridgeappearsatthechasm vi fosse un altro percorso (magari contenente il mio “oggetto magico”).

Utilizzai gobuster, un tool utilizzato per gli attacchi di “forza-bruta” a URL (directory e file) di siti web e sottodomini DNS (Figura 24).

• gobuster : il comando
• dir : seleziona la modalità di brute-force a directory e file
• -u :  specifica l’URL sul quale verrà eseguito l’attacco.
• http://192.168.178.37/amagicbridgeappearsatthechasm/ : l’URL target
• – w: il percorso della lista di parole da utilizzare per l’attacco
• usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt : il percorso del mio file .txt contenente il mio dizionario. In questo caso ne utilizzai uno “standard” chiamato: directory-list-lowercase-2.3-medium.txt

Arrivato circa al 12% dell’attacco, ci fu un riscontro positivo (Figura 25):

Quindi aggiunsi al mio URL il percorso /talisman (Figura 26).

Era l’oggetto magico che cercavo e che molto probabilmente mi avrebbe protetto dai poteri del Necromante.

Una volta scaricato il talismano, notai che si trattava di un file eseguibile. Quindi, dopo avergli dato i permessi d’esecuzione: chmod +x talisman, lo eseguii: ./talisman (Figura 27).

Hai trovato un talismano.  Il talismano è freddo al tatto e non ha parole o simboli sulla sua superficie.  Vuoi indossare il talismano?

Il primo tentativo che feci fu banalmente quello di scrivere “yes” ma ovviamente non successe nulla e l’esecuzione terminò, con un “Nothing happens”. Riprovai mettendo la password che avevo trovato, relativa alla flag 3 (Figura 22). Ma anche questo tentativo cadde nel vuoto.

A questo punto capii che “indossare il talismano” sarebbe stato più ostico del previsto.  Provai allora a provocare nel programma un bufferoverflow (Figura 28):

Questa volta assieme alla scritta “Nothing happens” ne apparve un’altra: “Segmentation fault”.

Non mi dilungherò in spiegazioni sul buffer-overflow, ma se volete saperne di più vi rimando al mio articolo: Let’s Rock! dove spiego di cosa si tratti e come sia possibile sfruttarlo per ottenere una reverse shell.

Nel nostro caso, per analizzare il funzionamento del file “talisman” e poterlo manipolare, utilizzai un “debugger” conosciuto come gdb.

Il primo passo fu avviare il programma con gdb:

• gdb: comando
• talisman : nome del programma da analizzare

Utilizzando info functions diedi un’occhiata alle funzioni del programma.

Fra di esse, ce ne fu una che attirò la mia attenzione:

0x08048a37 chantToBreakSpell (“canta/invoca per spezzare l’incantesimo”).
Così decisi di dare un’occhiata più da vicino e di disassemblare la funzione:

A questo punto la prima cosa che avrei dovuto capire era: quando avveniva il bufferoverflow? Cioè, qual era il numero esatto di lettere “A” che provocava lo straripamento del buffer? Provai a inserire le lettere “A” sino a quando, arrivando a inserirne 32, ottenni l’errore “Segmentation Fault” (Figura 32). Se ne avessi inserite 31 al posto di 32, il programma avrebbe “continuato a funzionare regolarmente”.

Nota: per determinare l’offset avrei potuto procedere, anche (come nell’articolo Let’s Rock), utilizzando i due ruby script contenuti nel framework di metasploit: pattern_create.rb e pattern_offset.rb .

Adesso, non dovevo far altro che sovrascrivere nel registro EIP (“Extended Instruction Pointer” – che controlla l’esecuzione del programma e punta alla prossima istruzione da eseguire) l’indirizzo di memoria della funzione chantToBreakSpell 08048a37 (Figura 30), reindirizzando così il flusso d’esecuzione del programma alla funzione: chantToBreakSpell.

Per farlo scrissi la seguente riga in python:

• python : richiama il comando del linguaggio
• -c : il programma viene passato come stringa
• print : scrivi/stampa
• “A”*32 : satura il buffer di 32 lettere A sino all’indirizzo EIP (il mio offset)
• + : “giunti al registro EIP sovrascrivilo” aggiungendo…
• “\x37\x8a\x04\x08″‘: nel registro EIP inserisci l’indirizzo della funzione chantToBreakSpell
• > overflow: scrivi il seguente comando in un file chiamato overflow

Non mi rimaneva che provarlo. Avviai ancora una volta il debugger (gdb) sull’eseguibile talisman, e questa volta diedi il comando r < overflow.
Lanciai il file overflow che avevo appena creato. Il risultato fu la flag numero 4 (Figura 33):

Nota: ho illustrato il procedimento utilizzato durante la lezione, ma un altro metodo per ottenere la flag4 molto più rapidamente, sarebbe stato (sempre utilizzando gdb):

1. settare prima un brackpoint sulla funzione main, con il comando: b main ,
2. lanciare il programma: run
3. saltare alla funzione chantToBreakSpell utilizzando il comando: jump chantToBreakSpell

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Ti inginocchi… debole e stanco. Alzando gli occhi puoi vedere che l’incantesimo sta ancora proteggendo l’ingresso della caverna. Il talismano ora è quasi troppo caldo per essere toccato! Girandolo vedi le parole ora incise sulla superficie: flag4 {} ea50536158db50247e110a6c89fcf3d3 Invoca queste parole: u31337 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Ancora un altro hash da “brut-forzare”:

FLAG4: ea50536158db50247e110a6c89fcf3d3 : blackmagic

FLAG – 05.

…Ancora un’invocazione: u31337.

Sembrava proprio un’altra porta UDP a cui connettersi (Parte I – Figura 11). Così, come avevo fatto in precedenza, anche questa volta utilizzai netcut.

Non successe nulla, sino a quando (analogamente alla prima volta, Parte I – Figura 12) non digitai la password travata nella flag4: blackmagic (Figura 35)

Mentre invochi le parole, un suono sibilante risuona dalle pareti di ghiaccio. L’aura blu scompare dall’ingresso della grotta. Entri nella caverna e vedi che è debolmente illuminato da torce; ombre che danzano contro il muro di roccia mentre scendi sempre più in profondità nella montagna. Senti strilli acuti provenienti dall’interno della caverna e inizi a percepire una leggera brezza. Gli strilli si stanno avvicinando e con essi la brezza inizia a trasformarsi in un vento gelido. All’improvviso, vieni attaccato da uno sciame di pipistrelli! Ti butti senza meta nell’aria di fronte a te! I pipistrelli continuano il loro attacco implacabile, fino a quando … silenzio.  Guardandoti intorno non vedi alcun segno di pipistrelli e nessuna indicazione della lotta appena avvenuta. Guardando verso una delle torce, vedi qualcosa sulla parete della caverna. Ti avvicini e noti un mucchio di pipistrelli mutilati disteso sul pavimento della caverna. Sopra di loro, una parola impressa nel sangue sul muro

Fine seconda parte – to be continued…

 

Riferimenti

1 – https://cyberchallenge.it/

2 – https://www.ictsecuritymagazine.com/articoli/a-case-history-ctf-necromancer-parte-1/

3 – https://www.ictsecuritymagazine.com/articoli/a-case-history-lets-rock/

 

Articolo a cura di Vincenzo Digilio