SOLUZIONE Seeweb Hacking Contest 2017: Music Of The Atoms

Seeweb Hacking Contest 2017: Music Of The Atoms

Da Lunedì 15 Maggio 2017 alle ore 10:00 a Mercoledì 31 Maggio 2017 alle ore 10:00 si è svolto l’hacking contest di Seeweb al quale abbiamo avuto l’onore di partecipare. Anche per questa edizione siamo lieti di presentare il nostro writeup degli step necessari a risolvere le varie challenge.

Per ognuna delle 3 manche Seeweb ha inviato una mail con le indicazioni da seguire per iniziare il percorso e la storia ad esso correlata.

Prima manche

Collegandoci a https://hc.seeweb.it/2822022B6D2903C83D30/ ci siamo trovati davanti un puzzle da ricostruire, il quale ci ha fornito un secondo URL da seguire.

puzzle seeweb

Una volta collegati a r3sistance.seeweb.it ci si è presentato una webapp con molte funzionalità, la cui quasi totalità disabilitate.

r3sistance seeweb

La prima cosa che ci ha colpiti è stato un cookie, il quale veniva settato, sempre uguale, una volta che la pagina index.php del sito veniva visitata, così dopo aver provato ad utilizzare tutte le funzionalità del sito abbiamo provato a vedere se venissero alterate in qualche modo nel caso noi modificassimo il cookie.
Dopo un considerevole numero di tentativi abbiamo identificato che la funzionalità di gestione dei documenti, collegandosi con SECRET-KEY anonymous leggeva il parametro spd dal cookie e ritornava una lista dei file presenti nella directory indicata al suo interno.

file upload seeweb

cookie & path traversal seeweb

Grazie a queste informazioni siamo venuti a conoscenza della presenza di 2 script PHP nella medesima cartella di engine.php, di cui conoscevamo la path in quanto era l’endpoint richiamato da tutte le funzionalità della webapp, ovvero authenticated_form_upload.php e authenticated_form_upload.php_old.

Il secondo file, avendo estensione php_old, era scaricabile, infatti il server non lo interpretava come un file eseguibile. Una volta scaricato ne abbiamo analizzato il comportamento.

Come risulta chiaro dal codice era possibile caricare file arbitrari senza autenticazione. Sperando che il file autenticated_form_upload.php si comportasse nello stesso modo, abbiamo scritto una paginetta html che permettesse di effettuare la richiesta POST di upload corretta.

Una volta aperta la pagina html in un browser e selezionata la nostra shell in PHP realizzata con weevely abbiamo effettuato il submit del form ottenendo un corretto upload.

upload shell seeweb

weevely seeweb

Navigando il filesystem abbiamo trovato un archivio ZIP nella root directory chiamato SeewebContestCheckpoint.zip. Dopo averlo scaricato abbiamo notato che lo ZIP era protetto da password, così abbiamo utilizzato John The Ripper per crackarne la password. Dopo qualche ora john ci ha comunicato che la password dello ZIP era abygurl69. A questo punto non era rimasto che estrarlo e prendere la prima flag.

soluzione 1° manche seeweb

Seconda Manche

Collegandoci via SSH ci siamo trovati davanti ad una Debian 8 aggiornata, senza evidenti vulnerabilità, quindi abbiamo effettuato una ricerca di eventuali binari SUID e/o GUID per elevare i nostri privilegi sulla macchina, data la presenza di diverse utenze sulla stessa.

find / -perm -g=s -o -perm -4000 ! -type l -exec ls -ld {} \; 2>/dev/null

Questa semplice ricerca ci ha permesso di identificare la presenza di 5 binary che quando venivano eseguiti dallo user venom giravano con i privilegi dello user enchant.

  • /usr/local/bin/encrypt_communications_genkey
  • /usr/local/bin/encrypt_communications_install_modules
  • /usr/local/bin/encrypt_communications_media
  • /usr/local/bin/encrypt_communications_mngclient
  • /usr/local/bin/encrypt_communications_mnglogs

Abbiamo subito provveduto a scaricarli e ad analizzarli localmente per capirne i comportamenti. Come nel caso della webapp della prima manche, la maggior parte delle funzionalità non erano disponibili / finte. Una delle prime cose che abbiamo notato era la presenza di un controllo per le format string, il quale controllava la presenza di %n e %N all’interno dell’input utente e, se erano presenti almeno in una determinata quantità. bloccava il flusso di esecuzione del programma.

Arrivati ad analizzare il file encrypt_communications_mngclient abbiamo notato una strana funzionalità, la quale dopo aver letto da una variabile d’ambiente una stringa la eseguiva in una execve con i privilegi dell’utente enchant a patto che questa stringa fosse /bin/sh o /bin/bash o /bin/dash, ma solo ed esclusivamente se la funzione sub_400F9B ritornava true, ovvero se veniva rilevato un tentativo di exploitare una format string.

Sfruttare questa vulnerabilità è estremamente semplice, è sufficiente settare la variabile d’ambiente RECOVERY_BIN con /bin/sh al momento dell’esecuzione del binario con le flag -d -t, così che si entri nella funzione func_t_debug() e inserire un payload per far sì che il check della format string ritorni il valore true (es. %n%n%n%N%N%N).

EOP enchant seeweb

Ottenuti i privilegi di enchant abbiamo potuto scaricare ed eseguire un altro binario sempre presente in /usr/local/bin chiamato venom_storage_manager. Una veloce analisi del binario ci ha permesso di identificare la password dell’utente e il contenuto della flag, in questo caso non era necessario eseguire il binario per ottenerla, ma per completezza lo abbiamo fatto.

second flag seeweb

Terza Manche

Appena collegati alla macchina abbiamo eseguito ps aux per vedere i processi in esecuzione e abbiamo notato la presenza di /bin/icaro eseguito dall’utente root.

root 1122 0.0 0.0 4096 1260 ? S May22 0:00 /bin/icaro

Abbiamo provveduto prontamente a scaricare il binario e ad analizzarlo. Per prima cosa abbiamo notato che l’eseguibile bindava la porta 31081 e forkava un processo per ogni connessione alla stessa, di conseguenza per interagire era sufficiente utilizzare il comando nc 127.0.0.1 31081.

icaro seeweb

Dopo aver analizzato il binario abbiamo identificato che impostando come exploit localFileReader ci veniva chiesto il nome del file da leggere e veniva prefisso a questo nome la stringa /tmp/ e suffissa la stringa .tmp, dopodiché all’avvio dell’attacco veniva fatta una __lxstat su quel file, successivamente veniva eseguita una usleep di 333000 microsecondi e infine il file veniva letto e stampato a schermo.
Per exploitare questa race condition era necessario sapere che:

  1. Se il file /tmp/nome.tmp era un symlink la __lxstat ci avrebbe impedito di continuare il flusso dell’esecuzione
  2. Nel tempo in cui la usleep era in corso il check di __lxstat era già avvenuto, ma il file non era ancora stato letto

Ne risulta che il flusso dell’exploit è stato il seguente:

  1. Creazione di un file in /tmp/nome.tmp
  2. Esecuzione di icaro via nc
  3. Selezione del target (inutile ai fini dell’exploit, ma necessario per il funzionamento dell’eseguibile)
  4. Selezione dell’Exploit localFileReader
  5. Esecuzione dell’attacco
  6. Sostituzione del file /tmp/nome.tmp con un symlink ad un file arbitrario negli 0.333 secondi della usleep
  7. Profit

Per svolgere queste azioni in un tempo così ridotto era ovviamente necessario scrivere un piccolo script, ma essendo pigri ne abbiamo scritti 2, il primo per gestire le interazioni con icaro (non era detto che al primo tentativo saremmo riusciti ad exploitare la race condition) e uno per fare la sostituzione continua del file /tmp/nome.tmp con un symlink a /etc/shadow e viceversa.

symlink.sh:

icaro.sh:

Dopo lanciato entrambi gli script e aver aspettato una manciata di iterazioni del secondo ecco comparirci il contenuto di /etc/shadow.

shadow icaro seeweb

Abbiamo subito dato in pasto il file shadow per una decina di minuti a John-The-Ripper, il quale ci ha restituito la password dello user ralph.

ralph password seeweb

Ci siamo quindi collegati al server via ssh con l’utente ralph e la password unicorn8 e abbiamo trovato una serie di file all’interno della suo home che abbiamo provveduto a scaricare.
ralph's home seeweb

I due file più interessanti erano MOTA_control_panel e 1493635127.M427207P24935.biosynthlab.seeweb.it, il contenuto del primo era un semplice link a quantum.seeweb.it, sito dove era possibile caricare un file audio.

quantum seeweb

Il secondo file invece era una e-mail con allegata un’immagine.

mail icaro seeweb

Analizzando l’immagine con binwalk era possibile identificare la presenza dei byte relativi alla fine di un archivio ZIP, data questa informazione abbiamo provato ad estrarre l’immagine con 7z con il comando 7z x ForYou.jpg ed è stato estratto un file chiamato (∂ + m) ψ = 0.m4a. A questo punto è stato sufficiente caricare il file su quantum.seeweb.it per concludere la nosta avventura.

third flag

Ringraziamo Seeweb e Luca Ercoli per la simpatica avventura e speriamo di vedere presto un nuovo CTF marchiato Seeweb.

Classifica

Seeweb ha pubblicato la classifica e abbiamo scoperto di aver vinto tutte e tre le manche!
1° Premio –> Smaury
2° Premio –> Pol
3° Premio –> Pei

finalisti seeweb

gadgets seeweb

Abdel Adim Oisfi

Sono Abdel Adim Oisfi, conosciuto nella rete come "smaury". Lavoro: Co-CEO, Security Researcher, Web Developer, Penetration Tester presso Shielder Srl. Passioni: Hacking, Autostop, Tuffi e Ginocchia Sbucciate.