HackDay Albania
Tempo di lettura: 8 minutiData pubblicazione: June 30, 2017
Il confine tra un sistema sicuro e uno insicuro è, nella maggior parte dei casi, molto labile, separato solo da un filtraggio mancante, una password poco sicura, un permesso errato. Ed è proprio a causa di quest’ultimo che ho ottenuto i permessi di root nella macchina virtuale HackDay: Albania 2016.
Come sempre, per chi fosse la prima volta che legge un Walkthrough di questo genere, consiglio Kioptrix 1, in cui vengono elencati i passi fondamentali da compiere per violare un dispositivo di questo tipo.
Scansione
Solitamente eseguo prima una scansione veloce di tutte le porte (è incredibile la fantasia con cui vengono scelte le porte per le macchine virtuali di Vulnhub), prima di passare ad una scansione approfondita (nel caso in cui non trovi nulla).
mrtouch@mrtouch:~$ nmap -sT -p- 192.168.56.102
Starting Nmap 7.01 ( https://nmap.org ) at 2017-06-29 17:45 CEST
Nmap scan report for 192.168.56.102
Host is up (0.0012s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE
22/tcp open ssh
8008/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 14.85 seconds
In questo caso mi è andata bene, alla porta 8008 dovrebbe esserci un applicazione web.
Footprinting ed enumerazione
La frase sembra aver poco senso, secondo il traduttore significa Se io sono, io so dove andare;). La prima azione da eseguire è un footprinting e scansione dei file interessanti, guardando nel codice sorgente della pagina o utilizzando dei software automatici.
Visto che non c’è pericolo di generare alert o essere rintracciati, eseguo una ricerca dei file con il tool dirsearch
Sembra esserci poco o niente, a parte il classico file robots.txt. Dando un occhio al file, sembra che abbiamo trovato il primo indizio!
Disallow: /rkfpuzrahngvat/
Disallow: /slgqvasbiohwbu/
Disallow: /tmhrwbtcjpixcv/
Disallow: /vojtydvelrkzex/
Disallow: /wpkuzewfmslafy/
Disallow: /xqlvafxgntmbgz/
Disallow: /yrmwbgyhouncha/
Disallow: /zsnxchzipvodib/
Disallow: /atoydiajqwpejc/
Disallow: /bupzejbkrxqfkd/
Disallow: /cvqafkclsyrgle/
Disallow: /unisxcudkqjydw/
Disallow: /dwrbgldmtzshmf/
Disallow: /exschmenuating/
Disallow: /fytdinfovbujoh/
Disallow: /gzuejogpwcvkpi/
Disallow: /havfkphqxdwlqj/
Disallow: /ibwglqiryexmrk/
Disallow: /jcxhmrjszfynsl/
Disallow: /kdyinsktagzotm/
Disallow: /lezjotlubhapun/
Disallow: /mfakpumvcibqvo/
Disallow: /ngblqvnwdjcrwp/
Disallow: /ohcmrwoxekdsxq/
Disallow: /pidnsxpyfletyr/
Disallow: /qjeotyqzgmfuzs/
Sono tutte directory esistenti nell’applicazione e che, ipoteticamente, dovremmo testare una ad una per visualizzarne il contenuto. In questo caso ho utilizzato il software ZAP, il quale, in modo automatico, ha eseguito la scansione di ogni cartella ritornando la grandezza e la risposta di ognuna
Seguendo il percorso, ci si trova davanti ad una pagina di autenticazione (Secure client login)
Uno dei problemi maggiori in questo tipo di richieste è SQL Injection, quindi con sqlmap andiamo ad attaccare il form.
mrtouch@mrtouch:~$ sqlmap -u "192.168.56.102:8008/unisxcudkqjydw/vulnbank/client/login.php" --data="username=QUI&password=QUI" --level 5 --risk 3 -a
Come prima, non ci sono problemi a generare migliaia di richieste, visto che è un dispositivo offline e utilizzato come testing.
Sembra che non sia riuscito ad ottenere nessun database, quindi provvedo ad eseguire il login con il vettore di attacco che fornisce sqlmap.
Nella schermata della banca c’è un unica possibilità. ossia quella di caricare immagini fornendo una descrizione del problema. Come abbiamo visto nell’articolo File Upload, possiamo provare ad aggirare il controllo e caricare una shell rinominandola con l’estensione di un immagine (il file utilizzato è questo).
Accesso alla shell
Per ottenere la shell basta porsi in ascolto sulla porta impostata nel file reverse-shell e cliccare su View Ticket nell’applicazione
Con qualche comando abbiamo scoperto che siamo l’utente www-data e il kernel di Linux è 4.4.0-45. Purtroppo sembra che non abbiamo alcun accesso ad altre cartelle al di fuori dei file dell’applicazione e altre poco utili. Bisogna quindi trovare un modo per ottenere i privilegi di amministrazione.
Privilege escalation
La prima idea che ho avuto è stata quella di cercare degli exploit con searchsploit, ma a quanto pare ho perso solo tempo, visto che nessuno di essi ha funzionato. Un’altra via è quella di cercare all’interno della macchina file particolari e vedere se si possono trovare altri indizi. Navigando nelle varie directory è balzato all’occhio il file passwd, più precisamente, i permessi dello stesso.
Nei nuovi sistemi il file /etc/passwd non contiene più le password, ma solo gli utenti presenti nel sistema e altre informazioni più o meno utili. Ma il fatto che sia scrivibile da un qualsiasi altro utente pone un problema enorme alla sicurezza della macchina, poiché mi basta modificare la riga di root ed ottenere l’accesso. La riga di root è definita come
root:x:0:0:root:/root:/bin/bash
dove x significa che la password è salvata nel file shadow. Ma se inserisco un hash definito da me, il sistema utilizza quello e non analizza più la password originale! Per avere l’hash si possono sfruttare diversi metodi, tra cui questi, generare sul proprio dispositivo un utente con una password conosciuta, o addirittura copiare la password che utilizziamo sul nostro computer Linux presente nel file shadow. Nel mio caso ho generato un hash basandomi sulla chiave password.
$ cat /etc/passwd
root:$1$dFS/e90h$Zm2vVzD5ajgAZfKXGtpm//:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
.....
Ed ora eseguo il login dalla macchina virtuale
Conclusioni
Sfida a tratti banale (directory in robots.txt, SQL Injection in un form), ma si è rivelata interessante proprio per l’ultima fase, dove per un “piccolo” permesso, siamo passati da un utente con pochissimi permessi all’amministratore completo del sistema.
