El envenenamiento de la caché de DNS, un ataque de Internet de 2008, ha vuelto de entre los muertos

El envenenamiento de la caché de DNS, un ataque de Internet de 2008, ha vuelto de entre los muertos
Envenenamiento de DNS
Modificado por última vez en Sábado, 14 Noviembre 2020 20:02
(0 votos)

Un canal lateral recién descubierto en un protocolo ampliamente utilizado permite a los atacantes falsificar dominios

En 2008, el investigador Dan Kaminsky reveló una de las amenazas a la seguridad de Internet más graves de la historia: una debilidad en el Sistema de Nombres de Dominio (DNS) que hizo posible que los atacantes enviaran en masa a los usuarios a sitios impostores en lugar de los reales que pertenecen a Google, Bank of America , o cualquier otro. Con la coordinación de toda la industria, miles de proveedores de DNS en todo el mundo instalaron una solución que evitó este escenario apocalíptico.

Ahora está de vuelta el ataque de envenenamiento de la caché de DNS de Kaminsky. Los investigadores presentaron el miércoles una nueva técnica que una vez más puede hacer que los resolutores de DNS devuelvan direcciones IP falsificadas maliciosamente en lugar del sitio que corresponde legítimamente a un nombre de dominio.

"Este es un avance bastante grande que es similar al ataque de Kaminsky para algunos resolutores, dependiendo de cómo [se] ejecuten realmente", dijo Nick Sullivan, jefe de investigación de Cloudflare, una red de entrega de contenido que opera el Servicio de DNS 1.1.1.1. "Este es uno de los ataques de envenenamiento de caché de DNS más efectivos que hemos visto desde el ataque de Kaminsky. Es algo que, si ejecuta un resolutor de DNS, debe tomarlo en serio".

Primer DNS

Cuando las personas envían correos electrónicos, navegan por un sitio web o hacen casi cualquier otra cosa en Internet, sus dispositivos necesitan una forma de traducir un nombre de dominio a los servidores de direcciones IP numéricas que se utilizan para localizar otros servidores. El primer lugar donde buscará un dispositivo es un resolutor de DNS, que es un servidor o grupo de servidores que normalmente pertenecen al ISP, corporación o gran organización a la que está conectado el usuario.

En el caso de que otro usuario del ISP u organización haya interactuado recientemente con el mismo dominio, el resolutor ya tendrá en caché la dirección IP correspondiente y devolverá el resultado. De lo contrario, el resolutor consultará el servidor autorizado dedicado para ese dominio en particular. El servidor autorizado devolverá una respuesta, que el resolutor proporcionará al usuario y almacenará temporalmente en su caché para cualquier otro usuario que pueda necesitarla en un futuro próximo.

Todo el proceso no está autenticado, lo que significa que el servidor autorizado no utiliza contraseñas u otras credenciales para demostrar que, de hecho, tiene autoridad. Las búsquedas de DNS también se realizan mediante paquetes UDP, que se envían en una sola dirección. El resultado es que los paquetes UDP suelen ser triviales de falsificar, lo que significa que alguien puede hacer que el tráfico UDP parezca provenir de algún lugar distinto del que realmente se originó.

Envenenamiento de la caché de DNS: un resumen

Cuando los arquitectos de Internet idearon por primera vez el DNS, reconocieron que era posible que alguien se hiciera pasar por un servidor autorizado y usara el DNS para devolver resultados maliciosos a los resolutores. Para protegerse contra esta posibilidad, los arquitectos diseñaron la búsqueda de números de transacciones. Los resolutores adjuntaron estos números de 16 bits a cada solicitud enviada a un servidor autorizado. El resolutor solo aceptaría una respuesta si contuviera el mismo ID.

Kaminsky se dio cuenta de que solo había 65.536 posibles ID de transacciones. Un atacante podría aprovechar esta limitación inundando un resolutor de DNS con una IP maliciosa para un dominio con ligeras variaciones (por ejemplo, 1.google.com, 2.google.com, etc.) e incluyendo un ID de transacción diferente para cada respuesta. Eventualmente, un atacante reproduciría el número correcto y la IP maliciosa se enviaría a todos los usuarios que confiaran en el resolutor. El ataque se denominó envenenamiento de la caché de DNS porque contaminó el almacén de búsquedas del resolutor.

El ecosistema DNS solucionó el problema aumentando exponencialmente la cantidad de entropía requerida para que se acepte una respuesta. Mientras que antes, las búsquedas y respuestas viajaban solo por el puerto 53, el nuevo sistema aleatorizaba las solicitudes de búsqueda de número de puerto utilizado. Para que un solucionador de DNS aceptara la dirección IP, la respuesta también tenía que incluir ese mismo número de puerto. Combinado con un número de transacción, la entropía se midió en miles de millones, lo que hace que sea matemáticamente inviable para los atacantes encontrar la combinación correcta.

Vuelta del envenenamiento de cache

El miércoles, investigadores de la Universidad de Tsinghua y la Universidad de California en Riverside presentaron una técnica que, una vez más, hace factible el envenenamiento de caché. Su método aprovecha un canal lateral que identifica el número de puerto utilizado en una solicitud de búsqueda. Una vez que los atacantes conocen el número, una vez más tienen una alta probabilidad de adivinar con éxito el ID de la transacción.

El canal lateral en este caso es el límite de velocidad para ICMP, abreviatura del Protocolo de Mensajes de Control de Internet. Para conservar el ancho de banda y los recursos informáticos, los servidores responderán solo a un número determinado de solicitudes de otros servidores. Después de eso, los servidores no proporcionarán ninguna respuesta. Hasta hace poco, Linux siempre establecía este límite en 1.000 por segundo.

Para explotar este canal lateral, la nueva técnica de suplantación de identidad inunda un solucionador de DNS con una gran cantidad de respuestas que son falsificadas, por lo que parecen provenir del servidor de nombres del dominio que quieren suplantar. Cada respuesta se envía a través de un puerto diferente.

Cuando un atacante envía una respuesta a través del puerto incorrecto, el servidor enviará una respuesta de que el puerto es inalcanzable, lo que agota el límite de velocidad global en uno. Cuando el atacante envía una solicitud a través del puerto correcto, el servidor no dará ninguna respuesta, lo que no cambia el contador de límite de velocidad. Si el atacante sondea 1.000 puertos diferentes con respuestas falsas en un segundo y todos se cierran, el límite de velocidad completo se agotará por completo. Si, por otro lado, uno de los 1.000 puertos está abierto, entonces el límite se reducirá a 999.

Posteriormente, el atacante puede usar su propia dirección IP no falsificada para medir el límite de velocidad restante. Y si el servidor responde con un mensaje ICMP, el atacante sabe que uno de los 1.000 puertos previamente analizados debe estar abierto y puede reducir aún más el número de puerto exacto.

"¿Como lo sabemos?"

"Estamos tratando de inferir indirectamente que el resolutor ha enviado un mensaje ICMP inalcanzable al servidor autorizado", dijo el profesor de la UC Riverside, Zhiyun Qian. "¿Como lo sabemos? Debido a que el resolutor puede enviar solo un número fijo de mensajes ICMP en un segundo, lo que significa que el atacante también puede intentar solicitar esos paquetes ICMP a sí mismo".

El artículo de los investigadores, DNS Cache Poisoning Attack Reloaded: Revolutions with Side Channels, proporciona una descripción técnica y mucho más detallada del ataque. Llaman al ataque SAD DNS, abreviatura de Side channel AttackeD DNS.

Los investigadores proporcionaron en privado sus hallazgos a proveedores de DNS y desarrolladores de software. En respuesta, los desarrolladores del kernel de Linux introdujeron un cambio que provoca que el límite de velocidad fluctúe aleatoriamente entre 500 y 2.000 por segundo. El profesor Qian dijo que la solución impide que funcione la nueva técnica. Cloudflare introdujo una solución propia. En ciertos casos, su servicio DNS recurrirá a TCP, que es mucho más difícil de falsificar.

La investigación se presentó en la Conferencia ACM 2020 sobre seguridad informática y de las comunicaciones, que se realizó este año por vídeo debido a la pandemia de COVID-19. Los investigadores brindan información adicional aquí, y un comunicado de prensa de la UC Riverside se puede leer aquí.


Comentarios (0)

No hay comentarios escritos aquí

Deja tus comentarios

  1. Publicar comentario como invitado. Regístrate o ingresaa tu cuenta
Archivos adjuntos (0 / 3)
Compartir su ubicación
close

Subscríbete a las últimas noticias, es gratis.