In questo articolo voglio parlarti di come un attaccante può sfruttare alcuni protocolli di name resolution per sniffare credenziali.Ocio, ci sono alte probabilità che anche la tua infrastruttura sia vulnerabile!
La sicurezza di una rete è forte quanto il suo anello più debole.Spesso, quel punto debole non è il sistema, ma la fiducia cieca in protocolli che il tempo ha reso vulnerabili.
Scenario#
Sono un attaccante e ho messo già una “zampa” nella tua rete interna, magari hai un servizio esposto le cui credenziali fanno parte di un data leak, magari ho sfruttato una 0-day o piuttosto un tuo collega è stato così gentile da andare in pausa pranzo lasciando il suo PC accessibile.A prescindere dalla motivazione, ora che ho un accesso, posso provare a “sniffare” le credenziali della tua organizzazione.
Come? Ora te lo spiego…
I servizi di “Name Resolution”#
Facciamo un passo indietro e immagina un mondo senza servizi di Name Resolution.
Hai visto se è in vendita su 52.95.120.36 ad un prezzo migliore?Let me 216.58.205.35 it for you!
Impossibile giusto?
I servizi di name resolution ci permettono di usare nomi “umani” per mappare indirizzi IP, in soldoni possiamo dire al nostro browser di raggiungere www.google.it piuttosto che 216.58.205.35.
Senza questi protocolli non solo non potremmo usare Internet, ma avremmo dei disagi anche nell’ uso di servizi su reti locali.
Di default un host Windows prova a risolvere un nome utilizzando, in ordine:
- Cache
- File
hostslocale - DNS
- Multicast Protocols: LLMNR, mDNS
- NetBIOS-NS
I protocolli di Multicast e NetBIOS-NS sono particolarmente utili in reti dove non esiste un server DNS, il loro scopo è quello di facilitare l’individuazione dei servizi di rete quando manca un sistema centralizzato (DNS).
Ok, ma che c’entrano i servizi di name resolution con le credenziali?!
Esiste un tool che ascolta le chiamate broadcast eseguite grazie a questi protocolli e risponde con una richiesta di autenticazione, in quel momento quindi il client vittima, in maniera del tutto automatica, utilizza le proprie credenziali per autenticarsi al servizio.
Questo tool è 🌈 Responder! 🌈
Cos’è Responder?#
Responder agisce da rogue server e riesce a fare poisoning del traffico di rete con l’obiettivo ultimo di sniffare credenziali. Sfrutta i protocolli non sicuri come LLLMNR NetBIOS-NS e mDNS, fingendo di essere un servizio di rete legittimo.
Quando un dispositivo sulla rete cerca di risolvere un nome che non esiste nel DNS (ad esempio, quando un utente digita male un nome di server o quando un attaccante riesce a forzare un redirect), Responder si inserisce, fingendo di essere la risorsa mancante. In questo modo inganna la vittima, facendole inviare i dati di autenticazione, come gli hash NTLM, che possono essere poi crackati offline o usati per attacchi di Relay.
Hai presente quei servizi, ad esempio di inventory o di backup, che girano di notte con un’ utenza privilegiata? Prova ad immaginare cosa succede nel momento in cui fanno il lavoro di discovery mentre Responder è attivo sulla rete 😈
In questa immagine possiamo vedere in maniera grafica la catena di attacco:
- La vittima cerca di raggiungere una share di rete
\\hackmeche non esiste. - La vittima manda un messaggio di broadcast a tutta la rete locale, chiedendo se qualcuno conosce l’host
hackme. - Responder finge di essere la share
\\hackme. - La vittima cerca di autenticarsi alla share fasulla usando le proprie credenziali.
A questo punto, avrò tra le mani un hash che potrà essere dato in pasto ad hashcat, per il cracking offline, o sfruttato per attacchi di tipo NTLM Relay.
Cosa succede se l’hash che ho catturato ha privilegi elevati?Niente, è GAME OVER. ☠️
E mo? - Mitigare#
Se non hai bisogno di questi protocolli, e credimi che nel 99% dei casi non ti servono, il modo più semplice per mettersi al sicuro è disabilitarli.
Come disabilitare LLMNR?#
Per LLMNR la procedura è semplice, abbiamo la possibilità di disabilitare il protocollo sia a livello di singolo host, sia a livello di dominio tramite una GPO.La regola da modificare è la seguente:
Computer Configuration -> Administrative Templates -> Network -> DNS Client
Settare ad Enabled la configurazione Turn Off Multicast Name Resolution
Intuitivo no? devi abilitare la disabilitazione 😅
Come disabilitare NetBIOS-NS?#
Purtroppo per NTB-NS e mDNS non esiste nessuna GPO, dobbiamo quindi usare altre strade.
Per un singolo host puoi eseguire questo script Powershell che disattiverà NetBIOS su tutte le schede di rete
$hive= "HKLM:SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces"
foreach($interface in (ls $hive| Select -ExpandProperty PSChildName)) {
Set-ItemProperty -Path "$hive\$interface" -Name "NetbiosOptions" -Value 2
}
Per applicare l’azione su tutto il dominio invece hai diverse opzioni.La prima è se utilizzi un server DHCP, in questo caso puoi seguire questa procedura ufficiale Microsoft.Altrimenti puoi distribuire lo script in PowerShell con Intune o qualsiasi altro RMM, GPO, etc..Quello che preferisci insomma.
Come disabilitare mDNS?#
Anche per mDNS ci viene in aiuto il nostro amico Powershell
$hive= "HKLM:SYSTEM\CurrentControlSet\Services\Dnscache\Parameters"
Set-ItemProperty -Path "$hive" -Name "EnableMDNS" -Value 0
Per la distribuzione su più host puoi usare le stesse modalità di sopra.
Altre raccomandazioni#
Se proprio non riuscissi a fare a meno di questi protocolli (poi però mi devi dire il perché), devi assolutamente:
- Abilitare l’SMB Signing
- Segmentare la tua rete e limitare il traffico broadcast e multicast, questo serve ad impedire che attaccanti ascoltino sottoreti critiche.
- Monitorare qualsiasi attività sospetta.
- Disabilitare NTLM dove possibile e affidarti solo a Kerberos come sistema di autenticazione, non proprio la cosa più semplice del mondo.