~/docs/llmnr_poisoning.pcap

Un aspetto che molto spesso viene sottovalutato durante le fasi di hardering in ambiente windows è relativo al poisoning dei protocolli LLMNR e NTB-NS.
Prima di entrare nel dettaglio di come questi possono essere sfruttati è bene aver chiaro in mente a cosa servono.

LLMNR sta per Local-Link Multicast Name Resolution, mentre che NBT-NS sta per NetBIOS Name Service.

Questi due protocolli sono di default abilitati su Windows (a partire da Windows Vista) e il loro scopo è quello di intervenire a supporto del sistema operativo quando non è in grado di risolvere un nome host tramite il servizio DNS o via il suo file host locale.

Qualche esempio di quando questo comportamento potrebbe verificarsi:

1. Windows tenta di rilevare automaticamente i proxy Web (protocollo Web Proxy Auto Discovery – WPAD) in un ambiente senza un proxy tentando di risolvere il nome Host “wpad” senza riuscirci (vedi per esempio il comportamento di Internet Explorer). In pratica se un browser Web è impostato per rilevare automaticamente le impostazioni proxy, utilizzerà WPAD per rilevare l’URL relativo al file di configurazione del proxy. Per scoprire questo URL, WPAD eseguirà un’iterazione attraverso una serie di potenziali URL e, ad ogni tentativo non andato a buon fine, si esporrà allo spoofing inviando una richiesta di broadcast per reperire questa informazione. Google Chrome e Firefox non hanno questo comportamento per impostazione predefinita, Internet Explorer si.
2. Se un utente digita erroneamente il nome di un host legittimo, di solito non verrà trovato alcun record host rilevante e la macchina ricorrerà all’LLMNR multicast. Questo è un caso d’uso piuttosto poco efficace poiché l’attaccante dovrà attendere un errore da parte della vittima
3. Google Chrome, quando viene digitata una stringa di una singola parola nella barra di ricerca, ha bisogno di un modo per discernere se la stringa è un URL o un termine di ricerca. Chrome prima tratta la stringa come un termine di ricerca e indirizza l’utente al motore di ricerca configurato assicurandosi contemporaneamente che la stringa non sia un nome host tentando di risolverlo. Inoltre, per prevenire l’esposizione al DNS hijacking, Chrome cercherà di risolvere diversi nomi host randomizzati all’avvio per assicurarsi che non si risolvano, garantendo essenzialmente alcune azioni NR (Name Resolution) multicast
4. una configurazione non corretta sul server DNS o sul client può causare problemi e quindi costringere il client a fare affidamento su query di nomi multicast

Vediamo di fare un esempio.

Il pricipio di funzionamento

1. client1 vuole accedere alla risorsa \\serrver\share. client1, non conoscendo l’ip di serrver, chiede al suo DNS di risolvere l’indirizzo (Img. 1)

2. Il DNS risponde che non conosce l’host serrver, quindi non è in grado di ottemperare la richiesta e restituisce un pacchetto di risposta DNS senza la sezione “answer” (Img. 2)

3. client1 invia un messaggio a tutti gli host del suo dominio di broadcast chiedendo se qualche host è in grado di risolvere il nome per il quale ha fatto richiesta al DNS (Img 3a e 3b)

Fino a qui tutto bene.
O quasi.

Spoofig

Fatto cento quanto fin’ora descritto, la tecnica consiste in una serie di fasi che riassumo qua sotto.

Il tool che comunemente si usa è responder anche se tuttavia ne esistono molti altri (come metasploit).

Nell’immagine 5 si vede come responder, dopo la richiesta della challenge (img 4 punto 6), riceve dal client DESKTOP-SCQBOJL l’hash dell’utente “administrator” (img 4 punto 7).

Con l’hash ottenuto, l’attaccante potrebbe tentare di decifrare la password mediante tool come “john the ripper” e successivamente utilizzare il set di credenziali ottenute per spostarsi lateralmente tra i vari sistemi sulla rete.

NOTA: sebbene un tentativo di dictionary attack sia comunemente “prassi” nel mondo dei laboratori di ethical hacking e/o nelle CTF, nel “mondo reale” non sempre si rivela efficace. Con questo non voglio dire che è non sia corretto provarci ma c’è sempre da tener conto che è un attacco basato su dizionario; ne viene di concerto che o si spera in una password debole oppure il rischio è quello di investire tempo e risorse in un nulla di fatto. Tenetelo sempre a mente nelle vostre analisi e, se siete dei red teamers, consiglio di investire in nella costruzione di un dizionario costruito ad hoc per il target (vedi hybrid dict o rainbow dict).

Mia personalissima opinione

Un secondo (e presumibilmente più efficace) utilizzo dell’hash ricevuto consiste nell’operare un attacco di tipo pass-the-hash (ne avevamo parlato qui), mediante un tool chiamato “MultiRelay”. Tuttavia è bene tenere a mente qualche precisazione:

1. l’hash catturato dalla macchina deve avere privilegi di amministratore sul sistema che si vuole attaccare
2. l’hash ottenuto non potrà essere utilizzato per accedere alla stessa macchina dalla quale si è ricevuto (vedi MS08-068)
3. l’SMB signig deve essere disabilitato (condizione vera nei sistemi client se non modificata manualmente o via GPO il settaggio manuale delle impostazioni, ma falsa nei controller di dominio). SMB signing è la funzione che garantisce al destinatario l’autenticità dei pacchetti ricevuti.

Per dare una connotazione più “reale” sul come sfruttare questo tipo di attacco si può ipotizzare questo scenario:

1. l’attaccante riceve l’hash dell’utente administrator dal client1
2. con l’hash ottenuto l’attaccante prende il controllo di client2
3. infine l’attaccante usa client2 per fare pivoting ed accedere alle risorse di client1

Remediation

DISCLAIMER
Prima di iniziare con le azioni di remediation "a spron battuto" assicuratevi che queste siano compatibili con i sistemi della vostra rete.

La buona notizia è che le remediation sono di fatto semplici da realizzare.

In prima battuta, come avevo scritto in un precedente articolo, consiglierei di disabilitare a livello di GPO l’uso del protocollo LLMNR.

Per farlo basta aprire l’editor dei criteri del gruppo e navigare su “Local Computer Policy” > “Computer Configuration” > “Administrative Templates” > “Network” > “DNS Client” e impostare a “Enabled” le impostazioni “Turn off Multicast Name Resolution”

Altro consiglio è quello di disabilitare il protocollo NTB-NS, sempre che non abbiate ancora macchine Windows 2000 e precedenti (Dio non voglia, ma non si sa mai).

Il “problema” in questo caso è quello che, a differenza dell’LLMNR, non c’è modo di disabilitarlo via GPO ma solo sulla macchina locale dalle impostazioni della scheda di rete oppure mediante uno script powershell per poi distribuirlo via GPO.

Il terzo ed ultimo consiglio che posso dare (anche perché non ne conosco altri) è abilitare l’SMB signing su client e server.

NOTA: è importantissimo tenere a mente che se abilitato, la GPO deve coprire tutti i sistemi aziendali in quanto se la firma fosse abilitata su un server e disabilitata sul client (o viceversa), la connessione fallirà e le macchine non saranno in grado di comunicare tramite SMB. Quindi accertatevi del fatto che le repliche GPO siano ben funzionanti prima di procedere. Inoltre, se avete dei client fuori dominio che risiedono sulla vostra rete questi, non prendendo la GPO, non potranno più accedere alle risorse condivise via SMB.

EOF