Envenenamiento de la caché de DNS
El envenenamiento de la caché de DNS es el ataque en el que se almacenan datos incorrectos en la caché de un solucionador, lo que provoca que consultas legítimas devuelvan respuestas incorrectas mientras dure la caché. El ataque Kaminsky de 2008 casi rompió el DNS global; Las soluciones implementadas desde entonces son duraderas pero no completas. La categoría sigue siendo relevante.
El cuerpo completo del artículo se proporciona en inglés a continuación.
Envenenamiento de la caché de DNS (a veces llamado suplantación de DNS) es el ataque en el que un atacante inyecta datos de DNS falsificados en la caché de un solucionador. Las consultas posteriores del registro envenenado devuelven una respuesta incorrecta hasta que caduque el caché. Debido a que los solucionadores almacenan en caché de manera agresiva para mejorar el rendimiento, un envenenamiento exitoso puede afectar a muchos usuarios durante horas.
Cómo funciona normalmente la resolución DNS
Sin pasar por todo el flujo (consulte nuestro artículo sobre el servidor DNS ), el punto clave: un solucionador realiza una consulta a un servidor de nombres ascendente y acepta la respuesta. DNS solía usar UDP exclusivamente para esto: sin protocolo de enlace, sin autenticación, simplemente "enviar consulta, aceptar la primera respuesta coincidente".
Si un atacante puede enviar una respuesta falsificada antes de que llegue la legítima, el solucionador almacena en caché la respuesta falsificada. Para todas las consultas durante la vida útil de la caché (normalmente de minutos a horas), el solucionador devuelve los datos envenenados.
El ataque de Kaminsky
En 2008, Dan Kaminsky publicó una extensión devastadora del envenenamiento de la caché de DNS clásico. El ataque original se basó en adivinar un ID de transacción de 16 bits: 1 entre 65.536 probabilidades, lo cual no es muy bueno. El giro de Kaminsky: el atacante no tiene que esperar a consultas legítimas. Pueden trigger preguntarles al solucionador sobre un subnombre que controlan y luego competir con respuestas falsificadas para los registros de autoridad del dominio principal. Con optimizaciones menores, la explotación se volvió práctica.
La divulgación desencadenó un esfuerzo de parche coordinado en todas las principales implementaciones de DNS en 2008. La solución: aleatorizar el puerto de origen que utiliza el solucionador. Combinado con el ID de la transacción, esto expande la entropía a ~32 bits, lo que reduce drásticamente la posibilidad de una falsificación exitosa.
Cómo se ven las defensas modernas
- Aleatorización del puerto de origen. Estándar desde 2008. Aumenta la entropía lo suficiente como para que el envenenamiento de la caché mediante adivinanzas se convierta en infactible.
- DNS sobre HTTPS (DoH) y DNS sobre TLS (DoT). El transporte criptográfico elimina por completo el ataque de inyección en ruta. El solucionador y la autoridad tienen un canal cifrado.
- DNSSEC. Las firmas criptográficas en los registros DNS detectan manipulación. Las respuestas falsificadas no superan la verificación de firma. Consulte nuestro artículo DNSSEC.
- Filtrado de IP de origen. Las redes que eliminan paquetes de direcciones de origen falsificadas (BCP38/validación de dirección de origen) dificultan el ataque al limitar dónde se pueden originar las respuestas falsificadas.
- Endurecimiento del solucionador. La codificación 0x20 (aleatorización de mayúsculas y minúsculas en los nombres de las consultas) agrega bits de entropía. Las cookies EDNS0 proporcionan anti-spoofing adicional.
El ataque DNS SAD de 2020
En 2020, los investigadores publicaron una nueva clase de ataque llamada SAD DNS que omitió la aleatorización de puertos en escenarios específicos utilizando información de canal lateral sobre la pila de red del solucionador. El ataque funciona contra los principales solucionadores, incluidos algunos valores predeterminados de Linux. Linux 5.10+ tiene mitigaciones; Los sistemas más antiguos siguen siendo vulnerables.
La categoría de "envenenamiento de DNS resuelto" nunca llega. Las defensas mejoran; Aparecen nuevos canales laterales. Las mejores prácticas modernas combinan múltiples capas.
Qué significa esto para los usuarios finales
Para usuarios cotidianos:
- Utilice un solucionador público importante (1.1.1.1, 8.8.8.8, 9.9.9.9): están reforzados contra los ataques conocidos y validan DNSSEC.
- Utilice DoH o DoT: cifra la búsqueda y derrota a la mayoría de los atacantes en el camino.
- HTTPS en sí mismo es un recurso alternativo: incluso si DNS miente y lo envía a la IP de un atacante, el certificado TLS no coincidirá y el navegador le advertirá. es un secuestro de resolución a nivel de enrutador o ISP. Configurar su dispositivo para usar un solucionador bueno conocido (con transporte cifrado) cierra ese agujero.
Qué significa esto para los operadores
Para operadores de DNS:
- Habilite DNSSEC en sus servidores autorizados.
- Utilice un solucionador que valide DNSSEC.
- Patch rápidamente. Las correcciones de 2008, las mitigaciones de DNS de SAD y cualquier aviso futuro.
- Implemente la validación de la dirección de origen si opera una red.
La infraestructura DNS es más segura que hace una década; las amenazas han evolucionado en paralelo.
Preguntas frecuentes
- ¿Puedo verme afectado por el envenenamiento de caché?
- Indirectamente. Los usuarios finales no suelen operar los cachés que se envenenan. Si su solucionador de DNS está comprometido, verá respuestas incorrectas para lo que fue envenenado. El uso de solucionadores reforzados importantes (1.1.1.1, 8.8.8.8) reduce sustancialmente el riesgo.
- ¿Cómo previene esto DNSSEC?
- Los registros firmados por el dominio autorizado se pueden verificar criptográficamente. Una respuesta falsificada no pasa la verificación y se rechaza. DNSSEC existe desde 1997 pero la adopción es desigual; Los resolutores principales validan, los más pequeños a menudo no lo hacen.
- ¿DNS sobre HTTPS es lo mismo que DNSSEC?
- No. DNSSEC agrega firmas a los registros, verificando la autenticidad. DoH cifra el transporte entre el cliente y el solucionador, evitando escuchas o alteraciones en la ruta. Son complementarios; puedes tener uno o ambos.
- ¿Cuál es la diferencia entre el envenenamiento de la caché y el secuestro de DNS?
- El envenenamiento de la caché inyecta datos incorrectos en la caché de un solucionador mediante un ataque a nivel de red. El secuestro de DNS cubre en términos generales el cambio del solucionador en sí (compromiso del enrutador, aplicación maliciosa, apropiación de la cuenta del registrador). El envenenamiento de caché es una técnica específica dentro de la categoría más amplia de secuestro.
- ¿Existen incidentes famosos de envenenamiento de cachés?
- El envenenamiento masivo al estilo Kaminsky nunca se materializó porque los parches se desplegaron lo suficientemente rápido. Se han producido envenenamientos específicos más pequeños: un incidente de 2019 que afectó partes de la infraestructura DNS china redirigió brevemente los principales servicios estadounidenses para los usuarios en China. La mayoría de los ataques DNS a gran escala desde 2008 han implicado secuestros de BGP o compromisos de registradores en lugar del clásico envenenamiento de caché.