Skip to main content

Validación de respuesta incorrecta que permite la omisión de DNSSEC · Aviso · dnsjava/dnsjava · GitHub

julio 23, 2024


Resumen

Los registros en las respuestas DNS no se verifican para determinar su relevancia para la consulta, lo que permite que un atacante responda con RR de diferentes zonas.

Detalles

Los mensajes DNS no están autenticados. No garantizan que

  • Los RR recibidos son auténticos
  • No se recibieron los RR no existen
  • Todos o algunos de los registros recibidos en una respuesta se relacionan con la solicitud.

Las aplicaciones que utilizan DNSSEC generalmente esperan que se cumplan estas garantías, sin embargo, DNSSEC por sí solo garantiza las dos primeras.
Para cumplir con la tercera garantía, los resolutores generalmente siguen un procedimiento (no documentado, en lo que respecta a las RFC)1) algoritmo como: (simplificado, por ejemplo, carece de validación DNSSEC)

  1. denotamos por QNAME el nombre que está consultando (por ejemplo, fraunhofer.de.) e inicialice una lista de alias
  2. si la sección RESPUESTA contiene un PTR RRSet válido para QNAMEdevuélvelo (y opcionalmente también devuelve la lista de alias)
  3. si la sección RESPUESTA contiene un RRSet CNAME válido para QNAMEagréguelo a la lista de alias. Establecer QNAME al destino CNAME y vaya a 2.
  4. Comprueba eso QNAME No tiene ningún registro PTR, CNAME ni DNAME que utilice registros NSEC o NSEC3 válidos. Regresar null.

Tenga en cuenta que este algoritmo se basa en registros NSEC y, por lo tanto, requiere que se implemente una parte considerable de las especificaciones DNSSEC. Por este motivo, no puede ejecutarlo un cliente DNS (es decir, una aplicación) y, por lo general, se realiza como parte de la lógica del solucionador.

Hasta donde sabemos, dnsjava no implementa un algoritmo comparable y las API proporcionadas en su lugar devuelven

  • el mensaje DNS recibido en sí (por ejemplo, cuando se utiliza un ValidatingResolver como en este ejemplo), o
  • esencialmente solo el contenido de su sección RESPUESTA (por ejemplo, cuando se usa una LookupSession como en este ejemplo)

Si las aplicaciones filtran ciegamente los resultados recibidos para los RR del tipo de registro deseado (como parece ser el uso típico de dnsjava), un solucionador recursivo no autorizado o (en conexiones UDP/TCP) un atacante de red puede

  • Además de la respuesta DNS real, agregue RR irrelevantes para la consulta pero del tipo de datos correcto, por ejemplo, de otra zona, siempre que esa zona esté usando DNSSEC correctamente, o
  • intercambiar completamente los registros de respuesta pertinentes

Impacto

Las bibliotecas DNS (SEC) generalmente se utilizan como parte de un marco de seguridad más amplio.
Por lo tanto, los principales usos indebidos de esta vulnerabilidad afectan al código de la aplicación, que podría tomar los registros devueltos como respuestas auténticas a la solicitud.
Damos tres ejemplos concretos de dónde esto podría ser perjudicial:

  • RFC 6186 especifica que para conectar a un servidor IMAP para un usuario, un agente de usuario de correo debe recuperar determinados registros SRV y enviar las credenciales del usuario a los servidores especificados. El intercambio de registros SRV puede ser una herramienta para redirigir las credenciales.
  • Al enviar correo a través de SMTP, los registros MX determinan dónde se deben enviar los correos. El intercambio de registros MX puede provocar la divulgación de información. Además, un intercambio de registros TLSA puede permitir a los atacantes interceptar el tráfico TLS.
  • Algunos proyectos de investigación como Más ligero Están intentando administrar los almacenes de confianza de CA a través de registros URI y SMIMEA en el DNS. El intercambio de estos permite manipular la raíz de confianza para las aplicaciones dependientes.

Mitigaciones

En este punto, recomendamos las siguientes mitigaciones:

  • Al utilizar un ValidatingResolver, ignore cualquier indicación del servidor sobre si los datos estaban disponibles o no (por ejemplo, NXDOMAIN, NODATA, …).
  • Para las API que devuelven RR de respuestas DNS, filtre los RR utilizando un algoritmo como el anterior. Esto incluye, por ejemplo: LookupSession.lookupAsync.
  • Elimine las API que manejan mensajes DNS sin procesar de la sección de ejemplos o coloque una advertencia visible arriba.

Si tiene alguna pregunta sobre el informe, no dude en ponerse en contacto con nosotros.
Atentamente,

Thomas Bellebaum, Instituto Fraunhofer AISEC



Source link

Translate »