No final de outubro deste ano, um grupo de pesquisadores da Universidade da Califórnia em Riverside, em conjunto com pesquisadores de outras universidades e empresas privadas, publicou um artigo no qual foi possível demonstrar a existência de uma vulnerabilidade presente no ecossistema DNS que permite realizar ataques de envenenamento de cache DNS, um problema que foi descoberto em 2008 pelo pesquisador Dan Kaminsky e que inicialmente se acreditava ter sido corrigido. A recente descoberta trouxe a vulnerabilidade de “volta à tona” ao demonstrar que usando uma nova técnica, denominada SAD DNS, é possível envenenar o cache DNS e fazer com que, após uma busca por um nome de domínio específico, o servidor devolva um IP potencialmente malicioso que redireciona a vítima para um site controlado pelo atacante e não para o site que corresponde ao nome de domínio legítimo.

Como já explicamos em posts anteriores, o Sistema de Nomes de Domínios (DNS) é responsável por traduzir nomes de domínio em endereços IP. Isso existe porque é mais fácil para os usuários lembrar nomes como welivesecurity.com do que seu endereço IP.

Como funciona o ecossistema DNS

Antes de entrar na análise do SAD DNS, para entender essa vulnerabilidade, é necessário explicar mais detalhadamente como funciona a infraestrutura global que permite essas traduções. Para isso, veja a Figura 1. A imagem mostra o fluxo completo de mensagens que deve ser realizado, em casos normais, entre diferentes servidores públicos para encontrar o registro que contém a tradução - ou resolução - que estamos procurando.

Figura 1 – Fonte: Cloudflare.

Como pode ser visto na imagem anterior, um cliente faz uma solicitação a um servidor chamado Resolver, também conhecido como resolvedor recursivo, que para a maioria dos usuários será aquele atribuído pelo fornecedor de serviços de Internet (ISP) ou algum serviço público como o Google 8.8.8.8.

Quando o Resolver recebe uma busca do cliente, ele primeiro procura em seu cache para ver se já contém a resolução procurada. Caso não possua esse registro, ele inicia uma série de buscas para outros servidores, assim como pode ser visto na Figura 1.

O próximo ponto que devemos entender é que as buscas DNS são normalmente executadas usando o protocolo da camada de transporte UDP, que não mantém um estado ou sessão entre o cliente e o servidor e cujo cabeçalho pode ser facilmente modificado para fazer parecer que a busca vem de outro computador. Embora esse protocolo incorpore alguns pontos fracos de segurança, seu uso é uma escolha de design, uma vez que esses servidores lidam com um grande volume de consultas e o UDP requer menos processamento e mensagens do que o protocolo TCP para a troca de dados.

Um atacante pode modificar o cabeçalho UDP se fazendo passar por um servidor autoritativo e introduzir uma resolução falsa que faça com que o Resolver o armazene em seu cache, causando sua contaminação ou "envenenamento". A partir desse momento, qualquer cliente que solicite a resolução de um determinado nome de domínio do Resolver envenenado receberá um IP potencialmente malicioso que o redireciona para o site do atacante ou para o seu endereço de e-mail, dependendo do tipo de registro DNS modificado.

Ataque Kaminsky

Antes de entender o ataque SAD DNS recentemente conhecido, vamos primeiro voltar a 2008, o ano em que surgiram os primeiros ataques de envenenamento de cache DNS. Neste momento, os Resolvers usavam uma porta UDP fixa (53) e a única medida de segurança que existia era um identificador de 16 bits contido no pacote que tinha que corresponder entre a busca e a resposta. Existiram (e ainda existem) outros tipos de fiscalização, como o “bailiwick check”, mas são irrelevantes, uma vez que não afetam mais a esse tipo de ataque e procuram prevenir outros tipos de problemas.

16 bits representam 65536 valores possíveis. O ataque Kaminsky consiste simplesmente em enviar todas essas combinações possíveis para o Resolver, falsificando o IP de um Servidor DNS Autoritativo no cabeçalho UDP, na esperança de que um desses pacotes contenha o ID correto (enviado pelo Resolvedor e com resposta ainda pendente) e que chegue ao Resolver antes da resposta do servidor legítimo. Não era algo que dava certo em 100% dos casos, mas ao continuar tentando, as chances aumentavam e até mesmo em algum momento acabava contaminando o cache do Resolver. Na prática, usando ferramentas automatizadas era possível contaminar o cache em aproximadamente 10 segundos.

Como esse ataque foi mitigado? Se, em vez de sempre usar a porta 53, forem escolhidas portas aleatórias ao enviar uma busca, a entropia aumentará significativamente de 65536 valores possíveis para 4.294.836.225 (216  * 216  = 232). Se a resposta DNS chegar em uma porta diferente daquela em que a busca foi feita, o pacote é descartado pelo sistema operacional e é praticamente impossível para um atacante tentar todas essas combinações antes que a resposta seja produzida pelo servidor legítimo, independentemente do número de tentativas.

Problema resolvido? Aparentemente não

Parece que, após 12 anos do primeiro ataque de envenenamento de cache DNS, essa estratégia realmente voltou à tona. Como vimos na análise do ataque Kaminsky, a medida de segurança que foi adotada para mitigar a vulnerabilidade foi a “randomização” das portas UDP, também conhecida como “Source Port Randomization”.

No entanto, se um atacante pudesse prever a porta aberta de uma maneira mais simples do que tentando todas as combinações possíveis, estaríamos diante de um cenário praticamente idêntico ao anterior (descrito acima). É aqui que entra em jogo a descoberta feita pelos pesquisadores da Universidade da Califórnia em Riverside e da Tsinghua University em Beijng.

A ideia é simples, mas muito genial. Trata-se de derrotar o Source Port Randomization por meio de mensagens de erro ICMP, usadas como um ataque de canal lateral. A técnica faz uso de um recurso do protocolo chamado Response Rate Limiting (RRL) que, ironicamente, foi adotada por razões de segurança para evitar ataques de negação de serviço distribuído (DDoS).

Por padrão, esse valor máximo de respostas por segundo é 1000 em servidores Linux, 200 no Windows Server 2019 (versão 1809) e FreeBSD e, por fim, 250 no MacOS 10.15.

Esse comportamento, adotado para prevenir ataques conhecidos como "Ataque Smurf", permite fazer inferências sobre a configuração do servidor, especialmente, se uma porta está aberta ou fechada, como veremos a seguir.

Se enviarmos um pacote UDP a uma porta fechada, obteremos uma mensagem de erro "port unreachable", mas se a porta estiver aberta não obteremos nenhuma resposta ICMP (a conexão foi bem-sucedida).

Suponhamos que o limite de mensagens definido pelo servidor seja 1000 por segundo. O ataque SAD DNS consiste em primeiro esgotar esse limite com 1000 solicitações que sabemos que irão gerar uma mensagem de erro ICMP, e a partir daí enviar lotes controlados de pacotes UDP, aumentando o número da porta sequencialmente em cada busca. Na Figura 2 podemos ver um diagrama do ataque enviando lotes de 50 pacotes a cada 20 milissegundos (velocidade máxima permitida nesse exemplo).

Figura 2. Diagrama do ataque. Fonte: Cloudflare.

Os primeiros 49 pacotes enviados pelo atacante falsificam o IP do servidor autoritativo, enquanto o último contém seu próprio endereço IP. A maioria das respostas ICMP irá para o endereço IP falsificado, de forma que o atacante não será capaz de vê-las, no entanto, elas não são necessárias. O truque é que se todas as portas estiverem fechadas, o contador do sistema operacional da vítima já terá atingido 1000, esgotando o limite de resposta estabelecido pelo RRL.

Isso significa que se o último pacote de cada lote enviado pelo atacante - enviado com seu endereço IP - não recebe nenhuma mensagem de erro ICMP, todas as portas foram fechadas. Caso uma mensagem de erro seja enviada, significa que o contador atingiu 999; ou seja, uma das portas estava aberta. Dessa forma, é possível restringir a busca de forma significativa.

As 1000 portas ainda representam um número enorme de possibilidades, mas é possível repetir esse processo de forma semelhante mais algumas vezes para restringir ainda mais a busca.

Em teoria, o ataque completo pode levar até 65 segundos, portanto, é provável que a resposta legítima do servidor chegue antes e o ataque falhe. Porém, como no caso do ataque Kaminsky, as chances de sucesso do ataque aumentam ao ser repetido.

Os pesquisadores não indicaram um tempo médio que leva para uma contaminação de cache bem-sucedida, no entanto, foi possível confirmar que 34% de todos os Resolvers na Internet são vulneráveis, incluindo, por exemplo, os serviços do Google 8.8.8.8 e 1.1. 1.1 da Cloudflare. Os pesquisadores trabalharam com essas e outras organizações para corrigir as vulnerabilidades antes de publicar o artigo.

Tenho um resolvedor recursivo próprio. E agora? Quais ações de mitigação devo implementar?

Esse ataque pode ter um impacto severo, portanto, os administradores de rede que usam servidores DNS desse tipo são aconselhados a adotar as seguintes dicas o mais rápido possível:

Dicas:

  • Atualizar o kernel do Linux para sua versão mais recente. Essa vulnerabilidade já foi corrigida randomizando o RRL para adicionar uma entropia ainda maior e efetivamente tornar esse ataque impraticável.
  • Bloquear mensagens de erro de “port unreachable” do ICMP no firewall.
  • Manter o software DNS atualizado.

Detecção de um ataque:

  • Detectar o tempo dos ataques, por exemplo, se lotes de 50 pacotes são enviados a cada 20 ms, provavelmente seja um ataque.
  • Detectar IDs de DNS incorretos em respostas recebidas pelo servidor – não é comum que o tráfego legítimo contenha IDs incorretos.