Red Hot Cyber
La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.
Manuel Roccon : 12 Gennaio 2024 09:51
In questo articolo continueremo a scoprire le funzionalità del framework metasploit. Abbiamo già compromesso la macchina di cui avevamo diretto accesso, ora esploreremo questa macchina per cercare di compromettere la rete interna che si nasconde dietro non accessibile direttamente dall’attaccante.
A questo punto proseguiamo con il nostro percorso e verifichiamo cosa si nasconde nelle interfacce di rete. Dalla sessione acquisita prima avviamo una shell.
Abbiamo detto che la macchina che dovremo collegarci è collegata a un’altra rete alla macchina che abbiamo già compromesso, quindi verifichiamo le interfacce di rete tramite ip addr (dalla sessione meterpreter possiamo fare la stessa cosa con il comando ).
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:
root@ubuntu:/tmp# ip addr
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:e1:0a:75 brd ff:ff:ff:ff:ff:ff
inet 192.168.83.139/24 brd 192.168.83.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fee1:a75/64 scope link
valid_lft forever preferred_lft forever
3: eth1: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:e1:0a:7f brd ff:ff:ff:ff:ff:ff
inet 192.168.9.130/24 brd 192.168.9.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fee1:a7f/64 scope link
valid_lft forever preferred_lft forever
meterpreter > ifconfig
Interface 1
============
Name : lo
Hardware MAC : 00:00:00:00:00:00
MTU : 65536
Flags : UP,LOOPBACK
IPv4 Address : 127.0.0.1
IPv4 Netmask : 255.0.0.0
IPv6 Address : ::1
IPv6 Netmask : ffff:ffff:ffff:ffff:ffff:ffff::
Interface 2
============
Name : eth0
Hardware MAC : 00:0c:29:e1:0a:75
MTU : 1500
Flags : UP,BROADCAST,MULTICAST
IPv4 Address : 192.168.83.139
IPv4 Netmask : 255.255.255.0
IPv6 Address : fe80::20c:29ff:fee1:a75
IPv6 Netmask : ffff:ffff:ffff:ffff::
Interface 3
============
Name : eth1
Hardware MAC : 00:0c:29:e1:0a:7f
MTU : 1500
Flags : UP,BROADCAST,MULTICAST
IPv4 Address : 192.168.9.130
IPv4 Netmask : 255.255.255.0
IPv6 Address : fe80::20c:29ff:fee1:a7f
IPv6 Netmask : ffff:ffff:ffff:ffff::
Ci appare subito la seconda scheda di rete con un’altra subnet (192.168.9.0/24).
La rete ovviamente è collegata solo alla macchina che abbiamo compromesso e non possiamo raggiungerla direttamente dalla nostra macchina attaccante.
Per questo dobbiamo forzare metasploit ad utilizzare la sessione già aperta sulla macchina intermedia per fare da “ponte” e poter far arrivare le richieste alla rete remota, il pivoting.
Per fare questo usiamo il modulo post/multi/manage/autoroute che individua automaticamente le subnet (reti) remote esistenti sulla sessione in esecuzione nella macchina Linux e imposterà automaticamente le rotte per poter raggiungere le reti remote all’interno di metasploit.
Per questo modulo dobbiamo configurare solo la sessione dove il modulo configurerà le rotte per far passare il traffico remoto.
Come possiamo vedere sono state configurate delle subnet remote tramite la session 3.
A questo punto la nostra console di metasploit saprà che per raggiungere la macchina remota con IP 192.168.9.X dovrà passare per la sessione 3.
Eseguendo il comando route print possiamo verificare le rotte impostate.
Così facendo ricordiamo che potremmo raggiungere la subnet remota solo all’interno di metasploit.
Durante information gathering è molto utile poter usare altri strumenti come nmap. È chiaro che dobbiamo riuscire a dialogare la nostra shell locale di kali dove avvieremo i vari tool, verso la subnet remota.
Per fare questo possiamo attivare un proxy all’interno di metasploit (tramite una porta locale) e con l’ausilio di un tool chiamato proxychain ci permetterà di poter dialogare con la rete remota.
Quindi avviamo il modulo post/multi/manage/socks_proxy per aprire questo socket, che farà da tramite per inviare le richieste della nostra macchina kali tramite la sessione di metasploit, con l’aiuto di un altro tool proxychain.
Andiamo quindi a impostare i parametri
La porta non andiamo a impostarla ma di default è la 1080.
E avviamo il proxy in background (exploit -j).
Allo stesso tempo configuriamo proxychains nell’inviare il traffico alla porta e il socket locale che abbiamo avviato.
Per fare questo modifichiamo il file di configurazione come mostrato sotto.
Ora possiamo avviare qualunque comando usando “proxychain comando”.
In questo caso eseguiamo la scansione delle prime 20 porte della subnet remota.
Dopo aver concluso la scansione ci verranno restituite le informazioni delle prime 20 porte aperte di un host remoto al ip 192.168.9.50.
Analisi ci restituisce delle porte aperte interessanti, tra cui SMB ed RDP.
Ora ci concentriamo sul asset trovato scansionando possibili vulnerabilità tramite il motore script di nmap (–script=vuln).
Alla fine della scansione ci vengono restituite alcune vulnerabilità.
In particolare:
Inoltre, ci viene confermato che si tratta di un sistema windows.
Abbiamo parlato di poter scansionare una rete remota tramite comandi esterni a metasploit.
Possiamo usare anche diversi comandi ausiliary come l’utilizzo del modulo “auxiliary/scanner/portscan/tcp”.
Oppure il modulo “auxiliarysmb/smb_version”.
Abbiamo individuato anche una porta RDP, possiamo provare a collegarci tramite proxychains per vedere il corretto funzionamento.
Questo test ci conferma che siamo di fronte a Windows XP e proxychan riesce a farci collegare in RDP tramite la sessione di metasploit.
A questo punto avendo le informazioni di 2 vulnerabilità sfruttabili, proviamo a sfruttare la ms17-010 rilevata durante la scansione.
Cerchiamo la vulnerabilità in metasploit (search), come fatto in precedenza.
Ci vengono restituiti vari moduli, scegliamo di usare il modulo exploit/windows/smsb/ms17_010_ethernalblue.
Verifichiamo un attimo i parametri necessari
Quindi impostiamo IP del host remoto, quello locale e avviamo exploit.
Ci accorgiamo che qualcosa viene fatto, sembra funzionare, ma la sessione remota fallisce.
Ora l’importante è non arrendersi e cercare di capire il motivo…
Tutto nasce dal tipo di payload, di default viene adottato una reverse shell.
Questo vuol dire che una volta avviato il payload, host remoto (windows) cercherà di connettersi all’host attaccante (kali) per stabilire una connessione.
In una situazione in cui host attaccato possa raggiungere host attaccante, per esempio, tramite la connessione internet, le reverse shell funzionano (a meno che non ci siano dei blocchi ad esempio firewall).
In questo caso nel laboratorio, l’host nella rete privata è stata volutamente isolata con esterno per creare un ulteriore difficoltà, per cui questa macchina non potrà mai comunicare direttamente con noi.
Nella macchina è stato proprio omesso il gateway, per cui per nessun modo la macchina potrà comunicare con una rete diversa dalla 192.168.9.X.
Per cui usare un bind è la soluzione migliore.
Con il bind, la macchina attaccante si metterà in ascolto di una nostra connessione, che transiterà tramite la macchina compromessa.
Qui uno schema semplificato sulla reverse o bind shell, la X nella reverse shell indica che la nostra macchina compromessa non può tentare di contattarci.
Nel bind invece l’attaccante, dopo aver messo la vittima in ascolto, la raggiungerà direttamente tramite pivoting.
REVERSE
BIND
Quindi cambiamo il payload usato (set payload windows/meterpreter/bind_tcp) e riavviamo exploit.
A questo punto abbiamo una nuova sessione remota (sessione 4), con utente NT AUTHORITY\SYSTEM.
A questo punto eseguiamo dell’information gathering.
Usiamo estensione incognito per poter vedere quali utenti possiamo personalizzare.
Impersonalizzazione ci permetterà di assumere i permessi e diritti di un altro utente.
Estensione caricherà una funzionalità aggiuntiva tramite il comando use, e in seguito usiamo list_token -u.
Non ci risulta interessante quindi proseguiamo.
Usiamo l’estensione kiwi (mimikatz), per tentare di individuare hash e password.
Per fare ciò ci serve un utente con permessi elevati, system ce li ha quindi possiamo proseguire.
Troviamo quindi hash LM e NTLM e fortunatamente anche la password in chiaro dell’utente administrator.
A questo punto abbiamo scoperto la password di amministratore.
Eseguiamo il dump SAM.
A questo punto avendo individuato la password, proviamo a collegarci in RDP.
E otteniamo la console come administrator.
Abbiamo completamente preso il possesso della macchina, obiettivo riuscito!
Ora vediamo alcuni comandi aggiuntivi che ci possono tornare utili per un post exploit in Windows.
Come prima cosa possiamo avviare la shell da meterterpreter come visto in precedenza.
Possiamo verificare gli exploit attivabili tramite il modulo post/multi/recon/local_exploit_suggestor.
Enumerare i software installati tramite il modulo post/windows/gather/enum_application.
Verificare gli utenti attualmente connessi tramite il modulo post/windows/gathering/enum_logged_on_users.
Estrarre hash delle password tramite post/windows/gather/hashdump.
Verificare se ci sono credenziali salvate tramite post/windows/gather/credentials/credentials_collector.
Verificare se ci sono condivisioni attive, post/windows/gather/enum_shares.
MIGRATE
Ora ci soffermiamo su un comando importante che ci può tornare utile per due motivi principali.
Il primo è poter impersonalizzare un altro utente.
Utilizziamo il comando ps per vedere tutti i processi che stanno girando sulla macchina.
Ora utilizziamo il comando migrate e il processo con utente Administrator
Si può vedere che adesso stiamo operando non più dall’utente SYSTEM ma ADMINISTRATOR (si può ottenere la stessa cosa tramite il modulo metasploit incognito)
Questo comando puà tornare utile anche nel caso stessimo sfruttando un exploit in cui il cui processo terminerebbe a causa di un timeout (es. una reverse shell avviata da una pagina web), eseguendo il migrate potremmo spostare l’esecuzione in un altro processo appena ottenuto il controllo.
PASS-THE-HASH
Ora vediamo un altro e ultimo punto interessante, accesso alle risorse tramite pass the hash.
Supponiamo che un altro sistema adiacente abbiamo scoperto hash NTLM di un utente administrator, con accesso tramite pass-the-hash passando direttamente hash in fase di login possiamo riuscire ad accedere al sistema.
Ci sono vari tool per farlo come psexec.py, pth-winexe o win-exe.py e anche dei moduli da utilizzare direttamente con metasploit.
Vediamo subito che utilizzando e configurando il modulo exploit/windows/smb/psexec, possiamo ottenere la shell meterpreter solo sapendo nome utente e hash ntlm
Verifichiamo i parametri disponibili
Impostiamo i parametri e avviamo exploit.
A questo punto otteniamo una sessione di meterpreter partendo dagli hash LM e NTLM.
La stessa cosa possiamo farla con il tool wmiexec.py, ovviamente utilizzando proxychains in quanto il sistema non è direttamente comunicante con il nostro.
In entrambi i casi, avendo una sessione amministrativa, potremmo cambiare la password oppure, meglio, creare un nuovo utente administrator, nel nostro caso poi facendo escalation tramite la sessione RDP.
Siamo alla fine di questo esempio creato in laboratorio utilizzando Metasploit. Abbiamo esplorato i vari moduli, comandi e funzionalità per compromettere 2 macchine utilizzando anche il pivoting.
Questa è stata una rapida scorsa al funzionamento di questo framework, di cose ce ne sarebbero ancora da analizzare e scoprire.
Lascio qui sotto il link alla documentazione per chi fosse interessato ad esplorare altri aspetti:
Manuel Roccon