La suplantación de DNS , también conocida como envenenamiento de caché de DNS , es una forma de piratería informática en la que se introducen datos corruptos del sistema de nombres de dominio en la caché del servidor de resolución de DNS , lo que hace que el servidor de nombres devuelva un registro de resultado incorrecto, por ejemplo, una dirección IP . Esto hace que el tráfico se desvíe a cualquier computadora que elija el atacante.
Un servidor de 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, se la preguntará a otro servidor y el proceso continúa de forma recursiva . Para aumentar el rendimiento, un servidor normalmente recordará (almacenará 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 esa caché.
Cuando un servidor DNS recibe una traducción falsa y la almacena en caché para optimizar el rendimiento, se considera que está envenenado y proporciona los datos falsos a los clientes. Si un servidor DNS está envenenado, puede devolver una dirección IP incorrecta, lo que desvía el tráfico a otro equipo (a menudo, el 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 mediante el almacenamiento en caché de los resultados de consultas obtenidos previamente. Los ataques de envenenamiento en un solo servidor DNS pueden afectar a los usuarios atendidos directamente por el servidor comprometido o a aquellos atendidos indirectamente por sus servidores posteriores, si corresponde. [3]
Para llevar a cabo un ataque de envenenamiento de caché , el atacante aprovecha las fallas en el software DNS. Un servidor debe validar correctamente las respuestas DNS para asegurarse de que provienen de una fuente autorizada (por ejemplo, mediante 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 elegido por 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. A continuación, 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 informáticos o virus . Un usuario cuya computadora ha hecho referencia al servidor DNS envenenado es engañado para que acepte contenido procedente de un servidor no auténtico y, sin saberlo, descargue 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é DNS va más allá de sus efectos inmediatos, ya que puede exponer a los usuarios a otros riesgos como el phishing , las inyecciones de malware , la denegación de servicio y el secuestro de sitios web debido a las vulnerabilidades del sistema. Diversos 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 dar lugar 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 de destino a realizar una solicitud a un dominio controlado por uno de los servidores de nombres del atacante. [ cita requerida ]
La primera variante del envenenamiento de caché DNS implica redirigir el servidor de nombres del dominio del atacante al servidor de nombres del dominio objetivo 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 Respuesta del atacante:
(sin respuesta)
atacante.ejemplo.3600 EN NS ns.objetivo.ejemplo . ns.target.example. EN UN w.xyz Un servidor vulnerable almacenaría en caché el registro A adicional (dirección IP) parans.target.ejemplo, lo que permite al atacante resolver consultas a todo el sistema.objetivo.ejemplodominio.
La segunda variante del envenenamiento de caché 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 requerida ]
Solicitud del servidor DNS: ¿para qué sirven los registros de direcciones?subdominio.atacante.ejemplo?
subdominio.atacante.ejemplo. EN UN Respuesta del atacante:
(sin respuesta)
objetivo.ejemplo.3600 EN NS ns.atacante.ejemplo . ns.atacante.ejemplo. EN A w.xyz Un servidor vulnerable almacenaría en caché la información de autoridad no relacionada.objetivo.ejemploEl registro NS (entrada del servidor de nombres) permite al atacante resolver consultas a todo el servidor.objetivo.ejemplodominio.
Muchos ataques de envenenamiento de caché contra servidores DNS se pueden prevenir si se confía menos en la información que les pasan otros servidores DNS e ignoran cualquier registro DNS que se devuelva y que no sea directamente relevante para la consulta. Por ejemplo, las versiones de BIND 9.5.0-P1 [5] y posteriores realizan estas comprobaciones. [6] La aleatorización del puerto de origen para las solicitudes 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 que se produzcan ataques de carrera DNS exitosos. [ cita requerida ]
Sin embargo, cuando los enrutadores, cortafuegos , 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 puerto (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 solucionadores de stubs. [ cita requerida ] [7]
El DNS seguro ( DNSSEC ) utiliza firmas digitales criptográficas firmadas con un certificado de clave pública de confianza para determinar la autenticidad de los datos. El DNSSEC puede contrarrestar los ataques de envenenamiento de caché. En 2010, el 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 de estos para DNSSEC 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 aún 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 extremo a extremo una vez que se establece una conexión. Un ejemplo común de esto es el uso de la seguridad de la capa de transporte y las firmas digitales . Por ejemplo, al usar HTTPS (la versión segura de HTTP ), los usuarios pueden verificar 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 contra el certificado incrustado. [9]