Quali sono i rischi reali di attivazione di aggiornamenti DNS non sicuri sul dominio intranet di Active Directory?

Question

Quali sono i rischi reali di attivazione di aggiornamenti DNS non sicuri sul dominio intranet di Active Directory?

#1 da (3 voti)

2

In base alla mia attuale ricerca, l'abilitazione degli aggiornamenti DNS non sicuri è un requisito per consentire ai client DHCP Linux di registrare i loro nomi con un FQDN.

Sebbene funzioni correttamente per le macchine Windows aggiunte al dominio, lo stesso non funziona con i client Linux senza abilitare questi aggiornamenti non protetti.

Per quanto ne so una macchina non sarebbe in grado di prendere in mano un altro nome riservato che sarebbe l'unica vera preoccupazione che io ora.

Ovviamente sarebbe il DDOS ma considerando che stiamo parlando di intranet qui, dubito che questo potrebbe essere un rischio reale.

Hai abilitato sul tuo dominio o no?

Hai mai dovuto disabilitarlo a causa di alcuni problemi con esso?

active-directory dns dns-domain

posta sorin 29.10.2015 - 16:33

fonte

1 risposta

Leggi altre domande sui tag active-directory dns dns-domain

Una società dovrebbe distruggere fisicamente il vecchio HDD? esiste una soluzione alternativa per CVE-2015-2625?

score 3 · Accepted Answer

Quando si utilizzano aggiornamenti dinamici protetti, solo i membri del dominio possono aggiornare le loro voci. Questo si ottiene usando kerberos per autenticare il client verso il server DNS. Questa funzionalità di autenticazione non sembra essere implementata nei client DNS di Linux ed è per questo che è necessario abilitare gli aggiornamenti dinamici non sicuri.

Gli aggiornamenti dinamici non sicuri consentono di aggiornare il proprio record DNS senza autenticazione. Questa è chiaramente una minaccia perché il DNS è un protocollo basato su UDP e l'indirizzo di origine può essere facilmente falsificato su una LAN.

D'altra parte questa è una funzionalità documentata pessima e non ci sono strumenti disponibili pubblicamente che potrebbero essere utilizzati per migrare questo attacco.

Non ho mai migrato questo attacco ma ci sono alcuni rischi a cui posso pensare.

Nomi duplicati nel server DNS - o provocheranno in DoS o impediranno una corretta funzionalità di risoluzione del nome host
Reindirizzamento WPAD. Se si nomina il proprio host wpad e si configura un server Web che fornisce una configurazione proxy, è possibile passare una configurazione proxy a Internet Explorer e agli utenti di Chrome. Questo fa parte del protocollo WPAD . La cosa peggiore è che puoi forzare Internet Explorer ad esporre l'hash della password degli utenti autentificati chiedendo l'autenticazione NTLM. So che è inconcepibile, ma questo può essere ottenuto anche da NBNS e LLMNR Avvelenamento utilizzando lo strumento Responder .

// Questo mi ha davvero interessato quando ho avuto il tempo di scrivere uno strumento POC che utilizza questa vulnerabilità.