.
O Google começou a permitir amplamente a randomização de casos em consultas de domínio enviadas a servidores de nomes autorizados, em um esforço para tornar os ataques de envenenamento de cache menos eficazes.
Isso significa que as consultas para um domínio como exemplo.com, se tratadas pelo DNS público do Google, podem ser reformatadas como eXaMpLe.coM quando a solicitação é transmitida aos servidores DNS para consulta. Embora isso possa ser notado pelos administradores que examinam o tráfego de rede, a formatação picante não é visível para o público em geral, portanto, ninguém deve saber – se tudo correr bem.
Quando as pessoas tentam visitar um site – como theregister.com – qualquer navegador ou aplicativo que estejam usando consulta o nome de domínio do site usando o Domain Name System (DNS) para descobrir os endereços IP dos servidores que hospedam o site. Essa consulta DNS geralmente passa por um serviço DNS recursivo que contata outros servidores de nomes até obter uma resposta de um servidor de nomes autorizado.
Para acelerar esse processo de várias etapas, as respostas de consulta DNS podem ser armazenadas em cache por esses servidores de nomes intermediários. Isso abre a possibilidade de ataques de envenenamento de cache.
Esse ataque envolve atingir um desses servidores de nomes intermediários com várias consultas de DNS para domínios que não estão em seu cache. O servidor vítima entra em contato com outros servidores de nomes que podem ajudá-lo a responder a essas perguntas. Ao mesmo tempo, o invasor inunda o servidor da vítima com respostas falsas disfarçadas para parecer respostas legítimas desses outros servidores de nomes.
O objetivo do jogo é fazer com que o servidor vítima aceite uma ou mais dessas respostas forjadas – e armazene em cache a resposta errada – para que os criminosos possam tirar proveito do direcionamento incorreto. Por exemplo, a resposta falsa pode enviar um nome de domínio valioso – como superbigbank.com – para um servidor que se disfarça de banco e rouba os detalhes de login das pessoas. Se o servidor da vítima armazenar em cache essas informações incorretas, os navegadores e aplicativos subsequentes que usam esse servidor para se conectar ao superbigbank.com acabam no endereço IP errado.
Tudo isso é possível porque os servidores DNS dependem do UDP – um protocolo de rede mais rápido que o TCP, mas que não oferece garantias sobre as conexões e, consequentemente, é mais vulnerável a spoofing. Também funciona porque os IDs de consulta DNS são campos de 16 bits, o que significa que seus valores possíveis podem variar apenas de 0 a 65.535 – um intervalo pequeno o suficiente para adivinhar com uma enxurrada de solicitações maliciosas.
Há uma análise detalhada deste ataque aqui se você está curioso. E sim, DNSSEC deve impedir esses tipos de ataques de envenenamento de cache, quando é suportado e usado.
Em 2008, a Internet Engineering Task Force (IETF) publicou um projecto de proposta para se defender contra envenenamento de cache. “Uso de bit 0x20 em rótulos DNS para melhorar a identidade da transação” descreve uma maneira de randomizar o caso de letras usadas em consultas.
A técnica é chamada de codificação DNS-0x20, em referência ao número hexadecimal 0x20 (32 em decimal) e sua relação com os caracteres ASCII. Sua representação binária (0b100000) tem todos os seus bits zerados, exceto o quinto, contando a partir do zero – que para caracteres ASCII determina se uma letra é maiúscula ou minúscula. Por exemplo, 01000001 (65 em decimal) é o código ASCII para um A maiúsculo, enquanto 01100001 (97 decimal) é o código ASCII para um a minúsculo.
Descrito com mais detalhes em um um trabalho acadêmico [PDF]a codificação DNS-0x20 expande o leque de possibilidades que um invasor deve adivinhar sem confundir a resolução de nomes DNS e endereços IP.
Essencialmente, você alterna aleatoriamente o bit 0x20 em uma consulta para misturar o caso, envia isso para ser resolvido e espera que a resposta tenha o mesmo caso correspondente. Se os casos não corresponderem, você pode ser pego em um ataque de envenenamento de cache, pois o invasor não saberá quais bits de caso serão definidos ou limpos por você ao fazer o envenenamento.
Os servidores DNS, em sua maioria, não diferenciam entre as consultas em TODAS AS MAIÚSCULAS, minúsculas ou ALGUMA MISTURA DOS DOIS. Mas a complexidade adicional de consultas com maiúsculas e minúsculas é importante para os invasores, proporcionalmente ao tamanho do nome de domínio. “Cada bit de codificação DNS-0x20 dobra o trabalho que um invasor deve executar para obter resultados de envenenamento semelhantes”, explica o artigo.
O Google vem brincando com a ideia desde 2009, quando começou a testar a defesa contra envenenamento de cache em um pequeno número de servidores de nomes. Em agosto passado, a gigante das buscas e anúncios começou a implantar a técnica de forma mais ampla.
“Espera-se que o nome da consulta aleatória na solicitação corresponda exatamente ao nome na seção de perguntas da resposta do servidor DNS, incluindo o caso de cada letra ASCII (A–Z e a–z)” explicou O engenheiro de software do Google, Tianhao Chi, em uma postagem na lista de e-mails do DNS público do Google. “Por exemplo, se ‘ExaMplE.CoM’ for o nome enviado na solicitação, o nome na seção de pergunta da resposta também deve ser ‘ExaMplE.CoM’ em vez de, por exemplo, ‘example.com.’ As respostas que não preservam o caso do nome da consulta podem ser descartadas como possíveis ataques de envenenamento de cache.”
Chi observou que apenas um pequeno número de servidores de nomes (menos de 1.000 endereços IP) não lida corretamente com a randomização de casos.
Na terça-feira, Chi disse que o web goliath implantou com sucesso a randomização de casos para algumas regiões da América do Norte, Europa e Ásia, cobrindo cerca de 90% das consultas ainda não protegidas pelo DNS sobre TLS.
“Ainda estamos implantando esse recurso de forma incremental, local por local”, disse Chi. “Isso é mais lento do que o planejado originalmente devido ao cuidado e nossa estimativa de habilitação global é de março a abril de 2023”.
Chi disse que o Google está atento a problemas de servidores de nomes não compatíveis e recomenda que os servidores de nomes preservem o caso de consulta na resposta ou suportem o TCP como um fallback.
Quando tudo estiver dito e feito, a internet deve ser um pouco mais segura. ®
.
