Utilizzo dello spoofing DHCP DNS - Guida pratica
Introduzione
Nella prima parte di questa serie del blog, abbiamo introdotto una nuova tipologia di attacchi sferrati contro i domini Active Directory tramite i server DHCP (Dynamic Host Configuration Protocol) di Microsoft. Questi attacchi consentono ai malintenzionati di eseguire lo spoofing dei record DNS nelle zone ADIDNS (Active Directory Integrated DNS), sfruttando la funzione degli aggiornamenti dinamici DHCP DNS. Abbiamo esplorato il funzionamento di tali aggiornamenti ed evidenziato le configurazioni errate di cui i malintenzionati potrebbero abusare per falsificare record DNS sensibili.
In questo secondo post, desideriamo approfondire alcuni dettagli tecnici richiesti per sfruttare questa superficie di attacco. Descriveremo in dettaglio i metodi utilizzati per raccogliere tutte le informazioni necessarie per condurre gli attacchi, parleremo di alcune limitazioni degli attacchi e analizzeremo come possiamo falsificare più record DNS tramite l'abuso di un comportamento interessante del server DHCP.
Infine, introdurremo un nuovo strumento da aggiungere al vostro arsenale di difesa. Abbiamo combinato tutte le conoscenze apprese per creare DDSpoof, uno strumento Python che consente ai team rossi e blu di eseguire e studiare gli attacchi DHCP DNS. In una sezione successiva di questo post, descriveremo come lo strumento può essere utilizzato in diversi scenari di attacco.
Dichiarazione di non responsabilità: DDSpoof può aiutare gli addetti alla sicurezza a identificare i rischi, incrementando la consapevolezza della superficie di attacco. L strumento di per sé non è sufficiente a causare danni effettivi poiché richiede l'accesso alla rete e un ulteriore abuso dello spoofing DNS primitivo.
Enumerazione DHCP
Nel post precedente, abbiamo condiviso la teoria alla base dello spoofing DHCP DNS. Di fatto, dobbiamo disporre di diverse informazioni per eseguire efficacemente gli attacchi descritti. Fortunatamente per i malintenzionati, rilevare i server DHCP e scoprire la loro configurazione è una funzionalità che fa parte del protocollo DHCP, il che rende oltremodo semplice il processo di ricognizione.
Nelle sezioni successive, descriveremo i vari metodi e i trucchi che gli autori degli attacchi possono utilizzare da un contesto non autenticato per raccogliere queste informazioni.
Identificazione dei server DHCP
L'elemento più importante di un attacco DHCP DNS è costituito dal server DHCP di destinazione, pertanto il primo passo consiste nell'identificarne uno. Identificare i server DHCP attivi nella rete è molto semplice. Un malintenzionato può inviare un messaggio di trasmissione DHCP Discover e ispezionare le risposte di offerta dei server.
Per inviare messaggi DHCP, possiamo eseguire l'utilità dhclient di Linux, un client DHCP configurabile che consente l'interazione con i server DHCP. Possiamo configurare l'utilità dhclient modificando il relativo file di configurazione, che si trova all'indirizzo /etc/dhcp/dhclient.conf.
Quando viene eseguita, l'utilità dhclient richiede la configurazione di rete del server DHCP e la applica al nostro computer, sovrascrivendo l'attuale indirizzo IP. Per evitare che ciò accada, possiamo eseguirla su un'interfaccia virtuale con la seguente sintassi:
dhclient <interface_name>:<virtual_interface_name>
Una volta eseguito questo comando, possiamo vedere che il nostro indirizzo IP originale (172.25.14.55) rimane invariato, mentre l'interfaccia virtuale ha ricevuto un nuovo indirizzo IP dal server DHCP (Figura 1).
Figura 1. Utilizzo di dhclient su un'interfaccia virtuale e mantenimento dell'IP originale
Se registriamo il traffico e ispezioniamo i messaggi DHCP Offer, potremo identificare tutti i server DHCP attivi (Figura 2).
Figura 2. Invio di un DHCP Discover per identificare i server DHCP attivi nella rete
Ottenimento del dominio del server DHCP e DNS
Una volta identificati i server DHCP nella rete, abbiamo bisogno di sapere su quali record possiamo eseguire lo spoofing tramite ciascun server. Un server DHCP può creare solo record all'interno della zona ADI associata; un server associato al dominio "aka.test" sarà in grado di scrivere solo record DNS aventi lo stesso suffisso: <hostname>.aka.test. Per capire quali record possiamo falsificare, dobbiamo identificare questo suffisso.
Dovremmo inoltre sapere quale server DNS ospiterà i nuovi record, il che ci consentirebbe di interrogarli e verificare il successo dell'attacco.
Un trucco che i malintenzionati possono utilizzare per scoprire questi due parametri è l'opzione Elenco richieste parametri che consente di interrogare il server DHCP per rilevare impostazioni specifiche. Per i nostri scopi, possiamo interrogare il nome di dominio associato al server e le opzioni del server relative al nome di dominio.
Possiamo nuovamente utilizzare l'utilità dhclient. Per aggiungere l'opzione Elenco richieste parametri al messaggio Discover, includiamo la seguente riga nel file di configurazione di dhclient:
request domain-name, domain-name-servers;
Quando eseguiamo dhclient (come in precedenza, su un'interfaccia virtuale) e ispezioniamo il nostro messaggio Discover, vediamo che include l'opzione Elenco richieste parametri con i campi richiesti (Figura 3).
Figura 3. Opzione Elenco richieste parametri contenuta in un messaggio DHCP Discover
Un server DHCP Microsoft in ascolto deve inviare una risposta Offer a questo messaggio Discover con i parametri richiesti (figura 4).
Figura 4. Risposta del server DHCP con le impostazioni richieste
Identificazione dello stato di protezione del nome
Un'altra impostazione importante quando si tenta di abusare della funzione Aggiornamenti dinamici DHCP DNS è la protezione del nome, poiché essa determina sealcuni attacchi di sovrascrittura sono possibili o meno. Non possiamo interrogare direttamente lo stato di protezione del nome, ma esiste un modo semplice per dedurlo, che consiste in quattro passaggi.
Creare un record DNS utilizzando un aggiornamento dinamico DHCP DNS
Verificare che sia stato creato un record A.
Interrogare il server DNS per richiedere un record DHCID con lo stesso nome
Se un record DHCID è presente contestualmente al record A, la protezione del nome è abilitata
Per richiamare un aggiornamento dinamico DHCP DNS utilizzando dhclient, aggiungiamo le seguenti righe al file di configurazione:
send fqdn.fqdn = “kali.aka.test”;
send fqdn.server-update on;
send dhcp-server-identifier 172.25.14.123;
Le prime due righe aggiungono l'opzione FQDN con il flag del server, necessaria affinché il server DHCP registri il record DNS. La terza riga è opzionale e consente di aggiungere un'opzione DHCP dell'identificatore del server per puntare un server DHCP specifico, qualora siano presenti più server.
Una volta eseguita l'utilità dhclient, possiamo utilizzare nslookup per interrogare il server DNS di destinazione e cercare un record DHCID (Figura 5).
Figura 5. Verifica dello stato di protezione del nome con nslookup
In questo caso, possiamo vedere che è stato creato un record DHCID, il che indica che la protezione del nome è abilitata.
Identificazione della configurazione degli aggiornamenti dinamici DHCP DNS
Esistono tre opzioni per determinare in quali casi il server DHCP creerà record DNS per i client (Figura 6). Sapere qual è l'impostazione utilizzata può consentire ai malintenzionati di rilevare le richieste DHCP e identificare quelle che portano alla creazione di un record gestito. In questo modo, è possibile identificare i potenziali obiettivi per la sovrascrittura dei record gestiti, ovvero la falsificazione dei record creati dal server DHCP.
Le tre possibili impostazioni sono le seguenti:
Aggiorna in modo dinamico solo se richiesto dal client. Questa è l'opzione predefinita. L'opzione crea un record DNS solo se nella richiesta è presente un FQDN e il flag del server è impostato.
Aggiorna sempre in modo dinamico. Viene creato un record DNS per qualsiasi richiesta DHCP con un'opzione FQDN, indipendentemente dal valore del flag del server.
Aggiorna in modo dinamico i client che non richiedono aggiornamenti. Crea un record DNS per i client anche quando l'opzione FQDN non è presente; l'FQDN si basa sull'opzione DHCP hostname. Questa opzione supporta i vecchi client DHCP che non utilizzano l'opzione FQDN.
Figura 6. Impostazioni dell'aggiornamento dinamico DHCP DNS
Possiamo dedurre questa impostazione analizzando i suoi "effetti collaterali": attiveremo un aggiornamento dinamico DHCP DNS in diverse condizioni e interrogheremo il server DNS per verificare se è stato creato un record. Questa operazione può essere eseguita utilizzando l'utilità dhclient per il lease di un indirizzo IP e utilizzando nslookup per interrogare il server DNS.
Le configurazioni dhclient richieste per testare ciascuna delle impostazioni possibili sono le seguenti:
Crea record per i client che non richiedono aggiornamenti
# Only include the hostname option, without the FQDN option
send host-name = “test.aka.test”;
send dhcp-server-identifier 172.25.14.123;
Crea sempre record (quando è presente l'opzione FQDN)
# Include the FQDN option, without the server update flag
send fqdn.fqdn = “test.aka.test”;
send dhcp-server-identifier 172.25.14.123;
Crea i record solo se richiesto dal client
# Include the FQDN option and the server update flag
send fqdn.fqdn = “test.aka.test”;
send fqdn.server-update on;
send dhcp-server-identifier 172.25.14.123;
Limitazioni sull'indirizzo dei record falsificati
Affinché il nostro attacco sia efficace, abbiamo bisogno che i record DNS falsificati puntino al nostro computer controllato. Con lo spoofing DHCP DNS, ci affidiamo al server DHCP per creare i record DNS. Purtroppo, non è possibile scegliere un indirizzo IP arbitrario: il server DHCP ha un ambito definito di indirizzi IP interni e rifiuterà di eseguire il lease (e di conseguenza di creare un record DNS) di qualsiasi indirizzo IP al di fuori di tale ambito.
Per questo motivo, l'indirizzo a cui reindirizziamo le comunicazioni è soggetto a due limitazioni:
L'indirizzo non può essere esterno alla rete: non possiamo eseguire il lease di un indirizzo IP esterno al server DHCP e quindi non possiamo utilizzarne uno per lo spoofing.
L'indirizzo non può appartenere a una macchina con indirizzo IP statico: se un computer ha un indirizzo IP statico, è improbabile che tale indirizzo si trovi nel pool di lease di un server DHCP e quindi non può essere utilizzato per lo spoofing.
Poiché abbiamo accesso a una macchina interna che può utilizzare un indirizzo IP dinamico, per lo spoofing dei record possiamo utilizzare solo un indirizzo offerto dal server DHCP.
Per essere certi di utilizzare lo stesso indirizzo quando si eseguono altre azioni, possiamo utilizzare l'opzione Indirizzo IP richiesto . Per farlo, possiamo aggiungere la seguente riga alla configurazione dell' utilità dhclient:
send dhcp-requested-address 172.25.14.55;
Scrittura di più record DNS
Per l'esecuzione dello spoofing DHCP DNS, è molto probabile che desideriamo falsificare più record DNS piuttosto che uno solo, con l'obiettivo di reindirizzare il traffico del maggior numero possibile di vittime. Tuttavia, quando tentiamo di indirizzare più record DNS allo stesso IP di destinazione, possiamo riscontrare un problema.
Quando un server DHCP ha assegnato un determinato indirizzo IP a un host, questo indirizzo IP non può essere assegnato da altri client. Questo comportamento ha lo scopo di evitare conflitti IP tra i vari client. Quando assegniamo un indirizzo IP con un determinato FQDN per eseguire un DDSpoof, questo indirizzo IP viene rimosso dal pool di indirizzi del server. Se cerchiamo di eseguire nuovamente il lease dello stesso indirizzo IP con un FQDN diverso, il server fornisce un indirizzo diverso (Figura 7).
Figura 7. Processo di lease DHCP quando l'indirizzo richiesto è in uso
Non possiamo risolvere il problema rilasciando il lease, perché questo attiverebbe un aggiornamento dinamico DNS da parte del server DHCP per eliminare il record appena rilasciato, causando la rimozione del record precedentemente falsificato (Figura 8).
Figura 8. DHCP Release richiama l'eliminazione del record DNS associato
In altre parole, i nostri obiettivi finali sono:
Liberare l'indirizzo IP, ovvero rimuovere la voce di lease dal server DHCP e restituirla al pool di indirizzi (in modo da poterla utilizzare per registrare un nuovo record DNS)
Impedire l'eliminazione del record DNS falsificato in essere
Abbiamo identificato un comportamento/bug interessante che ci consente di fare proprio questo.
Inviamo un pacchetto DHCP Request al server DHCP che attualmente assegna il nostro indirizzo IP, indicando i seguenti parametri:
L'indirizzo MAC del client utilizzato per ottenere il lease DHCP esistente dal server
L'identificatore di un server diverso dal nostro server di destinazione
Osservando il messaggio di trasmissione in basso, il server DHCP di destinazione "suppone" che stiamo richiedendo un nuovo indirizzo IP a un altro server e che quindi non abbiamo più bisogno di quello esistente (di lease). Pertanto il server eliminerà l'IP di lease senza eliminare il record DNS associato (Figura 9). Il motivo per cui il record DNS non viene eliminato non è chiaro; è probabile che si tratti di un bug logico.
Figura 9. Eliminazione di una voce di lease senza eliminare il record DNS associato
Vediamo tutto questo in azione
Vogliamo creare due record DNS che puntano allo stesso IP. Creiamo il primo record utilizzando l'utilità dhclient come descritto in precedenza. Il nostro record viene creato; se guardiamo la tabella dei lease del server DHCP, possiamo vedere che il lease è presente (Figura 10).
Figura 10. Voce in tabella di un lease DHCP
Ora, modifichiamo l'opzione dhclient dhcp-server-identifier nel file di configurazione sostituendolo con qualsiasi altro IP, eseguiamo di nuovo l'utilità dhclient e vedremo che il lease è stato eliminato.
Ora, basta semplicemente eseguire nuovamente l'utilità dhclient con un FQDN diverso per richiedere lo stesso indirizzo IP, dopo di che creiamo un secondo record (Figura 11).
Figura 11. Più record DNS di attacco puntano allo stesso indirizzo IP
Introduzione di DDSpoof.py
Abbiamo combinato tutte le funzionalità e le tecniche descritte in questa serie di blog per creare DDSpoof, un kit di strumenti che consente di riprodurre le performance degli attacchi al DHCP DNS. Questo strumento Python effettua l'enumerazione del server DHCP, esegue comandi DHCP DNS personalizzati e identifica potenziali obiettivi di spoofing. La funzionalità di DDSpoof è documentata in questo repository.
Nelle sezioni successive, esamineremo diversi scenari di attacco eseguibili con DDSpoof.
Configurazione di DDSpoof
Stiamo eseguendo una macchina di Kali Linux all'interno della nostra rete di destinazione, senza credenziali di dominio. Eseguiremo prima DDSpoof per la scansione della rete e l'identificazione dei potenziali obiettivi (specificando quale interfaccia utilizzare per inviare e ricevere i pacchetti; Figura 12).
Figura 12. Enumerazione DDSpoof iniziale
Possiamo notare che DDSpoof esegue quanto segue:
Identifica tutti i server DHCP raggiungibili e le relative configurazioni
Determina lo stato di protezione del nome
Verifica che l'attuale indirizzo IP sia disponibile per il lease sul server di destinazione
In questo esempio, l'indirizzo IP non è disponibile per il lease sul server di destinazione, pertanto lo modifichiamo manualmente in quello fornito dal server (Figura 13).
Figura 13. Modifica dell'indirizzo IP in un indirizzo disponibile sul server DHCP
Ora, siamo pronti per lo spoofing.
Spoofing DHCP DNS
Per eseguire il nostro primo spoofing DHCP DNS, vogliamo identificare i tentativi di risoluzione dei nomi che non sono andati a buon fine e creare record DNS che puntano al nostro computer. A tale scopo, utilizzeremo il comando start-llmnr di DDSpoof. Questo comando avvia uno sniffer LLMNR che notificherà le interrogazioni LLMNR nella rete, consentendoci di identificare potenziali obiettivi di spoofing (Figura 14).
Figura 14. Utilizzo dello sniffer LLMNR di DDSpoof per l'identificazione degli obiettivi di spoofing
In questa immagine, possiamo vedere che lo sniffer è stato in grado di identificare i file files.aka.test del nome. A questo punto, possiamo utilizzare il comando write-record per tentare di registrare il nome del DNS (Figura 15).
Figura 15. Utilizzo di DDSpoof per eseguire lo spoofing di un record DNS per il nome di destinazione
Come possiamo vedere, DDSpoof crea correttamente il record DNS che punta al nostro indirizzo IP. Possiamo verificarlo con il comando nslookup (Figura 16).
Figura 16. Utilizzo di nslookup per confermare che la creazione del record è riuscita
La prossima volta che un host della rete tenta di risolvere i file files.aka.test del nome, verrà indirizzato alla nostra macchina controllata.
Una volta completato l'attacco, possiamo utilizzare il comando delete-record per rimuovere il nostro record falsificato (Figura 17).
Figura 17. Utilizzo di DDSpoof per eliminare il record con spoofing
Sovrascrittura DHCP DNS
Un'altra opzione disponibile è la sovrascrittura DHCP DNS Osservando di nuovo la figura 12, vediamo che il server DHCP di destinazione è anche un server DNS. Questo ci fa presupporre che il server potrebbe anche essere un controller di dominio (DC), poiché il server DNS è spesso installato su un DC in ambienti Active Directory. Possiamo verificarlo utilizzando il seguente comando nmap:
Nmap -p389 -sV 172.25.14.123
Figura 18. Output Nmap che conferma che il server è un controller di dominio
Se una credenziale DNS non è stata configurata, è possibile sovrascrivere qualsiasi record nella zona ADI. Supponiamo di avere identificato un host denominato file-server.aka.test (Figura 19).
Figura 19. Risultati del comando nslookup per file-server.aka.test
Possiamo tentare di sovrascrivere il record DNS utilizzando il comando write-record di DDSpoof. Se è stata configurata una credenziale DNS debole, questa operazione dovrebbe non andare a buon fine. Nel nostro caso, la credenziale DNS configurata non è debole, quindi la sovrascrittura è andata a buon fine (Figura 20).
Figura 20. Utilizzo di DDSpoof per eseguire una sovrascrittura DHCP DNS del record DNS file-server
Figura 21. Utilizzo del comando nslookup per confermare che la sovrascrittura è andata a buon fine
Bypass della protezione dei nomi
In questo altro scenario, eseguiamo il comando start-dhcp di DDSpoof per rilevare il traffico DHCP, identificando i messaggi DHCP Request (Figura 22).
Figura 22. Utilizzo dello sniffer DHCP di DDSpoof per identificare i potenziali record gestiti
In questo esempio, identifichiamo una macchina denominata ubuntu-server.aka.test che ha inviato una richiesta DHCP contenente il suo FQDN. Questo potrebbe causare la creazione di un record DNS da parte del server DHCP, fornendo l'opportunità di sovrascrivere il record gestito (ricordate che un record gestito viene creato per gli host non Windows che non fanno parte del dominio e pertanto non possono comunicare direttamente con il server DNS).
Ma insorge un problema. Questa volta, il server DHCP di destinazione risulta avere la protezione del nome abilitata (Figura 23).
Figura 23. DDSpoof che enumera un server DHCP con protezione del nome abilitata
Se interroghiamo tutti i record DNS per la nostra macchina ubuntu-server.aka.test di destinazione, vediamo che è presente un record DHCID (Figura 24).
Figura 24. Output nslookup contenente un record DHCID
Ma non temete perché, come sappiamo, la protezione del nome può essere facilmente aggirata.
Per farlo, è sufficiente inviare un messaggio di rilascio DHCP con un ID del client (CID), essenzialmente l'indirizzo MAC del client, corrispondente al proprietario originale del record. Questa operazione farà in modo che il server DHCP elimini il record.
Per procedere, possiamo utilizzare il comando set-cid . Lo forniamo con il CID di destinazione ottenuto in precedenza, lasciando che DDSpoof impersonifichi il client DHCP originale. Fatto questo, possiamo eseguire il comando delete-record per rimuovere il nostro record di destinazione (Figura 25).
Figura 25. Utilizzo di DDSpoof per eliminare un record DNS protetto con la protezione del nome
A questo punto, non ci resta che registrare il nostro nome utilizzando il comando write-record (Figura 26).
Figura 26. Utilizzo di DDSpoof per creare un nuovo record dopo aver eliminato quello originale, eludendo la protezione del nome
Riepilogo
Negli scenari di attacco esaminati in questo post, abbiamo dimostrato come sia possibile eseguire lo spoofing di vari record DNS nei domini Active Directory da un contesto non autenticato. Questa capacità è molto flessibile e i malintenzionati potrebbero abusarne in diversi modi, inclusi i seguenti:
Prendere di mira i computer Windows e intercettare l'autenticazione NTLM o Kerberos, rendendo possibili altri attacchi relè o di forza bruta
Prendere di mira le applicazioni che eseguono protocolli non sicuri e intercettare i dati sensibili
Prendere di mira i record DNS dei server di sicurezza interni, come gli antivirus o i SIEM e bloccare l'accesso ai server
Questi sono solo alcuni esempi di come i malintenzionati possano abusare di questa capacità; ce ne sono molti altri.
Speciale attenzione degli addetti alla sicurezza
La superficie di attacco esposta dagli aggiornamenti dinamici DHCP DNS è molto potente e, dal momento che Microsoft non intende risolvere il problema, probabilmente continuerà a persistere. Incoraggiamo gli addetti alla sicurezza a utilizzare i seguenti strumenti per identificare e mitigare i rischi dello spoofing DHCP DNS, idealmente prima che i malintenzionati possano individuarli:
Invoke-DHCPCheckup: identifica le configurazioni DHCP e DNS in Active Directory
DDSpoof: evidenzia i rischi e verifica la resilienza della superficie di attacco degli aggiornamenti dinamici DHCP DNS
