• Guide, Sicurezza, Sistemi Operativi
• 8 Maggio 2024

Disclaimer: Gli strumenti e le tecniche descritte in questo articolo sono destinati esclusivamente a scopi educativi e di ricerca nel campo della sicurezza informatica. L’uso di tali strumenti e tecniche contro sistemi informatici senza il consenso esplicito del proprietario è illegale e può comportare gravi conseguenze legali. L’autore e gli editori declinano qualsiasi responsabilità per l’abuso o l’uso improprio di queste informazioni da parte degli utenti. Si consiglia vivamente di ottenere il consenso scritto prima di condurre qualsiasi tipo di test o di valutazione della sicurezza su sistemi informatici.

Questo articolo è parte della serie AD-ventures: La battaglia per la sicurezza di Active Directory – ICT Power

Nell’articolo precedente abbiamo parlato di Domain Enumaration. Lo scopo di tale attività è quella di recuperare il maggior numero di informazioni possibili relative ad un dominio Active Directory. Questa attività non ha un fine esclusivamente offensivo: se effettuata nel modo opportuno può essere un valido strumento alla ricerca di quelle configurazioni errate, o sottovalutate, che possono mettere a repentaglio l’intera infrastruttura.

Dopo aver raccolto le informazioni necessarie proseguiamo le nostre attività, verificando la presenza di possibili vulnerabilità che potrebbero essere presenti a causa di specifiche configurazioni, lasciate abilitate di default e non modificate. Un caso emblematico è l’utilizzo dei protocolli LLMNR e NBT-NS.

LLMNR e NTB-NS

Link Local Multicast Name Resolution (LLMNR) e NetBIOS Name Service (NBT-NS) sono due protocolli che consentono la risoluzione dei nomi per gli host di una rete locale. Normalmente, questa funzione è svolta dal Domain Name System (DNS) ma quando non riesce LLMNR e NBT-NS entrano in gioco: il concetto è garantire continuità in caso di problemi con il DNS.

LLMNR è stato introdotto da Windows Vista, di default utilizza la porta UDP 5355 e la sua principale funzione è consentire la risoluzione dei nomi di dominio in indirizzi IP quando non è disponibile un server DNS. Non è utilizzato per la risoluzione dei nomi su internet, utilizza multicast e link-local (un indirizzo tipico è 224.0.0.252 o comunque nella subnet 224.0.0.0/24) solo, appunto, nelle reti locali.

NBT-NS, invece, è quel servizio che riesce a identificare i sistemi tramite i nomi NetBIOS. Predecessore del LLMNR, anch’esso utilizzato quando il DNS non riesce a risolvere un nome di dominio. La porta è la UDP 137.

In sintesi, quando il sistema non riesce a risolvere i nomi host tramite il DNS, invia tramite il protocollo LLMNR delle richieste UDP in multicast nel tentativo di trovare quanto si sta cercando oppure attraverso il protocollo NBT-NS ricercando tra i nomi NetBIOS.

Si tratta di comunicazioni non autenticate, non cifrate e che chiunque in una rete locale può intercettare.

Questo tipo di comportamento non è una prerogativa Microsoft su Windows. Anche i client Linux o Apple utilizzano un protocollo con funzionalità molto simili denominato mDNS (Multicast DNS).

Come sfruttare la vulnerabilità

Esistono varie tecniche per riuscire a carpire le informazioni contenute in queste comunicazioni , ad esempio fingendosi l’host cercato, ma quello più efficace consiste nel mettersi in ascolto ed attendere che i meccanismi di Windows, in termini di autenticazione per l’accesso alle risorse, facciano il resto.

Immaginiamo che l’utente Bob voglia accedere ad una cartella condivisa denominata \\Dati ma per errore digita \\Data

Figura 1 – Richiesta accesso alla share \\Data

Il server DNS risponde alla richiesta di Bob dicendo di non conoscere “Data”, di conseguenza la richiesta di Bob viene effettuata in broadcast.

Figura 2 – Richiesta broadcast

A questo punto è sufficiente fingersi “Data” ed attendere che Bob si autentichi nel tentativo di accedere per ottenere le informazioni relative alla sua utenza, precisamente username e l’hash NTLM della password. Oppure effettuando un Man-in-the-Middle è sufficiente rimanere in attesa del three-way handshake.

Figura 3 – Invio credenziali

Questo processo è automatico, l’utente non deve fisicamente inserire le sue credenziali. Per il protocollo NTLM, ogni richiesta di autenticazione è formata da tre passi, il cosiddetto Three-way handshake:

• Negotiate: Il client tenta di accedere ad una risorsa chiedendo di autenticarsi;
• Challenge: Il server risponde al messaggio di negoziazione chiedendogli di crittografare una sequenza randomica di caratteri con un segreto che possiede. In questo caso, con l’hash della password;
• Authenticate: Il client invia la risposta ed il server contatta il servizio di autenticazione (il Domain Controller) per verificare che la risposta sia corretta.

Figura 4 – Three-way Handshake

Su device Apple e Linux ci sono delle piccole differenze anche se il meccanismo è il medesimo: la chiamata è in multicast verso l’IP 224.0.0.251 (IPv4) oppure FF02::FB (IPv6) sulla porta UDP 5353. In questo caso il primo a rispondere affermando di essere la risorsa cercata (oppure come per LLMNR nel caso la risorsa cercata non esista) è colui che viene contattato.

Per mettere in pratica questo scenario e proseguire il nostro percorso in ambiente Active Directory è possibile utilizzare il tool Responder/MultiRelay pubblicato su Github. Sulla vm Kali linux mettiamo in ascolto il responder con il comando

responder -I eth0

Figura 5 – Esecuzione responder

Effettuiamo il tentativo di accesso ad una share. Per evitare di fare troppo rumore, un attaccante potrebbe simulare un errore di battitura nel nome in modo da non generare un alert particolarmente visibile e tentando di confondersi tra le varie possibili azioni consuete. Inoltre, chiedendo di accedere ad una share “nuova” avremo sicuramente una richiesta di autenticazione.

Il DNS non conosce \\Data di conseguenza il client effettua una richiesta multicast chiedendo informazioni in merito.

Figura 6 – Richiesta di accesso alla share \\DATA

In questo caso non è necessario inserire le credenziali, il three-way handshake è già avvenuto (come possiamo vedere in fig. 8)

Figura 7 – Richiesta di autenticazione lato client

Controllando il responder abbiamo l’evidenza della richiesta con le credenziali dell’utente

Figura 8 – Ricezione informazioni sul responder

Nello specifico abbiamo lo username dell’utente e l’hash NTLMv2 della password.

A questo punto, abbiamo due possibilità:

• Tentare di craccare l’hash e recuperare la password: attività lunga e spesso non remunerativa. Se la password fosse molto lunga e complessa il tempo necessario a risolvere il problema sarebbe troppo lungo.
  Utilizzare l’hash per il movimento laterale con un attacco NTLM Relay.

  Esistono vari modi per utilizzare un hash e muoversi in un’infrastruttura. Vedremo il dettaglio più avanti, nei prossimi articoli.

Come difendersi

Disabilitare i protocolli LLMNR e NTB-NS è una buona pratica, solitamente affiancata dall’abilitazione della crittografia SMB ovvero “SMB Signing“.

Firmare le richieste è un ottimo modo per difendersi da questo tipo di attacchi ma è importante capirne bene il funzionamento: se la firma fosse abilitata solo su uno dei due interlocutori la comunicazione tramite SMB non potrebbe avvenire. Questo implica che tutti gli oggetti relativi al dominio devono essere opportunamente configurati, compresi quegli oggetti che non hanno effettuato il join ma che parlano comunque con oggetti dell’infrastruttura.

Disabilitare LLMNR

Per disabilitare LLMNR possiamo utilizzare la GPO “Computer Configuration -> Policies -> Administrative Templates -> Network -> DNS Client -> Turn off multicast name resolution”.

Figura 9 – Group Policy Management Editor

Figura 10 – GPO Turn off multicast name resolution

Disabilitare NTB-NS

Per disabilitare NTB-NS, invece, non c’è una GPO specifica. Per farlo su un singolo host è sufficiente modificare le configurazioni della scheda di rete, precisamente

“Internet Protocol Version 4 (TCP/IPv4) -> Properties -> Advanced -> WINS” e selezionare “Disable NetBIOS over TCP”

Figura 11 – Configurazioni scheda di rete

Per gli host a dominio, se le configurazioni di rete sono gestite da un DHCP Server Windows, così come indicato nella documentazione ufficiale Microsoft, è sufficiente aprire la console di gestione del DHCP, selezionare lo scope, successivamente Scope Options

Figura 12 – Console DHCP

selezionare Configure Options

Figura 13 – Console DHCP – Scope Options

In questa sezione, nel tab Avanzate, selezionare Microsoft Windows 2000 Options come Vendor Class, selezionare 001 Microsoft Disable Netbios Option e in “Data entry” inserire il valore 0x2.

Figura 14 – Console DHCP – Scope Options

Se si vuole utilizzare una GPO possiamo condividere uno script PowerShell da deployare su tutte le macchine interessate. Su
github
è possibile consultare ed utilizzare uno script già pronto
all’uso:

Dopo averlo salvato in un file con estensione .ps1 lo script va eseguito all’avvio delle VM. Si può fare in vari modi, ad esempio tramite una GPO. In questo caso sarà sufficiente aprire il Group Policy Management Editor ed utilizzare la GPO in “Computer Configuration -> Policies -> Windows Settings -> Script (Startup/Shutdown)” e selezionare le configurazioni di Startup

Figura 15 – Group Policy Management Editor

Selezionare lo script appena creato tramite l’apposito menu e premere OK.

Figura 16 – GPO Startup

Abilitare SMB Signing

Per abilitare questa configurazione, come al solito, abbiamo a disposizione una GPO e possiamo trovarla in “Computer Configuration -> Policies -> Security Settings -> Local Policies -> Security Options -> Microsoft network client: Digitally sign communications (always)”.

Figura 17 – GPO Microsoft network client: Digitally sign communication (always)

Definendo ed abilitando la policy verremo informati di prestare attenzione agli effetti di questa configurazione in termini di compatibilità, così come anticipato precedentemente.

Conclusioni

Come abbiamo visto, queste sono tecniche piuttosto semplici da utilizzare e ad alto impatto. Dobbiamo sempre tenere a mente che nella moltitudine di configurazioni abilitate di default c’è qualcosa da verificare. Ogni dominio è a sé ed andrebbe messo in sicurezza in maniera specifica. In questo caso un attaccante ha la possibilità di accedere a vari sistemi muovendosi con le credenziali carpite per poi tentare di utilizzare tecniche di privilege escalation al fine di ottenere più privilegi possibili. Questo tema lo affronteremo nel prossimo appuntamento.

Un attaccante ha molte strade perseguibili per ottenere informazioni utili ai suoi scopi. Spesso, come in questo caso, una leggerezza può essere sufficiente a permettere un problema molto più grande. Come sempre abbiamo a disposizione tanti strumenti per migliorare le nostre infrastrutture, per prendercene cura. La consapevolezza deve essere il mantra del 2024, in modo da concentrare l’attenzione dove realmente è necessario.

Stay tuned!