Los ataques de envenenamiento de la caché de DNS regresan debido a la debilidad de Linux

Investigadores de la Universidad de Tsinghua y la Universidad de California han identificado un nuevo método que se puede utilizar para realizar ataques de envenenamiento de caché de DNS.

El nuevo descubrimiento revive un error de 2008 que alguna vez se pensó que se había solucionado para siempre.

¿Qué es la suplantación de DNS o el envenenamiento de caché?

El sistema de nombres de dominio (DNS) se puede entender mejor como una libreta de direcciones para Internet.

Como cuando quieres llamar a tu amigo Alex, debe buscar su número de teléfono a través de un sistema llamado libreta de direcciones.

De manera similar, cuando inicia sesión en un dominio, su navegador web intenta identificar su dirección IP buscándola a través de un sistema de directorio de Internet llamado DNS.

El proceso real ocurre en una serie de pasos y no siempre es tan simple.

Por ejemplo, si usted o alguien de su red ha visitado antes bleepingcomputer.com, nuestra dirección IP se almacenará en caché en algún lugar de su computadora o en servidores intermedios.

Esto significa que la próxima vez que visite bleepingcomputer.com, no se requerirá otra búsqueda de DNS. Su computadora o navegador web ya sabría dónde encontrarnos.

Los ataques de envenenamiento de caché de DNS se refieren a la contaminación de esta misma caché existente en servidores intermedios.

Imagínese si un caché de DNS en el que su computadora (el cliente) hubiera confiado para la búsqueda bleepingcomputer.com¿La IP le dio una dirección IP incorrecta en lugar de la nuestra?

Los atacantes podrían causar estragos en Internet si pudieran envenenar los cachés de DNS.

Tal error fue descubierto por el investigador de seguridad Dan Kaminsky en 2008.

Cuando un dispositivo busca la dirección IP de un nombre de dominio usando DNS, incluye un número de "ID de transacción" único en la solicitud al servidor DNS.

Cuando el servidor responde al dispositivo con una respuesta (p. Ej. bleepingcomputer.com se puede encontrar en 104.20.60.209), el dispositivo acepta solo la respuesta es válida si también incluye el ID de transacción original.

La razón es simple: evitar que un servidor DNS no autorizado inunde su dispositivo con entradas de DNS maliciosas e inválidas.

Si no se realizaran estas comprobaciones, un servidor DNS no autorizado podría proporcionar fácilmente al usuario una dirección IP falsificada y, al conectarse a un sitio web, el usuario sería redirigido al servidor del atacante en lugar del legítimo, gracias. Respuesta de DNS falsa.

Sin embargo, Kaminsky descubrió que solo había 65.536 posibles ID de transacciones.

Un atacante podría enviar múltiples respuestas DNS falsas con ID de 0 a 65,535 y simultáneamente para prevenir la primera respuesta de obtener el caché.

Para evitar el almacenamiento en caché de la primera respuesta de DNS, el atacante envió respuestas con ligeras variaciones de un dominio, como que cada respuesta contiene un subdominio diferente: 1.bleepingcomputer.com, 2.bleepingcomputer.com, y así.

Eventualmente, el atacante podría adivinar el ID de transacción correcto de una solicitud de DNS y, al mismo tiempo, proporcionar su IP de servidor malicioso a través de la respuesta de DNS.

La próxima vez, el usuario va a bleepingcomputer.com, el dominio se resolvería con el servidor del atacante si ese ataque tuviera éxito.

¿Cómo volvió el envenenamiento de la caché de DNS?

Se ha implementado la aleatorización del puerto de origen para evitar ataques de envenenamiento de caché de DNS.

Esto significa que, incluso como atacante, incluso si eventualmente pudiera adivinar uno de los 65.536 ID de transacción especificados por su dispositivo en una solicitud de DNS, no lo sabría. Dónde está para enviar la respuesta de DNS, porque ahora su dispositivo que realiza una búsqueda de DNS lo hace desde un puerto aleatorio (que en teoría también tiene 65.536 valores) en lugar del puerto 53.

Esta solución había hecho prácticamente imposible realizar ataques de envenenamiento de caché de DNS a través del método descubierto por Kaminsky, dadas las miles de millones de posibilidades.

Pero investigadores de la Universidad de Tsinghua y la Universidad de California publicado un método que aprovecha un ataque de canal lateral para inferir el número de puerto de origen del cliente DNS.

Con el puerto de origen fuera de la bolsa, es posible una vez más realizar los ataques de envenenamiento del caché DNS de Kaminsky adivinando los ID de transacción como se describe anteriormente.

Adivinar el puerto de origen es posible debido a cómo se maneja el kernel de Linux ICMP solicitudes (piensa silbido o tracert).

Para ahorrar ancho de banda, el limitador de velocidad integrado de Linux establece el número de solicitudes entrantes en 1,000 por segundo y usa un contador para rastrear estas solicitudes.

Por cada solicitud recibida en un puerto cerrado en un servidor basado en Linux, el contador disminuirá en 1 es el servidor respondería con "inalcanzable".

Significa que, en un segundo, si envías 1,000 paquetes a diferentes puertos aleatorios en un servidor, todos ellos cerrados, el servidor te interrumpirá por ese segundo.

Pero eso también le diría que todas sus 1,000 suposiciones de que la puerta podría estar abierta eran incorrectas.

Curiosamente, el contador no disminuye por cada solicitud recibida en un puerto válido y abierto. Y, además, "inalcanzable" obviamente no sería enviado por el servidor.

Esto significa, cada segundo, un atacante podría inundar un resolutor de DNS con 1000 paquetes falsificados destinados a puertos aleatorios.

De esta manera, en segundos, el atacante podrá deducir qué puertos están abiertos en el resolutor de DNS que está intentando envenenar.

Con el conocimiento del puerto correcto, pueden reutilizar el error de Kaminsky para causar ataques de envenenamiento de DNS.

Entonces, ¿hay una solución para esto?

Así como la aleatorización del puerto de origen había agregado cierta complejidad para los atacantes, el kernel de Linux aleatorizando el valor máximo del limitador de velocidad en lugar de usar siempre 1,000 podría resultar útil.

Una solución de este tipo volvería a dificultar que un atacante deduzca el puerto correcto para atacar los ataques de suplantación de DNS.

David Maxwell, director de seguridad de software en Gato azul ofreció una sugerencia:

"El cambio introducido por Linux para aleatorizar automáticamente el valor de límite de velocidad se incluyó en el kernel de Linux el 16 de octubre, lo que significa que la mayoría de los sistemas tardarán un tiempo en ejecutarlo. Aún no está en la versión. utilice un pequeño script de shell para variar constantemente el límite de frecuencia ICMP. No tan limpio como estaba integrado en el kernel, pero es una posible solución ". Entonces, estamos trabajando en hacer un guión de muestra como el que está disponible para la comunidad en este momento. "

los ajustar hecho para el kernel de Linux icmp.c file ahora asigna un valor aleatorio al contador (llamado "crédito"), pero los servidores Linux de todo el mundo pueden tardar algún tiempo en ponerse al día, como explica Maxwell.

Maxwell no recomienda bloquear completamente el tráfico ICMP ya que el protocolo tiene casos de uso legítimos.

"Si un servidor DNS tiene ICMP completamente bloqueado, las transferencias de zona pueden fallar, si hay un salto con un MTU más pequeño (el bloqueo de ICMP causa un agujero negro de PMTUD) entre él y el otro servidor", dijo. Maxwell le dijo a BleepingComputer.

El descubrimiento de este ataque de canal lateral ejerce más presión sobre los ingenieros de Internet para aumentar la seguridad del DNS.

DNS ya es un protocolo relativamente inseguro diseñado para favorecer la velocidad sobre el rendimiento y la seguridad.

La creación de mejoras como DNS sobre HTTPS (DoH) tampoco impidió que los atacantes abusaran del DNS para sus actividades maliciosas.