No es el plan de Google. No hay forma de que sea el plan de Google. Era el plan de Google
Google ha comenzado a habilitar ampliamente la aleatorización de casos en consultas de dominio enviadas a servidores de nombres autorizados en un esfuerzo por hacer que los ataques de envenenamiento de caché sean menos efectivos.
Esto significa que las consultas para un dominio como ejemplo.com, si las gestiona el DNS público de Google podrían volver a formatearse eXaMpLe.coM cuando la solicitud se transmita a los servidores DNS para buscar. Si bien esto puede ser notado por los administradores que analizan el tráfico de la red, el formato picante no es visible para el público en general por lo que nadie debería darse cuenta, si todo va bien.
Cuando las personas intentan visitar un sitio web, como theregister.com, cualquier navegador o aplicación que estén utilizando consulta el nombre de dominio del sitio mediante el Sistema de nombres de dominio (DNS) para descubrir las direcciones IP de los servidores que alojan el sitio. Dicha consulta de DNS normalmente pasa a través de un servicio de DNS recursivo que se comunica con otros servidores de nombres hasta que finalmente obtiene una respuesta de un servidor de nombres autorizado.
Para acelerar este proceso de varios pasos, estos servidores de nombres intermediarios pueden almacenar en caché las respuestas de las consultas de DNS. Esto abre la posibilidad de ataques de envenenamiento de caché.
Tal ataque implica atacar a uno de estos servidores de nombres intermediarios con un montón de consultas de DNS para dominios que no están en su caché. Luego el servidor de la víctima se comunica con otros servidores de nombres que pueden ayudarlo a responder estas consultas. Al mismo tiempo, el atacante inunda el servidor de la víctima con respuestas falsas disfrazadas para parecer respuestas legítimas de esos otros servidores de nombres.
El objetivo del juego es lograr que el servidor de la víctima acepte una o más de estas respuestas falsificadas, y almacene en caché esa respuesta incorrecta, para que los delincuentes puedan aprovechar la dirección errónea. Por ejemplo la respuesta falsa podría resolver un nombre de dominio valioso como superbigbank.com, en un servidor que se hace pasar por el banco y roba los datos de inicio de sesión de las personas. Si el servidor de la víctima almacena en caché esa información incorrecta, los navegadores y las aplicaciones que posteriormente usan ese servidor para conectarse a superbigbank.com terminan en la dirección IP incorrecta.
Todo esto es posible porque los servidores DNS se basan en UDP, un protocolo de red que es más rápido que TCP pero que no garantiza las conexiones y en consecuencia es más vulnerable a la suplantación de identidad. También funciona porque los ID de consulta de DNS son campos de 16 bits, lo que significa que sus posibles valores pueden oscilar entre 0 y 65 535 un rango lo suficientemente pequeño como para adivinar con una avalancha de solicitudes maliciosas.
Hay un desglose detallado de este ataque aquí si tienes curiosidad. Y sí se supone que DNSSEC frustra este tipo de ataques de envenenamiento de caché, cuando es compatible y se usa.
En 2008, el Grupo de Trabajo de Ingeniería de Internet (IETF) publicó un borrador de propuesta para defenderse contra el envenenamiento de caché. “Uso del bit 0x20 en las etiquetas DNS para mejorar la identidad de las transacciones” describe una forma de aleatorizar el caso de las letras utilizadas en las consultas.
La técnica se denomina codificación DNS-0x20, en referencia al número hexadecimal 0x20 (32 en decimal) y su relación con los caracteres ASCII. Su representación binaria (0b100000) tiene todos sus bits puestos a cero excepto el quinto, contando desde cero, que para los caracteres ASCII determina si una letra es mayúscula o minúscula. Por ejemplo, 01000001 (65 en decimal) es el código ASCII para una A mayúscula mientras que 01100001 (97 decimal) es el código ASCII para una a minúscula.
Descrito con más detalle en un artículo académico [PDF] la codificación DNS-0x20 amplía el rango de posibilidades que un atacante debe adivinar sin confundir la resolución de los nombres DNS y las direcciones IP.
Esencialmente alterna aleatoriamente el bit 0x20 en una consulta para mezclar el caso, enviarlo para que se resuelva y esperar que la respuesta tenga el mismo caso coincidente. Si los casos no coinciden puede verse atrapado en un ataque de envenenamiento de caché ya que el atacante no sabrá qué bits de caso establecerá o borrará usted cuando realice el envenenamiento.
Fuente: https://www.theregister.com/2023/01/19/google_dns_queries/?td=rt-3a
Es un conocido experto en seguridad móvil y análisis de malware. Estudió Ciencias de la Computación en la NYU y comenzó a trabajar como analista de seguridad cibernética en 2003. Trabaja activamente como experto en antimalware. También trabajó para empresas de seguridad como Kaspersky Lab. Su trabajo diario incluye investigar sobre nuevos incidentes de malware y ciberseguridad. También tiene un profundo nivel de conocimiento en seguridad móvil y vulnerabilidades móviles.