¿Cuáles son los riesgos reales de habilitar actualizaciones de DNS no seguras en el dominio de intranet de Active Directory?

Question

¿Cuáles son los riesgos reales de habilitar actualizaciones de DNS no seguras en el dominio de intranet de Active Directory?

#1 de davidb (3 votos)

2

Según mi investigación actual, habilitar las actualizaciones de DNS no seguras es un requisito para permitir que los clientes DHCP Linux registren sus nombres con un FQDN.

Si bien esto funciona bien para las máquinas Windows unidas al dominio, lo mismo no funciona para los clientes Linux sin habilitar estas actualizaciones no seguras.

Por lo que sé, una máquina no podría tomar otro nombre reservado, que sería la única preocupación real que tengo ahora.

Obviamente, sería el DDOS, pero considerando que estamos hablando de intranet aquí, dudo que esto pueda ser un riesgo real.

¿Lo tienes habilitado en tu dominio o no?

¿Alguna vez tuvo que deshabilitarlo debido a tener algunos problemas con él?

dns active-directory dns-domain

pregunta sorin 29.10.2015 - 16:33

fuente

1 respuesta

Lea otras preguntas en las etiquetas dns active-directory dns-domain

Llave RSA de Heartbleed Privilegios de administrador de modificación aleatoria de regedit [cerrado]

score 3 · Accepted Answer

Cuando usa actualizaciones dinámicas seguras, solo los miembros del dominio pueden actualizar sus entradas. Esto se logra mediante el uso de kerberos para autenticar al cliente hacia el servidor DNS. Esta funcionalidad de autenticación no parece implementarse en los Clientes DNS de Linux y es por eso que necesita habilitar actualizaciones dinámicas no seguras.

Las actualizaciones dinámicas no seguras permiten actualizar su propio registro DNS sin autenticación. Esto es claramente una amenaza porque DNS es un protocolo basado en UDP y la dirección de origen se puede falsificar fácilmente en una LAN.

Por otra parte, esta es una funcionalidad muy mal documentada y no hay herramientas disponibles públicamente que puedan usarse para migrar este ataque.

Nunca migré este ataque, pero hay algunos riesgos que se me ocurren.

Nombres duplicados en el servidor DNS: resultará en DoS o impedirá una funcionalidad correcta de resolver el nombre de host
redirección de WPAD. Si asigna un nombre a su host wpad y configura un servidor web que proporciona una configuración de proxy, puede pasar una configuración de proxy a los usuarios de Internet Explorer y Chrome. Esto es parte del protocolo WPAD . Lo peor es que puede forzar al explorador de Internet a exponer el hash de contraseña de los usuarios autenticados solicitando la autenticación NTLM. Sé que es increíble, pero esto también puede lograrse mediante NBNS y LLMNR Poisoning utilizando la herramienta Responder .

// Esto realmente me llamó la atención cuando tuve tiempo. Voy a escribir una herramienta POC que usa esta vulnerabilidad.