secuestro de DNS

Un servidor DNS malicioso traduce los nombres de dominio de sitios web deseables (motores de búsqueda, bancos, corredores de bolsa, etc.) a direcciones IP de sitios con contenido no deseado, incluso sitios web maliciosos. La mayoría de los usuarios dependen de los servidores DNS asignados automáticamente por sus ISP . Los servidores DNS asignados a un enrutador también pueden alterarse mediante la explotación remota de una vulnerabilidad en el firmware del enrutador. ^{[ 2 ]} Cuando un usuario intenta visitar un sitio web, en su lugar es enviado a una página falsa que parece usar el mismo dominio. Este ataque se denomina pharming . Si el sitio al que se le redirige es un sitio web malicioso que se hace pasar por un sitio web legítimo para obtener información confidencial de forma fraudulenta, se denomina phishing . ^{[ 3 ]}

Varios proveedores de servicios de Internet para consumidores, como AT&T , ^{[ 4 ]} Optimum Online de Cablevision , ^{[ 5 ]} CenturyLink , ^{[ 6 ]} Cox Communications , RCN , ^{[ 7 ]} Rogers , ^{[ 8 ]} Charter Communications (Spectrum) , Plusnet , ^{[ 9 ]} Verizon , ^{[ 10 ]} Sprint , ^{[ 11 ]} T-Mobile US , ^{[ 12 ]} Virgin Media , ^{[ 13 ] [ 14 ]} Frontier Communications , Bell Internet , ^{[ 15 ]} Deutsche Telekom AG , ^{[ 16 ]} Optus , ^{[ 17 ]} Mediacom , ^{[ 18 ]} ONO , ^{[ 19 ]} TalkTalk , ^{[ 20 ]} Bigpond ( Telstra ) , ^{[ 21 ] [} 22 ] ^{[ 23 ] [ 24 ]} TTNET ^{, Türksat} y todos los ISP de clientes indonesios usan o usaron el secuestro de DNS para sus propios fines, como mostrar anuncios ^{[ 25 ]} o recopilar estadísticas. Los ISP holandeses XS4ALL y Ziggo usan el secuestro de DNS por orden judicial: se les ordenó bloquear el acceso a The Pirate Bay y mostrar una página de advertencia ^{[ 26 ]} mientras que todos los ISP de clientes legales en Indonesia hacen el secuestro de DNS para cumplir con la Ley Nacional de DNS ^{[ 27 ]} que exige que cada ISP de clientes indonesio secuestre el puerto 53 y lo redirija a su propio servidor para bloquear los sitios web que están listados en Trustpositif por Kominfo.bajo la campaña Internet Sehat. Estas prácticas violan directamente los estándares RFC para respuestas DNS (NXDOMAIN) e introducen vulnerabilidades de seguridad como el cross-site scripting. Sin embargo, la efectividad del secuestro de DNS a nivel de ISP ha disminuido sustancialmente debido a la adopción generalizada de protocolos DNS cifrados, específicamente DNS sobre HTTPS (DoH) y DNS sobre TLS (DoT). Los navegadores web y sistemas operativos modernos enrutan cada vez más las consultas a través de estos canales cifrados por defecto, lo que impide que los ISP intercepten o manipulen las respuestas DNS. ^{[ 28 ] [ 25 ]}

El problema del secuestro de DNS radica en la manipulación de la respuesta NXDOMAIN. Las aplicaciones de Internet e intranet dependen de esta respuesta para indicar que el DNS no tiene ninguna entrada para el host especificado. Si se consulta un nombre de dominio no válido (por ejemplo, www.example.invalid), se debería recibir una respuesta NXDOMAIN, que informa a la aplicación de que el nombre no es válido y le indica que tome las medidas adecuadas (por ejemplo, mostrar un error o no intentar conectarse al servidor). Sin embargo, si se consulta el nombre de dominio en uno de estos proveedores de servicios de Internet (ISP) que no cumplen con las normas, siempre se recibirá una dirección IP falsa perteneciente al ISP. En un navegador web , este comportamiento puede resultar molesto, ya que las conexiones a esta dirección IP muestran la página de redireccionamiento del ISP, a veces con publicidad, en lugar de un mensaje de error adecuado. Además, otras aplicaciones que dependen del error NXDOMAIN intentarán iniciar conexiones a esta dirección IP falsificada, lo que podría exponer información confidencial.

Ejemplos de funcionalidades que dejan de funcionar cuando un ISP secuestra el DNS:

• Los portátiles que forman parte de un dominio de Windows Server y que se encuentran en itinerancia creerán erróneamente que están conectados a la red corporativa, ya que recursos como los controladores de dominio , los servidores de correo electrónico y otra infraestructura parecerán estar disponibles. Por lo tanto, las aplicaciones intentarán conectarse a estos servidores corporativos, pero fallarán, lo que provocará una disminución del rendimiento, tráfico innecesario en la conexión a Internet y tiempos de espera agotados .
• Muchas redes domésticas y de pequeñas oficinas no tienen su propio servidor DNS, sino que dependen de la resolución de nombres por difusión . Muchas versiones de Microsoft Windows priorizan por defecto la resolución de nombres DNS sobre las difusiones de resolución de nombres NetBIOS; por lo tanto, cuando un servidor DNS del ISP devuelve una dirección IP (técnicamente válida) para el nombre del equipo deseado en la LAN, el equipo que intenta conectarse utiliza esta dirección IP incorrecta e inevitablemente no logra conectarse al equipo deseado en la LAN. Las soluciones alternativas incluyen usar la dirección IP correcta en lugar del nombre del equipo, o cambiar el valor del registro DhcpNodeType para modificar el orden del servicio de resolución de nombres. ^{[ 29 ]}
• Los navegadores como Firefox ya no tienen su función "Buscar por nombre" (donde las palabras clave escritas en la barra de direcciones llevan a los usuarios al sitio que más se ajusta a la búsqueda). ^{[ 30 ]}
• El cliente DNS local integrado en los sistemas operativos modernos almacena en caché los resultados de las búsquedas DNS por motivos de rendimiento. Si un cliente cambia entre una red doméstica y una VPN , es posible que queden entradas erróneas en la caché, lo que provocaría una interrupción del servicio en la conexión VPN.
• Las soluciones antispam DNSBL dependen del DNS; por lo tanto, los resultados DNS erróneos interfieren con su funcionamiento.
• Las aplicaciones, engañadas por el proveedor de servicios de Internet (ISP), podrían filtrar datos confidenciales de los usuarios haciéndoles creer que los servidores a los que desean conectarse están disponibles.
• Se elimina la posibilidad de que el usuario elija qué motor de búsqueda consultar en caso de que escriba mal una URL en el navegador, ya que el proveedor de servicios de Internet (ISP) determina qué resultados de búsqueda se muestran al usuario.
• Los ordenadores configurados para usar un túnel dividido con una conexión VPN dejarán de funcionar porque los nombres de la intranet que no deberían resolverse fuera del túnel a través de Internet pública comenzarán a resolverse a direcciones ficticias, en lugar de resolverse correctamente a través del túnel VPN en un servidor DNS privado cuando se reciba una respuesta NXDOMAIN de Internet. Por ejemplo, un cliente de correo que intenta resolver el registro DNS A para un servidor de correo interno puede recibir una respuesta DNS falsa que lo dirige a un servidor web de resultados de pago, con mensajes en cola para su entrega durante días mientras se intenta la retransmisión en vano. ^{[ 31 ]}
• Esto vulnera el Protocolo de detección automática de proxy web (WPAD) al llevar a los navegadores web a creer erróneamente que el proveedor de servicios de Internet (ISP) tiene un servidor proxy configurado.
• Esto provoca fallos en el software de monitorización. Por ejemplo, si se contacta periódicamente con un servidor para comprobar su estado, el sistema de monitorización nunca detectará un fallo a menos que intente verificar la clave criptográfica del servidor.

En algunos casos, aunque no en la mayoría, los proveedores de servicios de Internet (ISP) ofrecen ajustes configurables por el usuario para deshabilitar el secuestro de respuestas NXDOMAIN. Si se implementa correctamente, este ajuste restablece el comportamiento estándar del DNS. Sin embargo, otros ISP utilizan una cookie del navegador web para almacenar la preferencia. En este caso, el problema subyacente persiste: las consultas DNS siguen redirigiéndose, mientras que la página de redirección del ISP se reemplaza por una página de error DNS falsa. Las aplicaciones distintas de los navegadores web no pueden excluirse de este esquema mediante cookies, ya que la exclusión solo afecta al protocolo HTTP , cuando en realidad el esquema se implementa en el protocolo DNS, que es independiente del protocolo.