Uma explicação simples sobre o SAD DNS e por que ele é um desastre (ou uma bênção)

Em 2008, Kaminsky abalou os alicerces da internet. Uma falha de design no DNS permitia falsificar respostas e enviar a vítima para onde o invasor queria. 12 anos depois, uma fórmula semelhante muito interessante foi encontrada para ser capaz de envenenar o cache dos servidores DNS. Pior, se possível, do que o de Kaminsky. Principalmente porque não precisa estar na mesma rede que a vítima e porque foi anunciado quando muitos servidores, sistemas operacionais e programas ainda não foram corrigidos . Vamos ver como funciona de maneira compreensível.

Para falsificar uma solicitação DNS e um retorno falso para o cliente, o invasor deve saber o TxID (ID da transação) e a porta de origem UDP. Isso pressupõe uma entropia de 32 bits (supondo dois campos de 16 bits). O SAD DNS consiste (basicamente, porque o papel é muito complexo) em inferir a porta UDP por meio de um método engenhoso que usa mensagens de retorno de erro ICMP. Se a porta for deduzida, isso novamente deixa uma entropia de apenas o TxID de 16 bits, aceitável para um ataque. Assim que você tiver essas duas informações, o pacote é construído e o servidor de nomes é bombardeado.

Como inferir a porta UDP aberta?

As preliminares necessárias são que devido ao funcionamento do UDP, o servidor abre algumas portas de resposta UDP através das quais se comunica com outros servidores de nomes. Conhecer as portas efêmeras que ele abre em suas comunicações é vital porque, junto com o TxID, elas representam tudo o que um invasor precisa para falsificar a resposta. Ou seja, se um servidor (resolver ou forwarder) faz uma pergunta a outro servidor, ele espera um TxID e UDP específicos em sua resposta. E quem quer que devolva um pacote com esses dados, vai entender isso como uma verdade absoluta. Você pode ser enganado com uma resolução de IP de domínio falsa. Nesse caso, basta que o atacante conheça a porta UDP aberta, deduza o TxID pela força bruta e bombardeie sua vítima.

Quando você contata uma porta UDP e pergunta se ela está aberta ou não, os servidores retornam uma mensagem de «porta fechada» no ICMP. Para não sobrecarregar com as respostas, eles têm um limite geral de 1000 por segundo. Um limite global significa que não importa se são solicitados 100 ou 10 servidores ao mesmo tempo, pois todos você tem 1000 respostas em um segundo para abrir perguntas sobre portas, por exemplo. Isso, que foi feito para não saturar o sistema, é o que realmente causa todo esse problema.

O limite global é 1000 no Linux, 200 no Windows e FreeBSD e 250 no MacOS. E, na realidade, todo o paper se baseia em «denunciar» essa fórmula de limite global fixo. Deve ser revisto porque você já foi alertado sobre os perigos disso antes, mas nunca com um ataque e aplicação tão práticos. Também é importante porque não apenas DNS, mas QUIC e HTTP/3, baseados em UDP, podem ser vulneráveis. O ataque é complexo e em cada etapa há detalhes a serem mitigados, mas fundamentalmente as etapas básicas são (com possíveis imprecisões por uma questão de simplicidade):

• Envie 1000 sondagens UDP para o resolvedor da vítima com IPs de origem falsificados testando 1000 portas. Na verdade, são lotes de 50 a cada 20 ms para exceder outro limite de respostas por IP que o sistema operacional Linux possui.
• Se todas as 1000 portas estiverem fechadas, a vítima retornará (para IPs falsificados) 1000 pacotes de erro ICMP indicando que a porta não está aberta. Se estiver aberto, nada acontece, ele é descartado pelo aplicativo correspondente nessa porta. Não importa se o invasor não vê a resposta do ICMP (eles alcançam os IPs falsificados). O que importa é ver quanto do limite global de 1000 respostas por segundo é “gasto” naquele lote.
•  Antes de deixar essa segunda passagem, o invasor consulta qualquer porta UDP que ele saiba que está fechada e se o servidor retornar um ICMP de «porta fechada»… significa que o ICPM 1000 de «erro de porta fechada» não foi usado e, portanto… Nesse intervalo de 1000, havia pelo menos uma porta aberta! Bingo. Como o limite de resposta ICMP é global, uma única resposta de porta fechada significa que o limite de 1000 respostas de “porta fechada” por segundo não foi gasto. Alguns foram abertos. Esta consulta é feita a partir do seu IP real, não falsificado, para realmente receber (ou não) a resposta.

Assim, em lotes de 1000 consultas por segundo e verificando se o limite do pacote de erro de porta fechada é usado ou não, o invasor pode deduzir gradualmente quais portas estão abertas. Em nenhum momento você terá as portas abertas do servidor mapeadas. Obviamente, o invasor combina isso com pesquisas binárias «inteligentes» para otimizar, dividindo os intervalos de portas «potencialmente abertas» em cada lote para ir mais rápido e, assim, encontrar os dados específicos.

Os pesquisadores também tiveram que eliminar o «ruído» de outras portas abertas ou varreduras que estão sendo feitas no sistema enquanto o invasor o executa, e no papel eles esclarecem algumas fórmulas para conseguir isso.

Mais falhas e problemas

Tudo vem de uma tempestade perfeita de erros na implementação do UDP, na implementação do limite de 1000 respostas… A explicação acima é «simplista» porque os pesquisadores detectaram outros problemas de implementação que às vezes até os beneficiavam e outros consistiam em ligeiras variações do ataque.

Porque a falha não está apenas na implementação do limite global ICMP. A própria implementação do UDP também não é poupada. De acordo com a RFC, em um único socket UDP, os aplicativos podem receber conexões de diferentes IPs de origem no mesmo socket. A verificação de quem obtém o que resta na RFC nas mãos do aplicativo que trata da conexão de entrada. Isso, que deveria se aplicar a servidores (são sockets que recebem), também se aplica a clientes. Assim, de acordo com os experimentos no paper também se aplica ao cliente UDP que abre portas para consultas e, portanto, torna o ataque muito mais fácil, permitindo que portas “abertas” sejam verificadas para consultas com qualquer endereço IP de origem.

E algo muito importante: o que acontece se, na implementação UDP, a aplicação marcar uma porta de resposta UDP como «privada» para que apenas quem está iniciando a conexão possa se conectar a ela (e outros não possam ver se está aberta ou fechada?) Isso seria um problema para a primeira etapa do ataque, em que os IPs de origem são falsificados e acelera o processo. A abertura de portas «públicas» ou «privadas» depende do servidor DNS. E apenas o BIND faz isso direito. Dnsmask, Unbound, no. Nesses casos, os IPs dos streaks não podem ser falsificados (aqueles usados ​​para gastar o limite global e você não liga se recebe ou não), mas você só pode falsificar os streaks com um único IP de origem. Isso tornaria a varredura mais lenta. Mas não há problema. Se não, e as portas são privadas, também existe um bug no Linux para «mitigá-lo». A verificação do «limite global» é feita antes que o limite de IP seja contado. Isso, que a princípio era feito assim porque verificar o limite global é mais rápido que o limite por IP, na verdade permite que não demore tanto e a técnica continue válida mesmo com portas privadas.

O paper continua com recomendações para forwarders, resolvers… uma revisão completa da segurança do DNS.

Soluções?

O Linux já tem um patch pronto , mas há muito tecido para cortar. Desde DNSSEC, que é sempre recomendado, mas nunca realmente decola, até a desativação de respostas ICMP… o que pode ser complexo. O patch do kernel agora terá um valor fixo de 1000 respostas por segundo, mas aleatório entre 500 e 2000. Assim, o invasor não será capaz de adivinhar corretamente para descobrir se esse limite foi gasto em um segundo e deduzir as portas UDP abrir.

Parece que a fonte absoluta do problema é a implementação, não o design. Este RFC descreve esse limite de taxa de resposta e é deixado em aberto para um número. Escolhê-lo fixo e em 1000 como foi feito no Kernel em 2014 é parte do problema.

Pelo caminho, com este roteiro de BlueCatLabs programadas a cada minuto, você pode atenuar o problema no servidor DNS manualmente qual será o patch para o DNS SAD.

Então, vamos esperar por patches para todos: os sistemas operacionais e os principais servidores DNS. Muitos servidores públicos já foram corrigidos, mas muitos outros não. É particularmente interessante neste ataque que é muito limpo para o atacante, não precisa estar na rede da vítima. Você pode fazer tudo de fora e confundir os servidores. Um desastre. Ou uma bênção. Por causa disso, muitas «pontas soltas» no protocolo UDP e DNS serão corrigidas.