¿Qué es el envenenamiento de caché DNS (DNS spoofing)?
El envenenamiento de caché DNS es el ataque que hace que un servidor de nombres guarde y distribuya una respuesta falsa, de modo que quien escribe la dirección correcta termina en el servidor del delincuente. No hay ningún enlace sospechoso en el que hacer clic ni error al escribir: el nombre está bien, lo que estuvo mal fue la respuesta. Es el ataque que la firma de DNS, el DNSSEC, existe para volver detectable, y la razón por la que confiar en el DNS no es un detalle técnico.
Cómo se envenena una caché de DNS
Antes de cualquier conexión, el dispositivo le pregunta a un servidor resolutor cuál es el número de un nombre. Ese resolutor guarda la respuesta un tiempo para no volver a preguntar. El ataque apunta exactamente a esa copia guardada.
El atacante provoca la pregunta
Fuerza al resolutor a consultar un nombre de su interés, por ejemplo pidiendo un subdominio que todavía no está en la caché. Así controla el momento exacto en que se abre la ventana y ya no necesita esperar a que expire la caché: la propia especificación calcula que, con esa técnica y un único puerto de origen, la probabilidad de acierto llega al 50% en 7 segundos.
Dispara respuestas falsas en ráfaga
Mientras la respuesta legítima viaja, envía muchas respuestas forjadas, cada una adivinando el identificador de la consulta. Basta con que una acierte antes de que llegue la verdadera.
La respuesta falsa es aceptada y guardada
El resolutor no tenía cómo distinguir: la respuesta parecía venir del lugar correcto y llegó primero. Se la entrega a quien preguntó y la guarda durante el plazo que pidió la respuesta falsa, hasta el techo que impone el propio resolutor.
Todos los que están detrás de ese resolutor quedan afectados
A partir de ahí no es una víctima, son todas: cada persona y cada sistema que use ese resolutor recibe la dirección equivocada, sin nada anormal en pantalla.
Fuente: RFC 5452, la especificación del IETF sobre medidas para hacer al DNS resistente a respuestas forjadas, que describe el ataque, mide su viabilidad y define las contramedidas exigidas a los resolutores.
Por qué el DNS aceptó esto durante décadas
- La respuesta se verificaba contra un número de 16 bits. Era todo el secreto compartido entre pregunta y respuesta, y la propia especificación hace la cuenta: con ese campo bien aleatorizado, bastan unos 32 mil intentos en promedio para acertarlo.
- Quien llega primero gana. El resolutor acepta la primera respuesta que parezca válida y descarta las siguientes. El atacante no necesita impedir la respuesta verdadera, solo correr más rápido.
- El plazo de validez viene en la propia respuesta. La respuesta falsa lleva el tiempo que pide para quedarse en caché, y eso es lo que decide cuánto dura el envenenamiento. El límite no es del atacante ni de la víctima: es el techo que impone cada resolutor, y en las configuraciones más comunes ese techo es de 24 horas.
- La víctima no tiene síntoma. La dirección en la barra está bien, el nombre está bien, y nada avisa que la traducción fue adulterada. Por eso este ataque no aparece en la capacitación de concientización: no hay nada que la persona pueda notar.
Las formas de entregar la respuesta equivocada
- Envenenamiento de la caché La forma clásica y la más valiosa para el atacante, porque contamina de una vez a todos los que usan ese resolutor. Es la que mide el RFC 5452 y la que el DNSSEC vuelve detectable.
- Respuesta forjada en la red local En una red abierta o comprometida, el atacante responde a la consulta antes que el servidor legítimo, sin necesidad de envenenar caché alguna. Alcanza a quien está en esa red, uno por vez.
- Resolutor alterado en el dispositivo En lugar de engañar al resolutor, el ataque cambia qué resolutor usa el aparato, apuntándolo a un servidor del delincuente. Aquí el problema ya está dentro del equipo.
- Secuestro del registro en el registrador No es falsificación, es toma de control: con acceso a la cuenta del dominio, el delincuente cambia el registro en el origen. La respuesta pasa a ser oficialmente equivocada, y el DNSSEC no lo impide, porque quien controla esa cuenta controla también el eslabón que ancla la firma en el dominio de arriba: basta con quitarlo, o cambiarlo por el suyo, para que el dominio deje de estar firmado.
Qué cambia cuando la traducción no es confiable
El DNS es la capa que nadie ve y de la que todo depende. Una dirección envenenada no afecta solo el acceso a un sitio: afecta a la aplicación que llama a una interfaz, al servidor que busca una actualización, al sistema que se conecta a la base de datos y, lo que más importa aquí, al servidor que busca adónde entregar el correo de su dominio. Por eso este ataque está por debajo de toda una familia de defensas: el registro que dice qué servidores pueden enviar en su nombre, la clave que verifica la firma de sus mensajes, la política que exige canal cifrado, todas ellas son respuestas de DNS. Si la traducción puede adulterarse, cada una de esas defensas responde exactamente lo que el atacante quiera que responda. La corrección de 2008, que hizo que los resolutores aleatorizaran también el puerto de origen, encareció el ataque en órdenes de magnitud, pero encarecer no es impedir: sigue siendo una carrera que gana el más rápido, y no una verificación de quién está hablando: la propia especificación calcula que, incluso con los 64 mil puertos recomendados, el nivel de 50% se alcanza en unas 116 horas. Queda además la consecuencia que suele pasar inadvertida en la dirección: buena parte de los certificados digitales se emite contra una prueba publicada en el DNS. Quien controla la respuesta puede obtener un certificado válido para su nombre y mostrar el candado en el sitio falso, y puede desviar adónde su dominio recibe el correo, que es como un pedido de cambio de cuenta bancaria le llega convincente a su cliente.
Cómo reducir la exposición al envenenamiento
La defensa se divide entre lo que usted hace como quien consulta y lo que hace como dueño de un dominio:
- Use resolutores que validan la firmaUn resolutor que verifica el DNSSEC rechaza la respuesta adulterada en lugar de retransmitirla. Es la única defensa que ataca la causa, y no el costo del ataque.
- Firme su propio dominioFirmar permite que quien consulta su nombre detecte la adulteración, incluidos los servidores que entregan su correo. Es la mitad del problema que está a su alcance resolver por su cuenta.
- Trate la cuenta del registrador como cuenta críticaEl secuestro en el origen no es falsificación: quien tiene la cuenta puede apagar la propia firma. La verificación de dos factores, el bloqueo de transferencia y la revisión de quién tiene acceso valen más aquí que cualquier otra medida.
- Mantenga actualizados los resolutores internosLas contramedidas de la especificación, como la aleatorización del puerto de origen, solo valen si el software está en una versión que las implemente. Un resolutor viejo en la red interna es la puerta a la que la corrección de 2008 nunca llegó.
- Registre las consultas de DNSEl historial de consultas es lo que permite reconstruir un incidente y notar patrones extraños. Es la misma materia prima que usa el filtrado de DNS para bloquear dominios maliciosos.
En la práctica
Es como adulterar la guía telefónica en lugar de entrar en la casa: usted busca el nombre correcto, marca el número que la guía devolvió, y atiende otra persona. Nada de su lado parece mal, porque nada de su lado está mal. Por eso este ataque no se resuelve con atención del usuario, sino con una respuesta de DNS que se pueda verificar.
Cómo Zamak trata la confianza en el DNS
Zamak Technologies trata el DNS como capa de confianza, y no como directorio: resolutores que validan la firma, dominio del cliente firmado, cuenta de registrador con acceso controlado e historial de consultas guardado para investigación, junto a quien ya responde por la red del cliente. Toda la autenticación de correo reposa en esa capa, porque SPF, DKIM y DMARC son todas respuestas de DNS. El DNSSEC explica cómo funciona esa verificación, y el filtrado de DNS atiende el otro lado del problema, el dominio que es malicioso desde el origen. Esto forma parte de la Ciberseguridad gestionada del Método Zamak.