La suplantación de DNS , también conocida como envenenamiento de la caché de DNS , es una forma de piratería de seguridad informática en la que se introducen datos corruptos del sistema de nombres de dominio en la caché del solucionador de DNS , lo que hace que el servidor de nombres devuelva un registro de resultado incorrecto, por ejemplo, una dirección IP. . Esto da como resultado que el tráfico se desvíe a cualquier computadora que elija el atacante.
Un servidor del Sistema de nombres de dominio traduce un nombre de dominio legible por humanos (como example.com) en una dirección IP numérica que se utiliza para enrutar las comunicaciones entre nodos . [1] Normalmente, si el servidor no conoce una traducción solicitada, la preguntará a otro servidor y el proceso continúa de forma recursiva . Para aumentar el rendimiento, un servidor normalmente recordará (guardará en caché) estas traducciones durante un cierto período de tiempo. Esto significa que si recibe otra solicitud para la misma traducción, puede responder sin necesidad de preguntar a ningún otro servidor, hasta que caduque ese caché.
Cuando un servidor DNS recibe una traducción falsa y la almacena en caché para optimizar el rendimiento, se considera envenenado y proporciona datos falsos a los clientes. Si un servidor DNS está envenenado, puede devolver una dirección IP incorrecta, desviando el tráfico a otra computadora (a menudo la de un atacante). [2]
Normalmente, una computadora en red utiliza un servidor DNS proporcionado por un proveedor de servicios de Internet (ISP) o la organización del usuario de la computadora. Los servidores DNS se utilizan en la red de una organización para mejorar el rendimiento de la respuesta de resolución almacenando en caché los resultados de las consultas obtenidas previamente. Los ataques de envenenamiento en un único servidor DNS pueden afectar a los usuarios atendidos directamente por el servidor comprometido o a aquellos atendidos indirectamente por sus servidores descendentes, si corresponde. [3]
Para realizar un ataque de envenenamiento de caché , el atacante aprovecha fallas en el software DNS. Un servidor debe validar correctamente las respuestas DNS para garantizar que provienen de una fuente autorizada (por ejemplo, mediante el uso de DNSSEC ); de lo contrario, el servidor podría terminar almacenando en caché las entradas incorrectas localmente y entregárselas a otros usuarios que realicen la misma solicitud.
Este ataque se puede utilizar para redirigir a los usuarios de un sitio web a otro sitio que elija el atacante. Por ejemplo, un atacante falsifica las entradas DNS de la dirección IP de un sitio web de destino en un servidor DNS determinado y las reemplaza con la dirección IP de un servidor bajo su control. Luego, el atacante crea archivos en el servidor bajo su control con nombres que coinciden con los del servidor de destino. Estos archivos suelen contener contenido malicioso , como gusanos o virus informáticos . Un usuario cuya computadora ha hecho referencia al servidor DNS envenenado es engañado para que acepte contenido proveniente de un servidor no auténtico y, sin saberlo, descarga el contenido malicioso. Esta técnica también se puede utilizar para ataques de phishing , en los que se crea una versión falsa de un sitio web genuino para recopilar datos personales, como datos bancarios y de tarjetas de crédito/débito.
La vulnerabilidad de los sistemas al envenenamiento de la caché de DNS va más allá de sus efectos inmediatos, ya que puede exponer a los usuarios a riesgos adicionales como phishing , inyecciones de malware , denegación de servicio y secuestro de sitios web debido a vulnerabilidades del sistema. Varios métodos, que van desde el uso de tácticas de ingeniería social hasta la explotación de debilidades presentes en el software del servidor DNS, pueden conducir a estos ataques. [4]
En las siguientes variantes, las entradas para el servidorns.target .ejemplosería envenenado y redirigido al servidor de nombres del atacante en la dirección IP wxyz . Estos ataques suponen que el servidor de nombres paraobjetivo.ejemploesns.target.ejemplo.
Para llevar a cabo los ataques, el atacante debe obligar al servidor DNS objetivo a realizar una solicitud de un dominio controlado por uno de los servidores de nombres del atacante. [ cita necesaria ]
La primera variante del envenenamiento de la caché DNS implica redirigir el servidor de nombres del dominio del atacante al servidor de nombres del dominio de destino y luego asignar a ese servidor de nombres una dirección IP especificada por el atacante.
Solicitud del servidor DNS: ¿para qué sirven los registros de direcciones?subdominio.atacante.ejemplo?
subdominio.atacante.ejemplo. EN UN La respuesta del atacante:
(ninguna respuesta)
atacante.ejemplo. 3600 IN NS ns.objetivo.ejemplo. ns.target.ejemplo. EN UN w.xyz Un servidor vulnerable almacenaría en caché el registro A adicional (dirección IP) parans.target.ejemplo, permitiendo al atacante resolver consultas a todo elobjetivo.ejemplodominio.
La segunda variante del envenenamiento de la caché de DNS implica redirigir el servidor de nombres de otro dominio no relacionado con la solicitud original a una dirección IP especificada por el atacante. [ cita necesaria ]
Solicitud del servidor DNS: ¿para qué sirven los registros de direcciones?subdominio.atacante.ejemplo?
subdominio.atacante.ejemplo. EN UN La respuesta del atacante:
(ninguna respuesta)
objetivo.ejemplo. 3600 IN NS ns.atacante.ejemplo. ns.attacker.ejemplo. EN UN w.xyz Un servidor vulnerable almacenaría en caché la información de autoridad no relacionada paraobjetivo.ejemploel registro NS (entrada del servidor de nombres), lo que permite al atacante resolver consultas a todo elobjetivo.ejemplodominio.
Muchos ataques de envenenamiento de caché contra servidores DNS se pueden prevenir confiando menos en la información que les pasan otros servidores DNS e ignorando cualquier registro DNS devuelto que no sea directamente relevante para la consulta. Por ejemplo, las versiones de BIND 9.5.0-P1 [5] y superiores realizan estas comprobaciones. [6] La aleatorización del puerto de origen para las solicitudes de DNS, combinada con el uso de números aleatorios criptográficamente seguros para seleccionar tanto el puerto de origen como el nonce criptográfico de 16 bits , puede reducir en gran medida la probabilidad de ataques exitosos de carrera de DNS. [ cita necesaria ]
Sin embargo, cuando los enrutadores, firewalls , servidores proxy y otros dispositivos de puerta de enlace realizan la traducción de direcciones de red (NAT), o más específicamente, la traducción de direcciones de puertos (PAT), pueden reescribir los puertos de origen para rastrear el estado de la conexión. Al modificar los puertos de origen, los dispositivos PAT pueden eliminar la aleatoriedad del puerto de origen implementada por los servidores de nombres y los resolutores de código auxiliar. [ cita necesaria ] [7]
El DNS seguro ( DNSSEC ) utiliza firmas digitales criptográficas firmadas con un certificado de clave pública confiable para determinar la autenticidad de los datos. DNSSEC puede contrarrestar los ataques de envenenamiento de caché. En 2010, DNSSEC se implementó en los servidores de la zona raíz de Internet, [8] pero también debe implementarse en todos los servidores de dominio de nivel superior . La preparación DNSSEC de estos se muestra en la lista de dominios de nivel superior de Internet . A partir de 2020, todos los TLD originales admiten DNSSEC, al igual que los TLD de código de país de la mayoría de los países grandes, pero muchos TLD de código de país todavía no lo hacen.
Este tipo de ataque se puede mitigar en la capa de transporte o en la capa de aplicación realizando una validación de un extremo a otro una vez que se establece una conexión. Un ejemplo común de esto es el uso de Transport Layer Security y firmas digitales . Por ejemplo, al utilizar HTTPS (la versión segura de HTTP ), los usuarios pueden comprobar si el certificado digital del servidor es válido y pertenece al propietario esperado de un sitio web. De manera similar, el programa de inicio de sesión remoto de shell seguro verifica los certificados digitales en los puntos finales (si se conocen) antes de continuar con la sesión. Para las aplicaciones que descargan actualizaciones automáticamente, la aplicación puede incrustar una copia del certificado de firma localmente y validar la firma almacenada en la actualización de software con el certificado integrado. [9]