Riprendono gli studi per OSCE e riparte anche la serie getting-root con symfonos: 5, una macchina pubblicata il mese scorso sul portale VulnHub.

Dopo aver scaricato la macchina da VulnHub, è stata importata all’intero di Virtualbox in esecuzione sulla mia macchina, dove era già pronta e configurata una macchina virtuale Kali Linux che uso abitualmente per lavoro. Entrambe le macchine sono state configurate per essere su una rete interna all’host dove sono in esecuzione, nel mio caso sulla rete 192.168.56.0.

Information gathering

Come prima cosa, facciamo una scansione abilitando i plugin di default sulle porte principali.

nmap -A -T4 192.168.56.120 -oA first

Salvo sempre le scansioni e l’output dei tool, per due ragioni principali:

• ho sempre a disposizione le informazioni senza dover sprecare tempo nel dover rilanciare dei comandi
• in caso di assessment reale, salvando anche i timestamp ho una cronistoria di quello che ho lanciato. In caso di down di un servizio o di una macchina, è quindi possibile risalire a cosa stavo facendo. Succede raramente ma meglio essere previdenti.

Un demone ssh ed un sito web con la particolarità di server LDAP (ed LDAPS) in ascolto.

Il sito web è strano, una gigantografia di Zeus, niente nei commenti della pagina, niente negli header HTTP.

Enumeriamo ulteriormente alla ricerca di URL comuni:

dirb http://192.168.56.120/ -o dirb

Con dirb scopriamo anche un interessante pagina di amministrazione che provo ad sollecitare un po’ ma sembra non essere vulnerabile a SQL injection o Cross site scripting.

Sembriamo essere di fronte ad un punto morto. Non ci sono credenziali di default, non si può bypassare la pagina e non sembrano esserci altre pagine collegate. Penso quindi ad un altro modo per enumerare risorse web: il fuzzing. In questo modo posso trovare, se esistono, pagine web che non sono referenziate dalla prima, a patto di avere un buon dizionario.

Usando wfuzz, scopriamo che esistono altre pagine sul sito, in particolare una pagina di logout e una home.php

wfuzz --hc 404 -w /usr/share/wordlists/wfuzz/general/common.txt http://192.168.56.120/FUZZ.php

Chiamando la pagina home.php, nella risposta vedo che un link è costruito passando una URL alla pagina stessa.

Volevo provare a vedere se la pagina fosse vulnerabile ad una local file inclusion e dal contenuto del file /etc/passwd nella response HTTP, direi che ci siamo.

Accesso non privilegiato

A questo punto, provo a catturare qualche file a caso, tra cui admin.php e faccio una scoperta interessante. All’interno trovo le credenziali con cui l’applicazione fa la bind a LDAP.

Con queste credenziali, provo a collegarmi ad LDAP e sbirciare un po’ al suo interno. Qui trovo i dettagli dell’utente ‘zeus’ del quale avevo visto l’esistenza nel file passwd, tra cui la password.

In questo modo, ho accesso alla macchina come utente non privilegiato e posso iniziare ad enumerare quello che c’è sulla macchina per fare una privilege escalation e diventare root.

Privilege escalation

Dopo aver visto versione del kernel, pacchetti installati e fatta un’idea delle possibili strade da seguire, mi viene in mente di controllare se l’utente zeus può lanciare comandi con sudo.

Lanciando il comando sudo -l, possiamo vedere che l’utente zeus può lanciare dpkg come utente privilegiato.

La prima cosa che ho fatto, a questo punto, è stata andare nella man page di dpkg e vedere se era possibile invocare in qualche modo una shell.

Il comando dpkg ha un’opzione, –pre-invoke, che permette di specificare un comando da eseguire prima di eseguire il task per il quale è stato invocato… bingo.

sudo dpkg --pre-invoke /bin/bash --configure bash

Invocando questo comando, sono stato in grado di elevare i miei privilegi sul sistema e diventare root.

Off by one

La macchina è semplice e non è come quelle che mi troverò di fronte al secondo tentativo per l’OSCE. Tuttavia è stato divertente come esercizio.

Occorre fare attenzione quando si concede l’utilizzo del comando sudo ad utenti sul sistema, affinché non si aprano degli scenari per i quali gli stessi possono eseguire comandri arbitrari sul sistema. Lato difesa quindi, attenzione sempre a cosa concediamo sulle nostre macchine.

Lato attacco… controllate sempre cosa può fare con sudo il vostro utente non privilegiato :)

Enjoy it!