Tra le diverse attività che può eseguire un criminale all’interno di una rete informatica aziendale, così come può fare un dipendente infedele o un attaccante esterno che controlla una macchina compromessa tramite botnet, c’è sicuramente lo sniffing delle credenziali degli utenti.
Se la cosa può sembrare di difficile attuazione o complessa, e per taluni attacchi lo è davvero, grazie alla presenza di due protocolli insicuri abilitati di default da Windows, si dimostra invece molto semplice e realizzabile ancora in molte, troppe, realtà aziendali. Se è vero che si è scritto di questo attacco già dal 2001 o forse prima, per lo più solo in lingua inglese, è altresì vero che sono ancora molte le aziende e i responsabili IT che ne hanno scarsa consapevolezza. Sto infatti riscontrando una buona riuscita di questo attacco in tutte le realtà in cui eseguo attività di Penetration Testing interno in qualità di Red Teamer di 3C N-SOC, azienda per cui lavoro. Credo, per tale motivo, che sia importare far conoscere questa minaccia e mettere in guardia gli amministratori di rete e le aziende che ancora la ignorano, consigliando al contempo le opportune azioni per prevenirla.
I protocolli LLMNR (Local-Link Multicast Name Resolution) e NBT-NS (NetBIOS Name Service) sono due protocolli abilitati di default sui sistemi Windows e il loro scopo, apparentemente innocuo, è quello di intervenire in supporto del Sistema Operativo quando non è in grado di risolvere un nome Host tramite il servizio DNS o tramite il suo file Host locale. LLMNR, introdotto con Windows Vista è il successore di NBT-NS e si basa sul formato DNS (Domain Name System) che consente agli Host presenti sulla stessa rete locale di eseguire la risoluzione dei nomi per altri Host. NBT-NS, invece, identifica i sistemi tramite il loro nome NetBIOS.
Sappiamo che la ricerca del nome Host può fallire, ad esempio, se i server DNS non sono raggiungibili, spenti o mal configurati, ma anche se l’utente digita il nome Host in modo errato. In quest’ultimo caso, infatti, pur essendo disponibile un server DNS, questo non sarà comunque in grado di dare una risposta al sistema richiedente.
Inoltre i sistemi Windows configurati per rilevare automaticamente i proxy Web (protocollo Web Proxy Auto Discovery – WPAD), in un ambiente senza un proxy Web tenteranno di risolvere il nome Host “wpad” senza riuscirci. Anche i browser utilizzano il protocollo WPAD e Internet Explorer ce l’ha abilitato di default.
Ci sono poi diverse applicazioni che tentano di risolvere nomi Host inesistenti. Il browser Google Chrome, ad esempio, tenterà di risolvere tre nomi di dominio casuali ogni volta che viene caricato come parte di una routine di auto-configurazione e ottimizzazione
Ecco che allora, in tutti i casi in cui il sistema non riuscirà tramite il DNS a individuare gli Host, si attiveranno i protocolli LLMNR e NBT-NS, i quali invieranno in broadcast richieste UDP a tutti i dispositivi della rete affinché qualcuno di essi possa dare informazioni della risorsa cercata. Si tratta di comunicazioni non autenticate, non cifrate e che chiunque nella rete potrà intercettare.
Nell’immagine sopra vediamo lo sniffer di rete Wireshark in ascolto mentre su Windows10 un utente cerca la risorsa (inesistente) “ftp://PIOPPO”. Le prime due righe in alto rappresentano il protocollo NTB-NS e quello LLMNR (che supporta anche IPv6) inviati in broadcast. Nel dettaglio dei pacchetti, invece, vediamo come NBT-NS, a destra, invia il pacchetto sulla porta di destinazione 137/udp (e in basso vediamo anche la query di ricerca di “PIOPPO”) e LLMNR, a sinistra, sulla porta 5355/udp.
A questo punto, se tra i vari sistemi presenti nella rete ci fosse anche quello di un criminale in ascolto sulle porte 137/udp e 5355/udp, ricevendo la richiesta mandata in broadcast potrebbe rispondere fingendo di essere l’Host cercato (spoofing). Il sistema richiedente, quindi, credendo di aver individuato finalmente la risorsa voluta, tenterà di autenticarsi ad essa inviando l’HASH NTLMv1/v2 o LMv2 dell’utente attivo in quel momento sul sistema. HASH che ovviamente verrebbe catturato dall’attaccante.
E cosa se ne può fare l’attaccante dell’HASH delle credenziali Windows di un utente? Potrebbe, in primis, cercare di craccarlo offline per ottenere le credenziali in chiaro e quindi usarle successivamente per altri attacchi, ma qualora questo fosse invece inviolabile a causa della complessità della password, e l’utente fosse di tipo Amministrativo, potrebbe addirittura usare l’HASH per compromettere e prendere il controllo di un altro sistema della rete che condivida le stesse credenziali.
Esistono diversi strumenti per sfruttare questa vulnerabilità.
NBNSpoof, ad esempio, inventato nel 2007 da Wesley McGrew, crea automaticamente risposte alle query NetBIOS, mentre Metasploit ha vari moduli sia per creare risposte NetBIOS
(auxiliary/spoof/nbns/nbns_response) sia LLMNR (auxiliary/spoof/llmnr/llmnr_response).
Quello di cui vi parlerò però è Responder.py di Laurent Gaffie (https://github.com/lgandx/Responder), un tool Python capace di restare in ascolto nella rete e rispondere alle richieste LLMNR e NBT-NS (utilizzando falsi server di autenticazione HTTP, SMB, MSSQL, FTP, LDAP, POP3, …) spacciandosi per il server legittimo e carpendo, in questo modo, le credenziali dell’utente (in formato HASH NTLMv2 mentre per i protocolli insicuri come l’FTP o l’HTTP, invece, in chiaro). Nel momento in cui sto scrivendo la pagina di github di Responder viene segnalata da firefox come sito che potrebbe contenere software dannoso, capiremo andando avanti, il perché 😊
È possibile scaricare Responder da GitHub con il comando GIT
$ sudo git clone https://github.com/lgandx/Responder.git
Una volta fatto il download troveremo una cartella chiamata “Responder”, all’interno della quale ci sarà il tool “Responder.py”, il file di configurazione “Responder.conf”, la cartella “logs” con all’interno i file degli HASH catturati, e la cartella “tools” all’interno della quale si trovano altri strumenti come “MultiRelay.py” e “RunFinger.Py” che vedremo più avanti.
Supponiamo ora di essere in una rete composta da quattro sistemi, due Windows 7 Professional SP1, un Windows 10 Professional e una macchina attaccante (ad esempio di un dipendente infedele) con sistema operativo Kali Linux (versione 2020.4). Sui sistemi Kali Linux i tool sono già presenti, ma purtroppo siccome quello chiamato MultiRelay.py non funziona correttamente è consigliabile in ogni caso scaricarli da GitHub. La versione Python utilizzata sul sistema attaccante per eseguire i tool è la 2.7.18. Si tratta di macchine in gruppo di Lavoro “Workgroup” ma tutto quello che vedremo funziona allo stesso modo in un ambiente di dominio.
E se l’HASH ottenuto non fosse così facilmente violabile? Se l’azienda target usasse password lunghe 18 caratteri sarebbe davvero arduo decifrarne l’HASH. L’attaccante allora si dovrà arrendere? No! Perché gli HASH NTLM possono essere usati direttamente, anche senza ottenere la password in chiaro, in quelli che vengono definiti attacchi di tipo “Pass-the-Hash” utilizzando vari strumenti. Tra questi, uno è presente nella stessa suite di Responder, e si chiama “MultiRelay.py” il quale, proprio utilizzando gli HASH NTLM cercherà di autenticarsi, attraverso il protocollo SMB, su un sistema che condivida lo stesso utente e le stesse credenziali. È importante però sapere che:
Al criminale non rimane altra che avviare sia Responder che MultiRelay indicando, a quest’ultimo, che la macchina da compromettere è la 10.10.10.106 come vediamo nella foto in basso. Quello che avverrà è che gli HASH NTLMv2 raccolti da Responder, verranno passati direttamente a MultiRelay il quale li utilizzerà per autenticarsi alla macchina target attraverso un attacco definito SMB Relay.
N.B. Nelle versioni più datate di Kali Linux (di sicuro nella 2019.2) MultiRelay funziona. Nelle versioni recenti di Kali (2020.4) il tool non funziona per mancanza della libreria “Crypto” che dal repository ufficiale di Kali non si riesce a scaricare. Una soluzione funzionante (ma non ne ho provate altre) è quella di scaricare dal servizio ftp di debian.org, ed installare, il pacchetto “python-crypto_2.6.1.9…deb” più appropriato per il proprio sistema.
Il parametro (-t) indica a MultiRelay il target e il (-u ALL) che stiamo inoltrando tutte le richieste di autenticazione NTLMv1/v2 di tutti gli utenti. Potrebbe pertanto capitare un utente che non hai i privilegi elevati sul sistema e quindi l’attacco non riuscirebbe. In questo caso il tool impedirà ulteriori tentativi da parte dello stesso utente, in modo da evitare il blocco. Senza alcun altro parametro MultiRelay, in caso di attacco riuscito, farà ottenere una shell sulla macchina target, come nell’esempio che seguirà. È però, questa, la funzione più intrusiva e non è detto che sia sempre quella voluta dall’attaccante. Aggiungendo ad esempio il parametro (-d), invece, MultiRelay farà solo il dump degli HASH delle password locali, che rappresenta al contrario l’opzione meno intrusiva.
Dopo un po’ di tempo, Responder intercetta le credenziali dell’Administrator, e le passa a MultiRelay, il quale consente all’attaccante di autenticarsi sulla macchina target. A questo punto il criminale si trova nel file system del sistema 10.10.10.106 come Amministratore locale e potrà pertanto disporre completamente di esso.
Potrà fare il dump degli hash delle password locali, eseguire il pivot (saltare) su altri dispositivi della rete, installare malware, cifrare i dati, utilizzare il comando “reg save” per tentare di recuperare le eventuali password di dominio salvate in cache, e molto altro. Come vediamo nell’immagine in basso, ottenuta la shell il criminale digita i comandi hostname e poi ipconfig (magari scopriva una seconda scheda di rete).
Nel marzo del 2017 sono state integrate a MultiRelay le funzionalità di Mimikatz, l’eccezionale e potente tool opensource per il recupero delle credenziali di Windows e molte altre informazioni sulle stesse. Da una shell ottenuta con MultiRelay possiamo richiamare Mimikatz con il semplice comando “mimi” o “mimi32” se Host a 32 bit. Nella foto che segue vediamo uno dei Tweet sull’account ufficiale di Responder che informano dell’integrazione.
Altre utili funzionalità che sono state integrate in MultiRelay includono uno scanner SMB molto veloce che può essere utilizzato una volta che si ha una shell sull’Host compromesso, per trovare altri potenziali bersagli all’interno della rete e la possibilità di generare ed utilizzare la shell privilegiata preferita da criminali e pentester, ovvero Meterpreter.
Abbiamo visto come abusando di alcuni servizi di Windows e con un paio di strumenti gratuiti disponibili online un eventuale attaccante, presente in una rete aziendale, potrebbe sniffare con semplicità le credenziali degli utenti. E come potrebbe utilizzarle per prendere il controllo di eventuali computer o passare da utente senza alcun privilegio ad Amministratore di Dominio in pochi minuti. Come possiamo prevenire tutto ciò?
Prevenire l’attacco LLMNR NBT-NS è abbastanza semplice. In primis è fondamentale capire ed accertarsi di avere la vulnerabilità e quanto questa sia estesa con regolari attività di penetration testing. In secondo luogo occorre disabilitare sia LLMNR sia NetBIOS Name Service. Disabilitando solo LLMNR windows eseguirà il failover su NetBIOS per la risoluzione dei nomi. Inoltre occorre impostare la sicurezza del protocollo SMB. Quanto seguirà è a livello generale, ma attenzione alle specificità di ogni rete, non per tutte le reti possono andar bene tali consigli. È sempre bene considerare vantaggi e potenziali svantaggi che derivano dal cambio di impostazioni sui sistemi e sui protocolli.
Disabilitare il protocollo LLMNR
È possibile disabilitare il protocollo LLMNR attraverso le Group Policy (GPO).
Aprendo “l’Editor Criteri di Gruppo Locali (gpedit.msc)” -> “Local Computer Policy” -> “Computer Configuration” -> “Administrative Templates” -> “Network” -> “DNS Client” e impostando a “Enabled” le impostazioni “Turn off Multicast Name Resolution”, come nell’immagine in basso.
Disabilitare il protocollo NTB-NS
N.B: Se nella rete esistono computer che eseguono sistemi operativi precedenti a Windows 2000, il protocollo NBT-NS non dovrebbe essere disabilitato in quanto in tali sistemi i nomi NetBIOS erano necessari per individuare le risorse di rete non supportando completamente il Domain Name System (DNS), supportato invece da Windows 2000 in poi. (https://technet.microsoft.com/en-us/library/cc728457(v=ws.10).aspx) .
In ogni caso disporre di sistemi antecedenti a Windows 2000 espone a ben altri gravi rischi.
Con la configurazione che di seguito illustrerò si forzeranno tutte le connessioni dei sistemi ad utilizzare la firma SMB indipendentemente dal fatto che stiano agendo come server o come client.
Va però considerato che se la firma fosse abilitata e richiesta su un server e disabilitata sul client, o viceversa, la connessione fallirà e le macchine non saranno in grado di comunicare tramite SMB.
Pertanto se si applicheranno tali impostazioni è importante farlo in modo uniforme tramite GPO su tutte le macchine della propria rete, senza dimenticare però quelle fuori dominio che vanno configurate manualmente. Inoltre alcune stampanti non supportano la firma SMB, determinando l’impossibilità di stampare.
Tengo a sottolineare che i Vulnerability Scanner evidenziano la mancata firma SMB come vulnerabilità. E del resto come abbiamo visto è una situazione molto pericolosa, che se da un lato può sfuggire agli Amministratori di Rete., viene invece monitorata da eventuali criminali. Voglio ricordare che Microsoft ha introdotto questo meccanismo di protezione da Windows 98! Però come sappiamo, è abilitato di default solo sui controller di dominio. Vediamo come abilitare “SMB Signing” attraverso le Group Policy anche ai sistemi che non sono controller di dominio.
gpedit.msc -> “Computer Configuration” -> “Windows Settings” -> “Security Settings” -> “Local Policies” -> “Security Options” e quindi abilitare “Microsoft network client: Digitally sign communications (always)” e “Microsoft network server: Digitally sign communications (always)” come nell’immagine che segue. Notiamo l’alert che compare all’abilitazione della protezione (Q823659). Se non applichiamo queste impostazioni a tutti i sistemi potremmo non riuscire a comunicare.
Desidero chiudere facendo un cenno ai sistemi che non sono Windows.
Questi, soffrono della stessa vulnerabilità? Certo!
I client Apple e Linux utilizzano un protocollo simile a LLMNR e NTB-NS chiamato “multicast DNS o mDNS” sorto nei primi anni 2000 e regolato dalla RFC6762. Quando un client mDNS deve risolvere un nome Host, invia un messaggio di query multicast IP sulla porta di destinazione 5353/tcp che chiede all’Host che ha quel nome di identificarsi. La macchina di destinazione invia quindi un messaggio multicast che include il suo indirizzo IP. Tutte le macchine in quella sottorete possono quindi utilizzare tali informazioni per aggiornare le proprie cache mDNS. mDNS è implementato da Apple Bonjour e dai pacchetti software open source Avahi, inclusi nella maggior parte delle distribuzioni Linux.
Per il protocollo mDNS possono esistere due client con lo stesso nome. Pertanto a fronte di una query multicast di ricerca di una risorsa, vincerà il primo che invierà la risposta dicendo di essere la risorsa cercata. Ma il funzionamento sarebbe lo stesso se la risorsa proprio non esistesse, vincerebbe chi si presenta come tale, mancando qualsiasi forma di autenticazione. Quindi, ad esempio, se un’applicazione deve stampare sulla stampante epson.local, un attaccante potrebbe inviare una risposta alla query DNS con una risposta contraffatta che indica di stampare su un indirizzo IP diverso. Ma ovviamente si può far redirigere qualsiasi cosa, e pertanto anche le credenziali degli utenti.
La cosa interessante? Che Responder supporta anche il protocollo mDNS!
Si parla di Multicast DNS, però, per lo più per attacchi subiti su servizi mDNS esposti ad internet. Interrogando tale servizio in modo appropriato un criminale può ottenere il MAC Address della macchina ma anche la lista dei servizi in esecuzione. Inoltre, siccome mDNS si basa su query UDP, è possibile per un attaccante creare un attacco DoS/DDoS verso un obiettivo se cambia (spoofing) il suo indirizzo IP di destinazione dei pacchetti (Alert US-Cert TA14-017A).
Articolo a cura di Antonio Sagliocca
Si avvicina la data del Forum Cyber 4.0, che il 3 e 4 Giugno 2024 riunirà a…
Nel panorama odierno della sicurezza informatica, la protezione degli endpoint rappresenta un obiettivo imprescindibile per…
I numeri dell’evento Oltre 1000 ospiti, 42 relatori, 20 interventi tematici e 5 Tavole Rotonde:…
Group-IB è un fornitore, con sede a Singapore, di sistemi ad elevata attendibilità per il…
Le interazioni di natura digitale, su rete pubblica o all’interno di reti private, hanno assunto…
La Commissione Europea ha di recente ricordato come “Artificial intelligence (AI) is not science fiction;…