Spoofing dei record DNS tramite l'abuso degli aggiornamenti dinamici DHCP DNS
Analisi riassuntiva
I ricercatori di Akamai hanno scoperto una nuova serie di attacchi sferrati contro i domini Active Directory tramite i server DHCP (Dynamic Host Configuration Protocol) di Microsoft.
Questi attacchi potrebbero consentire ai malintenzionati di falsificare record DNS sensibili con conseguenze diverse, dal furto di credenziali alla compromissione completa del dominio Active Directory. Gli attacchi non richiedono credenziali e funzionano con la configurazione predefinita del server DHCP di Microsoft.
Il numero di organizzazioni colpite può essere significativo. Il server DHCP di Microsoft è molto popolare; è stato osservato in funzione nel 40% delle reti monitorate da Akamai.
Abbiamo segnalato la nostra scoperta a Microsoft, ma non è pianificata nessuna correzione.
In questo post del blog descriviamo nel dettaglio le best practice per la configurazione del server DHCP di Microsoft in modo da mitigare questi attacchi e condividiamo uno strumento che gli amministratori di sistema e i team blu possono utilizzare per individuare le configurazioni a rischio.
In un futuro post del blog, condivideremo i dettagli tecnici sull'implementazione di questi attacchi dal punto di vista di un criminale.
Introduzione
La possibilità di falsificare i record DNS è molto accattivante per i malintenzionati in quanto può portare a conseguenze devastanti, tra cui l'esposizione di dati sensibili, la compromissione delle credenziali e perfino l'esecuzione di codice remoto.
In questo post del blog, esaminiamo una superficie di attacco nel DNS che è stata raramente studiata ed è esposta da una funzione DHCP apparentemente innocua. Utilizzandola, abbiamo scoperto diversi modi in cui i criminali possono falsificare i record DNS sui server DNS Microsoft, tra cui la sovrascrittura non autenticata di record DNS arbitrari.
Insieme ai flussi di attacco, descriviamo nel dettaglio il funzionamento interno di un server DHCP di Microsoft, la sua interazione con DNS e Active Directory e come proteggere adeguatamente queste interfacce. Anche se online esistono molte risorse sparse (e imprecise!) sul DHCP, crediamo che questo post del blog sia una risorsa accurata e completa sull'argomento, in cui tutte le informazioni critiche per gli esperti di sicurezza sono presentate in un unico posto.
DNS e Active Directory
Il nostro percorso inizia con Active Directory (AD). AD si affida completamente al DNS per funzionare. Ogni dominio ha bisogno di un server DNS che ospita una zona DNS speciale chiamata zona ADIDNS (Active Directory Integrated DNS) (Figura 1). Questa zona viene utilizzata per ospitare i record DNS di tutti i computer aggiunti al dominio e dei diversi servizi di AD.
Figura 1. La zona ADIDNS predefinita
I record delle zone ADI vengono gestiti tramite una funzione DNS chiamata Aggiornamenti dinamici. Questa funzione consente a ciascun client di essere responsabile del proprio record: quando deve creare o modificare il proprio record DNS, il client invia una richiesta DNS speciale che include i dati da modificare sul server (Figura 2). Quando il server DNS riceve questa richiesta, modifica di conseguenza i record del client.
Figura 2. Esempio di contenuto di un aggiornamento del DNS
Una delle funzioni più importanti degli Aggiornamenti dinamici del DNS è Aggiornamenti sicuri, progettata per controllare chi può modificare ogni record DNS della zona. Senza Aggiornamenti sicuri, il server DNS obbedisce ciecamente a qualsiasi richiesta di aggiornamento, consentendo ai criminali di sovrascrivere facilmente i record esistenti. Con questa funzione, per impostazione predefinita, il server DNS accetta solo aggiornamenti sicuri per le zone ADI (Figura 3).
Figura 3. Impostazioni predefinite degli aggiornamenti dinamici del DNS
Quando si utilizza Aggiornamenti sicuri, tutte le richieste di aggiornamento ricevute dal server vengono autenticate e autorizzate; nelle zone ADI, questa operazione viene eseguita tramite Kerberos. Quando un aggiornamento viene inviato al server, esso include un ticket Kerberos che viene utilizzato per autenticare l'utente (Figura 4). Per ulteriori informazioni sul processo di autenticazione Kerberos tramite DNS, fare riferimento alla ricerca di Dirk-Jan Mollema su inoltro di Kerberos tramite DNS.
Figura 4. Un ticket Kerberos all'interno di un aggiornamento del DNS
Ogni record DNS è protetto da un elenco di controllo degli accessi (ACL) che determina i diritti di accesso per ogni principale. Questi diritti di accesso sono determinati al momento della creazione iniziale del record: Quando un client crea un record DNS inviando un Aggiornamento dinamico DNS, l'account del computer che ha creato il record DNS viene automaticamente assegnato come proprietario del record e riceve i permessi su di esso. Normalmente, ogni client DNS utilizza il ticket account del proprio computer per eseguire gli aggiornamenti DNS. Per autorizzare una richiesta di aggiornamento, il server DNS verifica l'ACL del record con il principale autenticato.
Nella Figura 5, possiamo vedere l'ACL per il record DNS dell'host "PC.aka.test". Questo record è stato creato dall'account del computer, perciò dispone dei permessi per modificarlo.
Figura 5. ACL del record DNS predefinito
Gli altri principali (ad eccezione di alcuni gruppi forti integrati) non dovrebbero disporre di permessi sul record. Quando un altro principale tenta di modificare un record DNS di cui non è proprietario o su cui non ha i permessi, il server rifiuta l'aggiornamento.
Le zone ADIDNS possono essere molto interessanti per i criminali. Una precedente ricerca di Kevin Robertson di NETSPI ha evidenziato alcuni interessanti attacchi a queste zone DNS. Volevamo espanderci su questa superficie di attacco, quindi abbiamo iniziato a indagare su altre funzionalità correlate e ne abbiamo individuata una interessante: gli Aggiornamenti dinamici DNS DHCP.
Aggiornamenti dinamici DHCP DNS
Il DHCP è un protocollo di gestione della rete utilizzato per assegnare automaticamente indirizzi IP e altre opzioni di rete ai client. Quando un client si unisce a una nuova rete, cerca di raggiungere un server DHCP inviando un messaggio di trasmissione per richiedere le configurazioni di rete. Quando un server DHCP riceve questa richiesta, risponde al client con un indirizzo IP assegnato.
Il DHCP è un protocollo molto comune che viene utilizzato nella maggior parte delle reti aziendali e il server DHCP di Microsoft, in particolare, è un'opzione molto popolare; abbiamo notato che il server DHCP di Microsoft è in esecuzione sul 40% delle reti di data center che monitoriamo.
Sebbene i moderni client Windows (a partire da Windows 2000) normalmente creino i propri record inviando gli Aggiornamenti dinamici del DNS, non è sempre così. I record DNS possono essere creati anche tramite una funzione DHCP chiamata Aggiornamenti dinamici DHCP DNS. Lo scopo di questa funzione è quello di consentire a un server DHCP di registrare i record DNS per conto dei suoi client. Ogni volta che un client riceve un indirizzo IP dal server DHCP, quest'ultimo può contattare il server DNS e aggiornare il record DNS del client. Per eseguire questi aggiornamenti, il server DHCP utilizza (sorpresa, sorpresa!) Aggiornamenti dinamici del DNS.
La somiglianza dei nomi può creare confusione, quindi facciamo chiarezza:
Funzione |
Protocol |
Finalità |
|---|---|---|
Aggiornamenti dinamici del DNS |
DNS |
Consente ai client DNS di creare o modificare i record DNS sul server DNS |
Aggiornamenti dinamici DHCP DNS |
DHCP |
Consente ai server DHCP di creare o modificare i record DNS per conto dei suoi client; gli aggiornamenti vengono eseguiti usando Aggiornamenti dinamici del DNS |
Il processo di Aggiornamento dinamico DHCP DNS è mostrato nella Figura 6.
Figura 6. Processo di aggiornamento dinamico del DHCP DNS
Il client DHCP ottiene un indirizzo IP dal server DHCP e gli comunica il proprio FQDN.
Il server DHCP invia una richiesta di Aggiornamento dinamico al server DNS.
Il server DNS convalida la richiesta, crea un record pertinente e informa il server DHCP del risultato in una risposta di Aggiornamento dinamico.
Tenete presente che, anche se la funzione Aggiornamenti dinamici DHCP DNS è abilitata, la configurazione predefinita richiede che il client specifichi esplicitamente che un record DNS deve essere creato per conto suo (Figura 7).
Figura 7. Configurazione predefinita degli aggiornamenti dinamici del DHCP DNS
Per specificarlo, il client deve inviare un'opzione DHCP dedicata. Le opzioni DHCP (Figura 8) sono campi extra che possono essere aggiunti a un pacchetto DHCP e sono utilizzati dal client e dal server per scambiare informazioni.
Figura 8. Esempio delle opzioni DHCP
Per la nostra causa, il client invia l'opzione FQDN, specificata in RFC 4702. Questa opzione consente al client DHCP di comunicare al server il suo nome di dominio completo (FQDN) e di specificare se deve registrare un record DNS per conto del client. A tal fine, il client può utilizzare il flag del server, che fa parte dell'opzione FQDN. Impostando il flag su 1 si indica al server che deve creare un record basato sull'FQDN fornito (Figura 9).
Figura 9. Richiesta DHCP con l'opzione FQDN
Dopo aver ricevuto questa richiesta, il server DHCP invia un aggiornamento dinamico del DNS e crea il record richiesto (Figura 10).
Figura 10. Zona ADI DNS con il nostro nuovo record
Questa funzione è utile, ma non è utilizzata comunemente al giorno d'oggi (come affermato, la maggior parte dei client Windows moderni crea semplicemente i propri record). Nonostante ciò, i server DHCP di Microsoft hanno questa funzione abilitata per impostazione predefinita, il che significa che il server DHCP registrerà un record DNS per qualsiasi client che lo richieda.
Tenete presente che gli Aggiornamenti dinamici DHCP DNS non richiedono l'autenticazione da parte del client DHCP, pertanto chiunque nella rete può ottenere un IP da un server DHCP e un malintenzionato può essenzialmente utilizzare il server DHCP per autenticarsi sul server DNS per proprio conto. Ciò consente al criminale di accedere alla zona ADIDNS senza alcuna credenziale.
Microsoft sembra essere consapevole dei rischi potenziali che questa funzione comporta e ne riconosce alcuni, ma questa superficie di attacco è ancora per lo più sconosciuta ai malintenzionati e agli esperti di sicurezza.
Le sezioni seguenti illustrano in dettaglio gli attacchi che potrebbero essere eseguiti abusando degli Aggiornamenti dinamici DHCP DNS.
Spoofing DNS DHCP
Gli attacchi di spoofing ADIDNS precedentemente descritti hanno utilizzato come arma ADIDNS per migliorare il classico spoofing LLMNR/NBNS . Dopo aver individuato i tentativi di risoluzione dei nomi non riusciti ("host morti"), un malintenzionato potrebbe registrare il nome nella zona ADI, facendo sì che i futuri tentativi di risoluzione dei nomi puntino al proprio computer.
Questo attacco potrebbe essere molto efficace, ma ha un prerequisito importante: credenziali di dominio valide. Utilizzando il server DHCP, possiamo aggirare questo requisito e operare senza credenziali.. Possiamo semplicemente inviare un Aggiornamento dinamico DHCP DNS per qualsiasi FQDN che non esiste nella zona ADI e il server DHCP lo creerà per noi. Chiamiamo questa variante dell'attacco Spoofing DNS DHCP. Questa tecnica è stata anche trattata in un post sul blog da Hans Lakhan di TrustedSec.
Quali nomi DNS potremmo utilizzare per questo attacco? Attingendo sempre alla ricerca di Robertson, alcuni candidati ovvi non funzionerebbero.
Tale famigerato nome host WPAD verrebbe bloccato dall'elenco globale di query da bloccare (GQBL) sul server DNS.
Il record jolly ("*") non può essere creato tramite gli aggiornamenti dinamici del DNS, quindi non può essere abusato in questo scenario.
Senza questi due candidati, ci rimane l'opzione di identificare gli host morti che sono specifici della rete. Possiamo identificarli effettuando lo sniffing della rete alla ricerca di trasmissioni di risoluzione dei nomi tramite LLMNR (Link-Local Multicast Name Resolution) o NBT-NS (NetBIOS Name Service). Dopo aver identificato un potenziale host obsoleto, possiamo creare un record DNS corrispondente inviando un aggiornamento dinamico del DNS DHCP (Figura 11).
Figura 11. Utilizzo dell'aggiornamento dinamico del DHCP DNS per falsificare gli hostname obsoleti
Un host della rete cerca di risolvere il nome "PC.aka.test" e invia una query al server DNS.
"PC.aka.test" è sconosciuto al server DNS, che risponde con "Nessun nome simile".
L'host invia quindi un multicast LLMNR per cercare di individuare "PC.aka.test" nella propria LAN.
Il malintenzionato identifica questo tentativo e richiede un IP al server DHCP con "PC.aka.test" come FQDN.
Il server invia una richiesta di Aggiornamento dinamico al server DNS e il record viene creato.
Ora, la prossima volta che un host della rete cercherà di risolvere "PC.aka.test", verrà reindirizzato al criminale. Tutto ciò che l'attaccante deve fare ora è utilizzare ntlmrelayx.py e aspettare i tentativi di autenticazione.
Questo approccio è migliore sia del metodo di spoofing LLMNR/NBNS standard sia della variante di spoofing ADIDNS.
Lo spoofing LLMNR/NBNS classico non richiede autenticazione, ma è limitato alle vittime nella stessa LAN (poiché LLMNR/NBNS si basano sulla trasmissione).
Lo spoofing ADIDNS ci ha consentito di colpire vittime al di fuori della LAN (poiché il DNS funziona attraverso le sottoreti), ma richiede un utente autenticato.
Con gli Aggiornamenti dinamici DHCP DNS otteniamo il meglio dei due mondi: l'attacco funziona su vittime al di fuori della LAN e non richiede alcuna autenticazione.
È fantastico, ma possiamo fare ancora meglio.
Sovrascrittura dei record esistenti
Creare record DNS non esistenti è meraviglioso, ma questo ci ha portato a pensare a un'altra opzione: Cosa succede se cerchiamo di creare un record per un nome host già esistente? Possiamo sovrascriverlo in qualche modo? Idealmente, non dovrebbe essere possibile, giusto? Beh...
Abbiamo identificato dei casi in cui i criminali aggressori sono riusciti a sovrascrivere i record esistenti. Chiamiamo questa tecnica Sovrascrittura DHCP DNS. Prima di analizzare questi casi, discutiamo di altri dettagli sul processo degli Aggiornamenti dinamici DHCP.
Tipi di record DNS e relativi proprietari
Nel contesto degli attacchi DHCP DNS, è importante distinguere tra due tipi di record DNS (Figura 12). D'ora in avanti utilizzeremo i seguenti termini:
Record dei client: Record creati direttamente dai client Windows
Record gestiti: Record creati dal server DHCP per conto dei client
Figura 12. Tipi di record DNS
La differenza fondamentale tra questi client è il loro proprietario. Come abbiamo descritto precedentemente in questo post, quando viene eseguito un aggiornamento DNS, viene creato un record client e il principale che ha inviato la richiesta di aggiornamento viene designato come proprietario del record. Per i normali client Windows, questo principale è l'account computer del client.
Ci si potrebbe aspettare che anche i record gestiti siano di proprietà del client richiedente, ma non è così. Quando il server DHCP invia gli aggiornamenti DNS per conto dei client, si autentica anche usando l'account del proprio computer, che diventa il proprietario del record.
Possiamo vedere questa differenza nella Figura 12. PC2 è un record client di proprietà del client, mentre PC1 è un record gestito di proprietà del server DHCP.
Gli elenchi di controllo degli accessi limitano la sovrascrittura DNS DHCP
Quando tentiamo di eseguire un aggiornamento dinamico DHCP DNS su un record esistente (in questo caso, il record "PC.aka.test", l'operazione non riesce. Viene osservato un interessante comportamento: Il server DHCP invia effettivamente un aggiornamento DNS con il nostro FQDN fornito, ma l'aggiornamento viene rifiutato dal server (Figura 13).
Figura 13. Aggiornamento DHCP DNS rifiutato dal server
Questo accade perché il server DHCP non è autorizzato a modificare il record.
PC.aka.test è un record client , che appartiene al PC$ principale. Quando il server DHCP invia l'aggiornamento del DNS, si autentica utilizzando l'account del proprio computer, ossia DHCP$. Poiché questo account non dispone delle autorizzazioni necessarie per il record, l'aggiornamento viene rifiutato (Figura 14).
Figura 14. Sovrascrittura del record DNS non riuscita
Per riassumere: È possibile, per i criminali, utilizzare il server DHCP per inviare aggiornamenti DNS arbitrari, ma i record DNS dovrebbero essere protetti dagli attacchi di sovrascrittura grazie ai loro ACL.
Una volta compreso il meccanismo che dovrebbe impedire la sovrascrittura, vediamo come potrebbe comunque essere eseguita.
Sovrascrittura dei record gestiti
Anche se la sovrascrittura dei record del client esistenti non riesce a causa degli ACL restrittivi, la sovrascrittura dei record gestiti (creati dal DHCP) invece riesce, poiché il computer di autenticazione è anche proprietario del record (Figura 15).
Questo è possibile perché un server DHCP non verifica la proprietà del record DNS e invia un aggiornamento DNS per qualsiasi FQDN richiesto.
Figura 15. Sovrascrittura dei record DHCP DNS gestita dal server DHCP
Come possiamo vedere, il server DHCP esegue l'aggiornamento utilizzando lo stesso account che possiede il record - il proprio - e quindi l'aggiornamento va a buon fine.
Vediamo un esempio. Avviamo un server Ubuntu, che non fa parte del dominio e quindi non può registrare il proprio record DNS. Il server Ubuntu richiede al server DHCP di effettuare l'operazione per suo conto (Figura 16).
Figura 16. Il server DHCP registra un record DNS per conto del server Ubuntu
Questo record è di proprietà dell'account del server DHCP. Ora, dal computer da cui stiamo sferrando l'attacco, richiediamo lo stesso FQDN al server DHCP nel processo di lease. Controlliamo la zona DNS per verificare che la nostra sovrascrittura sia riuscita e che il record ora punti all'IP che ci è stato appena fornito (Figura 17).
Figura 17. Record DNS del Ubuntu sovrascritto
Questo attacco va a buon fine, ma il suo impatto è piuttosto limitato perché riguarda solo i record gestiti. Come abbiamo menzionato prima, questi record sono molto meno comuni dei record client, che non sono interessati da questo attacco. Ciononostante, i record gestiti possono comunque essere trovati in alcuni casi in cui il client non è in grado di registrare il proprio record, ad esempio:
Client non Windows
Client Windows legacy
Client Windows che hanno disabilitato gli aggiornamenti DNS del client
Auto-sovrascrittura del DHCP
Per incrementare il potenziale impatto, vogliamo essere in grado di sovrascrivere i record presenti in qualsiasi zona ADI: i record del client. Il problema è che questi record sono di proprietà dei computer che li hanno creati e possiamo autenticarci solo utilizzando l'account computer del server DHCP.
Ma cosa dire del record DNS del server DHCP? Quando il server DHCP crea il proprio record DNS, il suo account computer diventa il proprietario del record! Scopriamo che possiamo fare in modo che il server DHCP esegua la sovrascrittura DNS DHCP su se stesso. Se forniamo il nome del server DHCP come FQDN, il server DHCP invierà un aggiornamento DNS per il proprio record client e la sovrascrittura avrà buon esito!
La Figura 18 mostra il flusso di questo attacco.
Figura 18. Sovrascrittura dei record DNS del server DHCP
Questo attacco è più affidabile: Se nella rete è presente un server DHCP Microsoft, è garantito un record client corrispondente, mentre i record gestiti (necessari per lo scenario di sovrascrittura precedente) sono più rari.
Quanto all'impatto, i malintenzionati potrebbero intercettare qualsiasi comunicazione destinata al server DHCP. La gravità dipenderebbe dalla natura del traffico. Nella maggior parte dei casi, la capacità di intercettare le comunicazioni destinate al server DHCP potrebbe essere sfruttata per intercettare le credenziali e ritardarle, oppure per catturare il traffico sensibile di altri servizi che potrebbero essere installati sul server.
Parlando di servizi sensibili: Cosa succede se il server DHCP è installato su un controller di dominio (DC)? Possiamo sovrascrivere il record del DC? Ebbene, scopriamo che possiamo farlo.
Sovrascrittura arbitraria del DC DHCP
Se il server DHCP è installato su un DC, possiamo eseguire una sovrascrittura DHCP DNS sul record del DC stesso (per i motivi descritti in precedenza in questo post). Ciò può essere molto utile, ma possiamo fare di più.
Come già sappiamo, se il server DHCP è installato su un DC, l'account computer del DC verrà utilizzato per l'invio degli aggiornamenti DNS. Stranamente, se esaminiamo l'ACL predefinito di un record DNS arbitrario, notiamo che il gruppo principale ENTERPRISE DOMAIN CONTROLLERS dispone delle autorizzazioni in scrittura su ogni record DNS presente nella zona, indipendentemente dal suo autore (Figura 19).
Figura 19. ACL predefinito di tutti i record del dominio contenente il gruppo ENTERPRISE DOMAIN CONTROLLERS
Si tratta di un aspetto importante. Se il server DHCP è un DC, dispone delle autorizzazioni necessarie su tutti i record presenti nella zona e i criminali potrebbero utilizzarlo per sovrascrivere i record A del DNS presenti all'interno della zona ADI, come se si trattasse di un utente non autenticato! L'attacco è illustrato nella Figura 20.
Figura 20. Sovrascrittura DHCP DNS quando il server DHCP è un DC
I nostri dati mostrano che questa configurazione rischiosa è piuttosto comune; tra le reti che abbiamo osservato utilizzare il server DHCP di Microsoft, il 57% ha un server DHCP installato su un DC. Tutti questi domini sono vulnerabili per impostazione predefinita.
Sebbene questo rischio sia stato riconosciuto da Microsoft nella sua documentazione, riteniamo che la consapevolezza di questa errata configurazione non sia in linea con il suo potenziale impatto.
Mitigazioni per gli attacchi DHCP DNS e come aggirarli
Tutti gli attacchi descritti finora funzionano con la configurazione predefinita dei server DHCP di Microsoft. Tuttavia, esistono due impostazioni che potrebbero contribuire a mitigare alcuni di essi. Diamoci uno sguardo e vediamo come possono essere aggirate.
Protezione del nome DHCP
Come sappiamo, quando un server DHCP crea un record DNS, non c'è niente che impedisca ad altri client di richiedere lo stesso FQDN e forzare il server a sovrascriverlo. La protezione del nome è una funzione progettata per evitare che ciò accada.
La protezione del nome viene implementata utilizzando un tipo di record DNS speciale, il DHCID (identificatore client DHCP). Con la protezione dei nomi abilitata, ogni volta che un server DHCP server registra un record per conto di un client, viene creato un altro record DHCID (Figura 21).
Figura 21. Record DHCID creato da un server DHCP con la protezione dei nomi abilitata
Come potete vedere, il valore del record DHCID è un blocco di dati codificato in Base64. Questo valore (che analizzeremo più avanti in questo post) è una firma univoca destinata a identificare il client DHCP che ha richiesto la creazione o l'aggiornamento del record.
Quando al server DHCP viene richiesto di modificare un record DNS, esso calcola il valore DHCID del client e invia un aggiornamento DNS che include i dati aggiornati insieme al valore DHCID.
Se il record non esiste già sul server DNS, crea semplicemente il record e il record DHCID corrispondente. Tuttavia, se i record Host (A) e DHCID esistono già, il valore DHCID esistente viene confrontato con quello inviato dal server DHCP. L'aggiornamento viene eseguito solo se i valori corrispondono.
Quindi, in sostanza, il record DHCID associa un record DNS al client che lo ha creato. Dopo aver creato questa associazione, solo il client originale sarà in grado di apportare modifiche al record.
Bypass della protezione dei nomi
Abbiamo trovato un modo per aggirare la protezione del nome utilizzando un messaggio di rilascio DHCP, un messaggio inviato dai client DHCP per informare il server quando non c'è più bisogno dell'indirizzo IP dedicato. Per tenere traccia degli indirizzi forniti, il server DHCP mantiene una tabella in cui vengono memorizzati i vari indirizzi, le relative date di scadenza e l'identificatore univoco del client che li ha consentiti (Figura 22).
Figura 22. Inserimento della tabella degli indirizzi consentiti nel server DHCP
L'identificatore univoco è semplicemente l'indirizzo MAC del client. Quando riceve un messaggio di rilascio da un client, il server DHCP cerca una voce esistente con indirizzo e ID corrispondenti e, se la trova, la cancella. Se gli Aggiornamenti dinamici DHCP DNS sono abilitati, oltre a liberare l'indirizzo IP, il server DHCP invia anche un aggiornamento dinamico DNS per eliminare il record DNS del client associato.
Se riusciamo a inviare un rilascio DHCP con un ID univoco (indirizzo MAC) che corrisponde all'ID del nostro target, il server DHCP eliminerà il record, consentendoci di registrarlo per noi stessi. L'unico requisito per aggirare la protezione del nome è l'indirizzo MAC della vittima! (Tenete presente che non è necessario cambiare il nostro MAC effettivo: il valore viene preso dall'intestazione del DHCP).
Se ci troviamo sulla stessa LAN del target, trovare il suo MAC è alquanto banale; ad esempio, possiamo trovarlo inviando una richiesta ARP. Ma se non siamo sulla stessa LAN? Abbiamo un'altra opzione.
Forzare i record DHCID per aggirare la protezione del nome
I record DHCID sono definiti in RFC 4701, e il loro algoritmo è piuttosto semplice:
Concatenare i seguenti valori:
DHCP HTYPE (tipo di hardware). Per Ethernet, il valore è 01.
Opzione ID client DHCP
Record FQDN (in formato wire DNS)
SHA256 il risultato
Aggiungere i bit di dati DHCID (nell'implementazione di Windows, questo valore è costante)
Codificare il risultato in Base64
La Figura 23 mostra un esempio di calcolo DHCID.
Figura 23. Esempio di calcolo del DHCID
Poiché conosciamo l'FQDN e i bit di dati sono costanti, l'unica variabile è l'ID del client, che è di nuovo l'indirizzo MAC del client.
I record DHCID sono normali record DNS, quindi qualsiasi client può chiedere al server DNS il loro valore. Poiché conosciamo l'algoritmo per calcolare un record DHCID, possiamo iterare tutti i possibili indirizzi MAC, quindi calcolare il loro valore DHCID e confrontare ogni risultato con il nostro record di destinazione. Quando otteniamo una corrispondenza, sappiamo di aver trovato l'indirizzo MAC corretto. Ciò permette ai criminali di forzare l'indirizzo MAC in tempi ragionevoli: 248 possibili indirizzi MAC potrebbero essere decifrati da un computer moderno e dedicato in soli pochi giorni. Siamo in grado di ridurre significativamente questo tempo solo se utilizziamo solo ID di vendor comuni. Un esempio di questo processo è illustrato nella Figura 24.
Figura 24. Eliminazione di un record DNS con protezione dei nomi abilitata
Tale codice di riferimento può essere utilizzato per calcolare il valore del DHCID in base ai parametri specificati.
Mitigazione degli effetti collaterali della protezione dei nomi
La protezione dei nomi DHCP è destinata ai record gestiti: in sostanza, il server DHCP protegge i record che ha creato dalla modifica da parte di client casuali. La protezione del nome non ha nulla a che fare con i record del client.
Nonostante tutto, in alcuni casi, la protezione del nome può comunque mitigare gli attacchi ai record del client.
Quando si aggiornano i record DNS con la protezione del nome abilitata, il server DHCP richiede la presenza di un record DHCID. Poiché i client DNS normali non creano record DHCID, i record del client non li hanno. Di conseguenza, qualsiasi tentativo di aggiornare il record di un client da parte di un server DHCP non riesce (Figura 25).
Figura 25. L'aggiornamento del DNS non riesce se un record DHCID non è esistente
Ciò accade a causa del modo in cui è implementata la protezione del nome. Quando un server DHCP con la protezione del nome abilitata invia un aggiornamento DNS, aggiunge un campo Prerequisiti alla richiesta. Questo campo specifica le condizioni che devono essere soddisfatte sul server DNS affinché l'aggiornamento DNS avvenga. In Figura 26, possiamo vedere che l'aggiornamento del DNS inviato dal server DHCP include un prerequisito per il valore DHCID.
Figura 26. Prerequisiti dell'aggiornamento del DNS
Ciò significa che l'aggiornamento non andrà a buon fine se non esiste un valore corrispondente. Poiché i record del client non devono mai avere un record DHCID, se la protezione del nome è abilitata, i record del client dovrebbero essere protetti dagli attacchi di sovrascrittura DHCP DNS senza un modo per bypassare questa funzione. In teoria.
In realtà, la protezione del nome non lo prevede (forse è più un effetto secondario) poiché, per definizione, questa funzione è concepita solo per i record gestiti e, per la logica che abbiamo appena descritto, quindi, può anche proteggere i record del client. Tuttavia, anche questa difesa accidentale può essere bypassata.
Il server DHCP viene in soccorso?
I server DHCP supportano la capacità di definire più ambiti, dove per ambito si intende una serie definita di indirizzi IP in una specifica sottorete che il DHCP può concedere (Figura 27).
Figura 27. Esempio degli ambiti DHCP
La separazione in ambiti consente una migliore gestione della distribuzione degli indirizzi e anche l'applicazione di diverse policy per le varie sottoreti. La protezione del nome è una di queste policy e viene abilitata a livello di ambito a indicare che varie ambiti possono avere diverse configurazioni.
Come menzionato in precedenza in questo post, quando abbiamo tentato di eseguire una sovrascrittura del DHCP DNS su un record del client, l'operazione non è riuscita perché l'ambito DHCP disponeva della protezione del nome. Ma c'è un aspetto importante da comprendere: l'ambito è un termine DHCP. I record del client non ne sono consapevoli e non sono associati ad alcun ambito.
Pertanto, se possiamo ottenere un lease da un altro ambito con la protezione del nome disabilitata, possiamo "bypassare" questa mitigazione. (Come ottenere un lease da un altro ambito con la protezione del nome disabilitata, non è oggetto di questo post, ma potete consultare l'opzione del relè DHCP)
Pertanto, anche se la protezione del nome è disabilitata su un solo ambito sul server, è sufficiente per consentire ad un criminale di sovrascrivere i record del client (se è presente una delle configurazioni errate descritte in precedenza).
Credenziale DNS
Un'altra impostazione che può essere configurata sul server DHCP è la credenziale DNS. Questa impostazione ci consente di fornire le credenziali di un utente del dominio e di farle utilizzare dal server DHCP anziché dall'account del computer durante la creazione e l'aggiornamento dei record (Figura 28).
Figura 28. Configurazione delle credenziali DHCP DNS
Torniamo all'esempio in cui un server DHCP è stato installato su un DC. Al momento di aggiornare i record DNS, è stato usato l'account del computer DC, che dispone delle autorizzazioni necessarie sui record presenti nella zona. Con una credenziale DNS configurata, si potrebbe usare invece un account debole e l'attacco non avrebbe esito positivo.
La configurazione di una credenziale DNS è molto importante perché consente di ridurre la superficie di attacco che espone il server DHCP e dovrebbe riuscire a mitigare gli attacchi più gravi descritti in precedenza.
Tuttavia, esistono due punti da considerare quando si utilizza questa funzione:
La credenziale configurata deve essere un utente debole. Se configuriamo la credenziale come amministratore del dominio, ad esempio, il server DHCP riuscirà comunque a sovrascrivere i record arbitrari
I record DNS creati dal server DHCP devono comunque essere di proprietà della stessa credenziale e sono, comunque, vulnerabili agli attacchi di sovrascrittura DHCP DNS.
Gruppo DNSUpdateProxy
Durante la nostra analisi del DHCP di Microsoft e della sua interazione con il DNS, abbiamo individuato un'altra funzione di cui è possibile abusare, il gruppo DNSUpdateProxy . Questo gruppo è concepito per risolvere due problemi dei record gestiti correlati con le autorizzazioni: l'aggiornamento del client e la presenza di più server DHCP.
Problema di aggiornamento del client
Consideriamo innanzitutto il problema di aggiornamento del client: un client tradizionale utilizza inizialmente il server DHCP per registrare un record DNS, ma viene aggiornato ad un sistema operativo più recente che supporta gli aggiornamenti dinamici del DNS. Il client non può modificare il suo record direttamente perché è di proprietà del server DHCP che l'ha creato.
Per risolvere questo problema, è possibile aggiungere il server DHCP al gruppo DNSUpdateProxy.
Questo gruppo ha due effetti: Innanzitutto, quando i suoi membri creano un record DNS, l'ACL del record è diverso dai record gestiti normalmente: al gruppo degli utenti autenticati viene fornita l'autorizzazione in scrittura sul record. Ciò significa che ogni client presente nel dominio può modificarlo (Figura 29).
Figura 29. ACL del record DNSUpdateProxy
Il secondo effetto è una funzione di "controllo del record", ossia al primo client che modifica un record creato da un membro del gruppo DNSUpdateProxy viene concessa la proprietà del record e viene rimossa l'autorizzazione in scrittura agli utenti autenticati. In tal modo, viene risolto il problema di aggiornamento del client, che può quindi modificare e assumere il controllo dei suoi record quando gli viene richiesto.
Presenza di più server DHCP
Il secondo problema insorge quando a più server DHCP viene richiesto di lavorare insieme. In questo esempio, abbiamo due server DHCP ( DHCP1 e DHCP2) e un client PC1 che registra un record DNS tramite il server DHCP1.
Ora, immaginiamo che il server DHCP1 venga disconnesso per qualche motivo e il server DHCP2 venga chiamato in azione. Il lease del client scade, pertanto viene contattato il server DHCP2 per rinnovarlo. Quando il server DHCP2 effettua il lease del nuovo IP e tenta di modificare il record DNS per il client, l'operazione non riesce perché il record è di proprietà del server DHCP1 (Figura 30).
Figura 30. Esempio di più configurazioni del server DHCP
È possibile risolvere nuovamente questo problema utilizzando il gruppo DNSUpdateProxy grazie ad una sua funzione aggiuntiva. Se un membro del gruppo DNSUpdateProxy tenta di modificare un record di proprietà di un altro membro, l'aggiornamento riesce grazie all'ACL, ma questa volta l'ACL e la proprietà non cambiano. In tal modo, più server sono "comproprietari" dei record.
Un rischio per la sicurezza e un bug
A questo punto, dovrebbe essere chiaro che il gruppo DNSUpdateProxy implica un rischio per la sicurezza: tutti i record creati dai membri di questo gruppo possono essere rubati da un qualsiasi utente autenticato. Non si tratta di una vulnerabilità, ma di un abuso del design di questa funzione. Questo rischio è stato riconosciuto da Microsoft.
Oltre a questo rischio, abbiamo identificato un altro problema originato da ciò che sembra essere un bug presente nell'implementazione della funzione DNSUpdateProxy. Quando un membro del gruppo crea il proprio record DNS, utilizza lo stesso ACL vulnerabile, per cui gli utenti autenticati dispongono delle autorizzazioni in scrittura.
La Figura 31 mostra un esempio. Il record dhcp1.aka.test del nostro server DHCP ha un ACL sicuro.
Figura 31. ACL iniziale del server DHCP
Possiamo notare che l'account del computer dispone delle relative autorizzazioni e il gruppo degli utenti autenticati non si trova da nessuna parte. Ora, aggiungiamo il server al gruppo DNSUpdateProxy e attiviamo il processo per ricreare il record DNS. Questo problema si può verificare per vari motivi, ad esempio, se viene cambiato il nome del server. Dopo aver ricreato il record DNS, esaminiamo il nuovo ACL (Figura 32).
Figura 32. ACL vulnerabile del server DHCP
Notiamo che il nuovo record DNS ora può essere scritto dagli utenti del dominio. Ovviamente, non si tratta di una parte prevista della funzione: i record gestiti creati dal server sono progettati per avere un ACL modificato, ma il record del client del server non ne è interessato.
Mitigazione degli attacchi DHCP DNS
Sono molti i rischi relativi agli aggiornamenti dinamici DHCP DNS. Cerchiamo di riepilogare tutte le varie configurazioni possibili del server per comprendere come mitigare gli attacchi appena descritti.
Ci riferiamo a due tipi di record: i record gestiti, che sono stati creati direttamente dal server DHCP, e i record del client, che sono stati creati direttamente dai client Windows.
In breve, è consigliabile:
Disattivare gli aggiornamenti dinamici DHCP DNS se non sono necessari
Configurare un utente debole come credenziale DNS per proteggere i record del client
Utilizzare i record DNS per gli host non Windows sensibili, se possibile, poiché non è possibile proteggere i record gestiti dallo spoofing con qualsiasi configurazione
Non utilizzare il gruppo DNSUpdateProxy, ma usare invece la stessa credenziale DNS per tutti i server DHCP
Credenziale DNS
È il modo migliore per mitigare gli attacchi di sovrascrittura DHCP DNS dei record del client. Configurare un utente debole con una password complessa dedicata a questo scopo. Se si esegue un server DHCP su un DC, questa impostazione è fondamentale, ma non servirà a fermare gli attacchi di sovrascrittura DHCP DNS dei record gestiti.
Protezione del nome
La protezione del nome, in teoria, dovrebbe proteggere i record gestiti, ma, in pratica, i criminali possono bypassarla alquanto facilmente. Tuttavia, è consigliabile abilitare questa funzione per rendere più difficile sferrare attacchi di sovrascrittura.
Benché la protezione del nome non sia concepita per proteggere i record del client, se è abilitata su tutti gli ambiti del server, dovrebbe comunque mitigare gli attacchi di sovrascrittura.
Durante la configurazione della protezione del nome su Microsoft DHCP, ci sono due modi per applicare la funzione: a livello di server o a livello di ambito. Si potrebbe pensare che, se la protezione del nome è abilitata a livello di server, lo è anche a livello di ambito. Beh, non è sempre così. L'abilitazione della protezione del nome a livello di server garantisce solo che la funzione sia abilitata sui nuovi ambiti creati sul server, ma non che sia abilitata anche sugli ambiti esistenti. È importante verificare, quindi, che la protezione del nome sia abilitata anche su tutti gli ambiti sul server.
DNSUpdateProxy
Si consiglia di non usare questo gruppo poiché crea rischi alla sicurezza in quanto tutti i record creati dai suoi membri sono vulnerabili agli attacchi di sovrascrittura.
Se sono presenti più server DHCP e si desidera farli lavorare insieme, è consigliabile invece usare la credenziale DNS. Configurare soltanto la stessa credenziale DNS su tutti i server DHCP per consentire ai server di modificare i record l'uno dell'altro.
Il gruppo DNSUpdateProxy è utile solo se si dispone di client Windows NT 4.0 (o versioni precedenti) che verranno aggiornati a breve. Inoltre, in caso di altri componenti obsoleti, i problemi sono anche maggiori rispetto all'utilizzo del gruppo DNSUpdateProxy.
Se, per qualche motivo, è necessario usare il gruppo DNSUpdateProxy, si consiglia di creare un record DNS statico per ciascun membro del gruppo. Un record statico dovrebbe essere di proprietà dell'account che l'ha creato, solitamente diverso dai vari account dei computer dei server. In tal modo, si impedisce ai server di creare propri record con autorizzazioni non sicure.
Spoofing DNS DHCP
Non c'è modo di impedire ai criminali non autenticati di creare record DNS inesistenti. L'unico modo consiste nel disabilitare gli aggiornamenti dinamici DHCP DNS su tutti i server DHCP. In generale, se gli aggiornamenti dinamici DHCP DNS non sono richiesti nel vostro ambiente, la disabilitazione di questa funzione potrebbe essere una buona idea per eliminare alcuni rischi e aiutare a ridurre la superficie di attacco.
Rilevamento delle configurazioni errate con Invoke-DHCPCheckup
Per aiutarvi a superare la confusione delle possibili configurazioni del DHCP, stiamo rilasciando uno strumento PowerShell denominato Invoke-DHCPCheckup che consente di identificare i rischi correlati agli aggiornamenti dinamici DHCP DNS (Figura 33).
Figura 33. Risultati dell'esempio Invoke-DHCPCheckup
Lo strumento identifica le seguenti configurazioni errate:
Credenziale DNS
Credenziale DNS non configurata
Configurata la credenziale DNS di un utente forte
Protezione del nome
Protezione del nome non abilitata su un ambito
Protezione del nome non abilitata per impostazione predefinita sui nuovi ambiti
DNSUpdateProxy
Visualizzazione dei membri del gruppo
Specificato se i membri sono server DHCP
ACL del record debole
Elenco dei record di proprietà dei server DHCP (record gestiti)
Elenco dei record che possono essere sovrascritti dagli utenti autenticati
Questo strumento si basa sull'API di gestione del server DHCP e richiede l'esecuzione di un utente forte, pertanto lo strumento è concepito principalmente per gli addetti alla sicurezza.
Riepilogo
Abbiamo segnalato tutti i nostri risultati a Microsoft, che ci ha risposto affermando che tutti i problemi sopra menzionati sono intrinseci o non sono abbastanza gravi da dover essere risolti.
Non siamo d'accordo con questa dichiarazione. L'impatto degli attacchi che abbiamo evidenziato può risultare molto significativo: la capacità di sovrascrivere i record DNS senza alcuna autenticazione consente ai criminali di usare un attacco MITM (Machine-In-The-Middle) sugli host presenti nel dominio. Pertanto, le credenziali e le informazioni sensibili possono venire esposte facilmente e attivare anche attacchi relè, consentendo ai criminali di violare i domini AD e scalare i privilegi. Le statistiche che abbiamo condiviso in questo post mostrano quanto solida sia la minaccia per molte reti di data center.
Poiché non è stata pianificata una correzione per questi problemi, incoraggiamo gli addetti alla sicurezza ad esaminare i loro ambienti tramite Invoke-DHCPCheckup per tentare di individuare le configurazioni errate a rischio che abbiamo evidenziato. Vi avvertiamo: se non è stata cambiata la configurazione predefinita, il vostro sistema è vulnerabile.
Tenetevi al passo
In un prossimo post, verrà rilasciato uno strumento, denominato DDSpoof (DHCP DNS Spoof), che consente di implementare tutti gli attacchi descritti in questo articolo. Vogliamo dimostrare come criminali non autenticati possono raccogliere i dati necessari dai server DHCP, identificare i record DNS vulnerabili, sovrascriverli e utilizzare questa capacità per violare i domini AD.
