Attacco alle credenziali degli utenti della LAN. LLMNR e NBT-NS Poisoning con Responder e MultiRelay.

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.

LLMNR e NTB-NS

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.

La Vulnerabilità

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.

Dimostrazione – Responder.py

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.

1. L’attaccante (10.10.10.102) guarda le opzioni di Responder con il parametro (-h). Quindi lo avvia in modo che si metta in ascolto sulla rete 10.10.10.0/24 e sull’interfaccia di rete eth0 (-I) in attesa di richieste LLMNR o NBT-NS, come si vede nella foto in basso.
   Responder è stato avviato con il comando:
   $ sudo ./Responder.py -I eth0
   
2. L’utente (Administrator) della macchina Windows 10 (10.10.10.105) tenta di accedere alla risorsa “\\share223” ma invece digita “\\share23”. Siccome il Server DNS non sa dire al sistema chi è “\\share23”, quest’ultimo invia richieste LLMNR e NBT-NS a tutta la rete per cercarla.
   
3. Il sistema attaccante intercetta le richieste e fingendo di essere la risorsa “\\share23” risponde alla macchina richiedente. Questa, allora, credendo di parlare con la risorsa giusta, invia l’HASH NTLMv2 dell’utente attivo sul sistema (Administrator) affinché questo possa autenticarsi… Ecco che l’attaccante, in questo momento, entra in possesso dell’HASH delle sue credenziali, come vediamo nell’immagine in basso. Responder, inoltre, tramite il suo server fake SMB, restituirà un errore all’utente il quale crederà semplicemente di aver digitato male il nome di condivisione (foto in alto).
   
4. Nel frattempo l’utente del sistema Windows 7 (10.10.10.103) cerca di raggiungere via browser la risorsa “ftp:\\share14”, inesistente. Responder.py che continua ad essere in esecuzione sul sistema dell’attaccante risponde ad esso con una finta maschera di login. L’utente ingenuamente (senza sapere di aver sbagliato a digitare l’indirizzo (share14 invece di share114) inserisce delle credenziali per autenticarsi. Credenziali che in questo caso saranno raccolte dall’attaccante in chiaro, trattandosi di FTP. È interessante vedere, nella foto in basso, che oltre alle credenziali FTP in chiaro, Responder abbia registrato in precedenza la richiesta del protocollo WPAD (Web Proxy Auto Discover) effettuata dal sistema operativo Windows 7 e quella del sito “www.bing.com” avvenuta con l’apertura di Internet Explorer (in questa rete mancando un server DNS tutte le richieste vanno su LLMNR e NTB-NS).Se l’attaccante avesse utilizzato Responder con l’opzione (-F), in caso di richieste WPAD da parte del browser, avrebbe forzato quest’ultimo ad autenticarsi fornendo le credenziali dell’utente, che nel caso di Internet Explorer avrebbe passato automaticamente. Utilizzando invece l’opzione (-A) avrebbe usato Responder in modalità di solo ascolto. Vuol dire che avrebbe potuto analizzare le richieste senza rispondere a nessuna. Ciò può essere utile per capire quanto una rete sia loquace senza interagire con alcun Host.
5. Dopo un po’ di tempo nella cartella “/Responder/logs” si saranno raccolti vari file di testo all’interno dei quali ci sono gli HASH e le password in chiaro raccolte da Responder mentre era in ascolto. Quelli interessanti per l’attaccante sono ovviamente quelli che cominciano con “FTP-..”, “HTTP-NTLMv2-“, “SMB-NTLMv2-“… Nella foto in basso vediamo l’elenco dei file di log, l’apertura del file “SMB-NTLMv2-SSP-10.10.10.105” che corrisponde alla prima richiesta fatta dall’utente Administrator su Windows 10. Vediamo l’HASH della sua password. Vediamo anche il contenuto di altri due file, il primo contenente l’HASH della password di un utente Michele per una richiesta HTTP e il secondo contenente le credenziali in chiaro inserite sulla richiesta FTP. Essendoci diversi utenti per lo stesso computer 10.10.10.103, probabilmente il computer è di Michele ma per accedere ad alcune risorse serve l’utente Antonio (che forse è un Amministratore). O più semplicemente il dispositivo potrebbe essere utilizzato da diversi utenti.
   
6. Ecco che, infine, utilizzando il tool di cracking “Jhon The Ripper”, con la sua wordlist di default, in zero secondi l’attaccante riesce a craccare l’HASH della password dell’Administrator che come si vede nella foto in basso è “batman”. Capiamo benissimo come gli HASH di password semplici vengano individuate in pochissimo tempo. E quindi quanto importante sia disporre di password robuste.
   

HASH inviolabili – MultiRelay-py

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:

• L’HASH da utilizzare dovrà essere di un utente che abbia privilegi di Amministratore sul sistema da violare.
• MultiRelay non potrà inoltrare l’autenticazione NTLMv1/2 alla stessa macchina da cui proviene l’HASH (e questo a seguito della correzione, da parte di Microsoft, della vulnerabilità MS08-068);
• MultiRelay non potrà utilizzare gli HASH raccolti e archiviati durante l’attività di Responder, ma dovrà inoltrare solo richieste di autenticazione NTLM in tempo reale. Significa che MultiRelay dovrà essere utilizzato in contemporanea a Responder. Per tale motivo bisogna apportare una modifica al file di configurazione di questo, nel file che si chiama conf. e che si trova nella stessa directory di Responder.py. Occorre disabilitare i protocolli HTTP e SMB come si vede nell’immagine in basso. Questo perché vorranno entrambi utilizzare le porte 80/tcp e 445/tcp e invece vogliamo che sia MultiRelay ad utilizzarle ora. Nel file di configurazione si vede anche qual è il database del tool, ovvero il file Responder.db, contenuto nella stessa cartella.
  Poiché Responder non indica più a video gli HASH degli utenti che ha già raccolto basterà cancellare proprio questo file database affinché il programma riprenda a farci vedere l’HASH dell’utente mentre lo raccoglie creando un nuovo file Responder.db.
• Prima di poter eseguire l’attacco il criminale deve accertarsi che i dispositivi che vuole attaccare non abbiano abilitata la funzione di sicurezza del protocollo SMB chiamata “SMB Signing”. Non devono cioè richiedere la firma SMB. Di default tale funzione di sicurezza è disabilitata nei client mentre è obbligatoria per i Controller di Dominio. Garantisce al destinatario l’autenticità del mittente dei pacchetti. È una sorta di firma digitale del pacchetto. Ecco che in presenza di tale meccanismo attacchi di tipo Man In The Middle, come quelli di cui stiamo parlando, non potrebbero avvenire.
  L’attaccante per verificare la presenza o meno di questo meccanismo lancia su tutta la rete un altro strumento presente nella cartella “/Responder/tools”, chiamato RunFinger.py. Non ha intenzione di sprecare tempo con obiettivi che hanno SMB Signing abilitato ma solo con quelli che hanno SMB signing impostato a “False”. Ecco che individua la macchina 10.10.10.106 (W7) che fortunatamente ha la funzione disabilitata! Qualunque dispositivo, e quindi anche quello dell’attaccante, potrà autenticarsi via SMB con tale sistema, passando le credenziali (o l’HASH) giusto! Invece la 10.10.10.103 (W7) ha il SMB signing a “True” e quindi non andrebbe bene, mentre la 10.10.10.105 (W10) non compare.
  

L’attacco – SMB Relay

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.

PREVENIRE QUESTO ATTACCO

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.

• Vediamo un primo procedimento per disabilitare NetBIOS su uno specifico Host.
  “Control Panel” -> “Network Connection / Network and Sharing Center” -> “Network Connection properties” -> “Internet Protocol Version 4 (TCP/IPv4)” -> “Properties” -> “Advanced” -> “WINS” -> selezionare “Disable NetBIOS over TCP”.

• È possibile poi disabilitare NetBIOS sui client di dominio che ottengono indirizzi IP da un server DHCP
  Aprire “dhcpmgmt.msc”, connettersi al server DHCP e selezionare “Scope Option zone settings” (o “server – Server Options”) quindi selezionare “Advanced” poi “Microsoft Windows 2000 Options” dal menu a tendina Vendor Class:” e infine abilitare “001 Microsoft Disable Netbios Option” impostando il valore 0x2.
  Per dettagli è possibile consultare il documento Microsoft.
• Attraverso le GPO non c’è un sistema per disabilitare NetBIOS.
  Però è possibile utilizzare le GPO per fare il deploy sui client di uno script Powershell che lo faccia all’avvio delle macchine.
  Creare il seguente script Powershell chiamandolo, ad esempio “NoNTBNS.ps1”
  $regkey = “HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces”
  Get-ChildItem $regkey |foreach { Set-ItemProperty -Path “$regkey\$($_.pschildname)” -Name NetbiosOptions -Value 2 -Verbose}Quindi aprire l’editor dei Criteri di Gruppo (gpedit.msc) e mettere lo script NoNTBNS.ps1 in “Computer Configuration” -> “Windows Settings” -> “Scripts (Startup/Shutdown)” -> “Startup”.
  

Abilitare “SMB Signing”

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.

E i sistemi Linux e Apple? – Multicast DNS (mDNS)

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