Um bug que acreditava-se resolvido desde 2018 voltou com força total. Ataques de envenenamento de cache DNS retornam graças a falhas do Linux. A descoberta é de pesquisadores da Tsinghua University e da University of California. Eles identificaram um novo método para fazer ataques de envenenamento de cache DNS.
O Domain Name System (DNS) pode ser mais facilmente compreendido como sendo uma lista telefônica. É como se você precisasse procurar determinado número antes de fazer a ligação. Da mesma forma, quando você navega para um domínio, o navegador da web tenta identificar seu endereço IP procurando por um sistema de diretório da Internet chamado DNS.
O processo real acontece em uma série de etapas e nem sempre é tão simples. Por exemplo, se você ou alguém de sua rede já tivesse visitado o site sempreupdate.com.br, nosso endereço IP seria armazenado em cache em algum lugar do seu computador ou em servidores intermediários.
Isso significa que da próxima vez que você visitar esta página, não será necessária outra pesquisa de DNS. Seu computador ou navegador da web já saberia onde nos localizar.
Ataques de envenenamento de cache DNS retornam devido a falhas do Linux
Imagine se um cache DNS em que seu computador (o cliente) estava contando para pesquisar o IP de so Sempreupdate e retornasse para você um endereço IP incorreto em vez do nosso?
Os invasores podem causar estragos na Internet, caso consigam envenenar os caches DNS.
Fonte: Bluecat
Esse bug foi descoberto pelo pesquisador de segurança Dan Kaminsky em 2008. Quando um dispositivo pesquisa o endereço IP de um nome de domínio usando DNS, ele inclui um número de ‘ID de transação’ exclusivo na solicitação ao servidor DNS.
Quando o servidor responde ao dispositivo com uma resposta, o dispositivo só aceitará a aceitará como válida se também incluir aquele ID de transação original. A razão para isso é simples: para evitar que um servidor DNS desonesto inunde seu dispositivo com entradas DNS inválidas e maliciosas.
Se essas verificações não estivessem em vigor, um servidor DNS fake poderia facilmente fornecer ao usuário um endereço IP e, ao se conectar a um site, o usuário seria redirecionado para o servidor do invasor em vez do legítimo.
Ataque é limitado
No entanto, Kaminsky descobriu que havia apenas 65.536 IDs de transação possíveis.
Um invasor pode, portanto, enviar várias respostas DNS falsas com IDs de 0 a 65.535 e, ao mesmo tempo, impedir o armazenamento da primeira resposta em cache.
Para evitar o armazenamento em cache da primeira resposta DNS, o invasor enviaria respostas com pequenas variações de um domínio, como cada resposta contendo um subdomínio diferente.
Eventualmente, o invasor seria capaz de adivinhar a ID de transação correta de uma solicitação de DNS e, simultaneamente, fornecer seu IP de servidor malicioso por meio de resposta de DNS. Na próxima vez, o usuário seria redirecionado ao servidor do invasor, caso o ataque seja bem-sucedido.
Como o envenenamento do cache DNS retornou?
Para evitar ataques de envenenamento de cache DNS, houve a randomização da porta de origem.
Isso significa que, mesmo como um invasor, eu pudesse adivinhar um dos 65.536 IDs de transação especificados pelo seu dispositivo em uma solicitação DNS, não saberia para onde enviar a resposta DNS – porque agora seu dispositivo está fazendo uma pesquisa DNS. Portanto, de uma porta aleatória (que em teoria também tem 65.536 valores) em vez da porta 53.
Essa solução tornou virtualmente impossível que ataques de envenenamento de cache DNS ocorressem por meio do método descoberto de Kaminsky, dadas as bilhões de possibilidades.
Saiba como
Porém, pesquisadores da Tsinghua University e da University of California publicaram um método que aproveita um ataque de canal lateral para deduzir o número da porta de origem do cliente DNS.
Com a porta de origem, torna-se mais uma vez possível conduzir ataques de envenenamento de cache DNS de Kaminsky. Isso ocorre adivinhando os IDs de transação. Adivinhar a porta de origem se torna possível por causa da forma como o kernel do Linux lida com solicitações ICMP (pense em ping ou tracert).
Para economizar largura de banda, o limitador de taxa embutido no Linux padroniza o número de solicitações de entrada para 1.000 por segundo e usa um contador para rastrear essas solicitações.
Notícias Relacionadas
Para cada solicitação recebida em uma porta fechada em um servidor baseado em Linux, o contador diminuiria em 1 e o servidor responderia com “inacessível”.
Ou seja, em um segundo, se você enviar 1.000 pacotes para diferentes portas aleatórias em um servidor, todas fechadas, o servidor o cortará naquele segundo.
Mas, isso também informaria que todas as suas 1.000 suposições para quais portas poderiam ser abertas estavam incorretas.
Curiosamente, o contador não diminui para cada solicitação recebida em uma porta aberta válida. E, além disso, “inacessível” não há envio pelo servidor.
Isso significa que, a cada segundo, um invasor pode inundar um resolvedor de DNS com 1.000 pacotes falsificados destinados a portas aleatórias.
Dessa forma, em questão de segundos, o invasor poderá deduzir quais portas estão abertas no resolvedor de DNS que ele está tentando envenenar.
Com o conhecimento da porta certa, eles podem explorar novamente o bug de Kaminsky para causar ataques de envenenamento de DNS.
Então, há uma solução para isso?
Assim como a randomização da porta de origem adicionou alguma complexidade para os invasores, o kernel Linux randomizando o valor máximo do limitador de taxa em vez de sempre usar 1.000 pode ser útil.
Essa correção tornaria novamente difícil para um invasor deduzir a porta correta de destino para ataques de falsificação de DNS.
David Maxwell, diretor de segurança de software da BlueCat ofereceu uma sugestão:
A mudança que está sendo introduzida pelo Linux para randomizar automaticamente o valor ratelimit foi incluída no kernel Linux em 16 de outubro, o que significa que demorará um pouco até que a maioria dos sistemas esteja executando isso. Ainda não está no lançamento. Nesse ínterim, você pode usar um pequeno script de shell para variar constantemente o limite de proporção do ICMP. Não tão limpo quanto está sendo construído no kernel, mas uma solução alternativa viável. Portanto, estamos trabalhando para disponibilizar um script de amostra como esse para a comunidade no momento.
A correção feita no arquivo icmp.c do kernel do Linux agora atribui um valor aleatório ao contador (chamado ‘crédit’), mas pode demorar um pouco até que os servidores Linux ao redor do mundo alcancem, como Maxwell explica.
Maxwell não recomenda bloquear o tráfego ICMP completamente, pois o protocolo tem casos de uso legítimos, como na fragmentação IPv6.
“Se um servidor DNS tiver o ICMP bloqueado completamente, as transferências de zona podem falhar, se houver um salto com um MTU menor (bloquear o ICMP causa um buraco negro no PMTUD) entre ele e o outro servidor”, disse Maxwell ao BleepingComputer.
DNS é inseguro
A descoberta desse ataque de canal lateral coloca uma pressão extra sobre os engenheiros da Internet para aumentar a segurança do DNS.
No entanto, o DNS já é um protocolo relativamente inseguro, projetado para favorecer a velocidade em relação ao desempenho e à segurança.
Mesmo os aprimoramentos de construção, como DNS-over-HTTPS (DoH), não impediram os invasores de abusar do DNS para suas atividades maliciosas.
