Se exploradas, essas falhas podem permitir que invasores obtenham acesso não autorizado a informações confidenciais ou geralmente causem problemas
O Centro de Coordenação CERT (Equipe de Resposta a Emergências Informáticas) publicado alguns dias atrásé um alerta sobre uma série de vulnerabilidades em implementações de protocolo de aplicação que usam UDP como transporte. O CERT menciona que essas vulnerabilidades pode causar negação de serviço gerando loops de pacotes entre hosts, esgotando a largura de banda disponível, bloqueando serviços de rede e facilitando ataques DDoS. (por exemplo, criando uma carga alta e excedendo os limites de taxa de solicitação).
É mencionado que as vulnerabilidades Eles se originam da falta de segurança do protocolo UDP contra falsificação de endereço. Na ausência de proteção contra esse tipo de falsificação em roteadores de trânsito, um invasor pode especificar o endereço IP de um servidor arbitrário em um pacote UDP e enviá-lo para outro servidor. Este segundo servidor retornará uma resposta ao endereço falso fornecido.
Pesquisadores de segurança identificaram que certas implementações do protocolo UDP em aplicativos podem ser acionadas para criar um loop de rede de pacotes aparentemente intermináveis...
Por exemplo, se dois servidores de aplicativos tiverem uma implementação vulnerável de tal protocolo, um invasor poderá iniciar a comunicação com o primeiro servidor, falsificando o endereço de rede do segundo servidor (vítima). Em muitos casos, o primeiro servidor responderá com uma mensagem de erro à vítima, o que também desencadeará um comportamento semelhante de outra mensagem de erro para o primeiro servidor. Foi demonstrado que esse comportamento drena recursos e pode fazer com que os serviços parem de responder ou fiquem instáveis.
O método de ataque é baseado na criação de um loop de troca de pacotes entre servidores que usam implementações de protocolo vulneráveis. Por exemplo, quando o servidor de destino responde a um pacote recebido com um código de erro, o servidor cujo endereço foi falsificado pelo invasor também enviará sua resposta, gerando uma resposta adicional do servidor original, e assim por diante, causando uma situação de travamento. loop infinito ou "ping-pong" entre servidores.
Protocolos vulneráveis incluir implementações DNS, NTP, TFTP, Eco, Chargen e QOTD, Além disso, foi confirmada a presença da vulnerabilidade CVE-2024-2169 em produtos da Cisco, bem como da Microsoft, Broadcom, entre outros.
Uma varredura global de endereços da Internet revelou que existem pelo menos 23 mil servidores TFTP vulneráveis, 63 mil servidores DNS, 89 mil servidores NTP, 56 mil serviços Echo/RFC862, 22 mil serviços Chargen/RFC864 e 21 mil serviços QOTD/RFC865. No caso dos servidores NTP, a vulnerabilidade não corrigida é atribuída ao uso de versões muito antigas do ntpd anteriores a 2010.
Os serviços Echo, Chargen e QOTD são inerentemente vulneráveis devido à sua arquitetura e é mencionado que a situação com os servidores TFTP e DNS requer investigação com os seus administradores. Os servidores atftpd e tftpd não são afetados devido ao uso de um número de porta de rede de origem aleatório ao enviar uma resposta. É mencionado que dproxy-nexgen está entre os servidores DNS vulneráveis. Nos produtos Microsoft, o problema afeta o WDS (Windows Deployment Services), enquanto nos produtos Cisco, o problema afeta os roteadores das séries 2800 e 2970.
Como método para “corrigir o problema” é recomendado habilitar o uRPF no firewall, limitando o acesso a serviços UDP desnecessários e configurando a limitação da intensidade do tráfego como soluções alternativas para bloquear essas vulnerabilidades.
Assim sendo Esses tipos de ataques não são novos, já que para citar um exemplo, existe a vulnerabilidade que foi detectada no servidor de sincronização de horário ntpd, uma variante do ataque foi abordada em 2009 (CVE-2009-3563) nas versões 4.2.4p8 e 4.2.5. Este ataque envolveu o envio de um pacote NTP com um endereço falsificado e o sinalizador MODE_PRIVATE ativado. Quando o servidor de destino processou este pacote, ele retornou uma resposta indicando que não poderia usar o modo privado, mas deixou o sinalizador MODE_PRIVATE habilitado na resposta.
Se você interessado em saber mais sobre isso, você pode verificar os detalhes em o seguinte link.