La fijación de DNS no protege contra los ataques sofisticados de reconexión de DNS .
Considere un escenario en el que un atacante configura un firewall frente a su servidor web. Solicita su sitio web, attacker.com, que da como resultado que una consulta de DNS devuelva su dirección IP. El resultado del DNS tiene un TTL (tiempo de vida) de 1 segundo. Normalmente, esto significa que el navegador debe realizar otra solicitud de DNS después de que haya transcurrido 1 segundo, sin embargo, la fijación de DNS le indica al navegador que ignore el TTL y le agregue alguna unidad de tiempo (por ejemplo, una hora). Así que ahora, su navegador no realizará otra consulta de DNS para ese nombre de host durante 1 hora, 1 segundo. Una vez que se completa la consulta de DNS, se envía su solicitud HTTP y el atacante le devuelve el sitio web que solicitó con el código javascript que iniciará el ataque.
Ahora, el Javascript del atacante ha configurado una solicitud AJAX que espera dos segundos antes de disparar. Luego, vuelve a solicitar automáticamente algún recurso en el sitio web del atacante. Sin embargo, la solicitud falla. Esto se debe a que el atacante ya ha configurado una regla de firewall que bloquea la solicitud de su navegador . Ahora estamos en el siguiente estado:
- El TTL ha caducado en su primera solicitud de DNS, pero la asignación de DNS todavía está vigente
- Hiciste una solicitud al sitio web del atacante a través de su llamada JS AJAX
- El firewall del atacante eliminó la solicitud
Estas tres cosas harán que su navegador web envíe otra consulta de DNS a pesar del hecho de que está usando la asignación de DNS. En efecto, el atacante ha derrotado fácilmente su estrategia de fijación de DNS mediante el uso de un firewall y Enviando una segunda solicitud fuera del TTL. La fijación de DNS no es una estrategia efectiva porque hay muchas razones legítimas por las que el servidor de alguien podría estar inactivo; su navegador se ve obligado a realizar una segunda consulta de DNS en caso de que haya otro registro de DNS que se resuelva en la máquina correcta (por ejemplo, en el caso de una migración de servidor, tiempo de inactividad, lo que sea). Básicamente, su navegador no tiene forma de saber si está siendo atacado aquí o no; por lo que sabe, el servidor está inactivo legítimamente y, por lo tanto, DEBE realizar otra solicitud de DNS.
Entonces ... ¿por qué importa que haya una segunda solicitud de DNS?
El atacante suele utilizar la segunda solicitud de DNS para devolver una dirección IP incorrecta para el registro de DNS. Los navegadores tienen lo que se denomina una política de "mismo origen" que evita que las páginas web realicen solicitudes de recursos que no son de su propiedad. Básicamente, la forma en que funciona el mismo origen es que dice que enlace solo puede solicitar enlace . Pero en realidad funciona usando la dirección IP para hostname.com, no el nombre de host legible por humanos. Entonces, en un ataque de reencuadernación de DNS, cuando su navegador realiza la segunda consulta de DNS que describí anteriormente, el atacante devolverá una dirección IP "falsa" en el resultado de la consulta de DNS. Entonces, su navegador pensará, por ejemplo, que la dirección IP 1.1.1.1 pertenece a attacker.com aunque en realidad pertenece a google.com. Esto permite al atacante explotar la misma política de origen del navegador; ahora el javascript del atacante puede solicitar cosas de google.com a través de AJAX. Además, pueden leer y configurar cookies y otras cosas maliciosas. Esto explota la misma política de origen engañando al navegador para que confíe en el segundo registro DNS que se devolvió. Ahora el navegador cree que hostname.com está asociado con la dirección IP 1.1.1.1, aunque en realidad no lo está. ¿Qué es un navegador para hacer? DNS no tiene ese tipo de autenticación incorporada. :(
Evitar el ataque de reencuadernación de DNS
Hay muchas maneras de prevenirlo, y estoy bastante seguro de que los navegadores modernos ya han implementado protección contra estos ataques. Una forma fácil de evitarlo (como propietario de un sitio web) es verificar el encabezado de host HTTP de una solicitud. Por ejemplo, si usted es google.com, entonces recibirá una solicitud pero el encabezado del host aún dirá attacker.com. Obviamente, eso no forma parte de su dominio, por lo que puede evitar el ataque simplemente eliminando la solicitud. ¿Por qué alguien querría hacer esto para empezar? Bueno, haga clic en el fraude en la publicidad. Raspando los motores de búsqueda de muchas máquinas a la vez. Robar datos valiosos de sitios web en la red interna de su empresa. Etc.