Entendendo e Protegendo o RADIUS Contra Ataques de Colisão MD5

Resumo Executivo

O protocolo RADIUS, um pilar da autenticação de redes corporativas desde 1991, carrega uma vulnerabilidade crítica e agora praticamente explorável. Revelada em julho de 2024 sob a CVE-2024-3596 e apelidada de 'Blast-RADIUS', essa falha permite que um invasor man-in-the-middle (MitM) posicionado entre um cliente e um servidor RADIUS forje uma aprovação de autenticação válida — convertendo um 'Access-Reject' legítimo em um 'Access-Accept' — sem nunca saber a senha do usuário ou o segredo compartilhado do RADIUS. O ataque explora técnicas de colisão de prefixo escolhido em MD5 que, com hardware moderno, podem ser executadas em minutos.

Para operadores de locais públicos e equipes de TI corporativas, o risco de negócios é direto: um invasor que obtém acesso não autorizado à rede pode se mover lateralmente pela infraestrutura, acessar sistemas de ponto de venda, exfiltrar dados de convidados e causar violações de conformidade sob o PCI DSS e GDPR. Toda organização que executa RADIUS/UDP com modos de autenticação PAP, CHAP ou MS-CHAP está exposta até que as correções sejam aplicadas e as mudanças arquitetônicas sejam planejadas. A mitigação imediata — impor o atributo Message-Authenticator em todo o tráfego RADIUS — é uma mudança de configuração de baixo impacto disponível em todos os principais fornecedores. A resposta estratégica é uma migração em fases para EAP-TLS e RADIUS sobre TLS (RADSEC).

Análise Técnica Detalhada

O Protocolo RADIUS e Sua Herança Criptográfica

O RADIUS (Remote Authentication Dial-In User Service), padronizado na RFC 2865, foi projetado em uma época em que os requisitos de segurança de rede eram fundamentalmente diferentes. O protocolo opera sobre UDP e usa um segredo compartilhado entre o cliente RADIUS (geralmente um ponto de acesso ou servidor de acesso à rede) e o servidor RADIUS para fornecer um grau de integridade de mensagem. Especificamente, as respostas do servidor são 'autenticadas' usando uma estrutura chamada Response Authenticator, calculada como:

MD5(Code || ID || Length || RequestAuthenticator || Attributes || SharedSecret)

Essa construção nunca foi um código de autenticação de mensagem (MAC) adequado. Ela precede o HMAC, que foi padronizado em 1997 precisamente para resolver as fraquezas dos MACs baseados em hash puro. A especificação do RADIUS não foi atualizada quando o HMAC foi introduzido, nem quando as colisões de MD5 foram demonstradas pela primeira vez em 2004. Esse débito arquitetônico agora se tornou uma responsabilidade crítica.

A Mecânica do Ataque Blast-RADIUS

O ataque Blast-RADIUS (CVE-2024-3596) combina três elementos: uma vulnerabilidade no nível do protocolo na forma como o RADIUS constrói seu Response Authenticator, uma técnica de colisão de prefixo escolhido de MD5 e melhorias significativas de velocidade na computação de colisão que tornam o ataque prático em um cenário de interceptação de rede em tempo real.

O ataque ocorre da seguinte forma. Um invasor MitM intercepta um pacote Access-Request enviado do cliente RADIUS para o servidor. O invasor injeta um atributo malicioso nesta solicitação — um payload cuidadosamente elaborado que causará uma colisão entre o hash MD5 da resposta legítima do servidor e o hash MD5 da resposta forjada desejada pelo invasor. Quando o servidor retorna um Access-Reject (uma falha de autenticação), o invasor usa a colisão pré-computada para forjar um pacote Access-Accept válido, completo com um Response Authenticator que o cliente RADIUS aceitará como genuíno. O invasor não precisa saber o segredo compartilhado ou as credenciais do usuário.

Pesquisadores da Boston University, UC San Diego, CWI Amsterdam e Microsoft demonstraram que, com algoritmos otimizados, a colisão de prefixo escolhido de MD5 necessária para este ataque pode ser computada em menos de cinco minutos em hardware comum. Isso torna o ataque operacionalmente viável para um adversário determinado com acesso ao caminho de rede entre o cliente RADIUS e o servidor.

Modos de Autenticação Afetados

A vulnerabilidade afeta todas as implantações de RADIUS/UDP que usam métodos de autenticação não-EAP. A tabela abaixo resume a exposição por modo de autenticação:

A distinção crítica é que os métodos baseados em EAP estabelecem seu próprio túnel criptográfico para autenticação, o qual não depende do MD5 Response Authenticator. Isso os torna imunes ao vetor de ataque específico do Blast-RADIUS.

Por que a Segmentação de VLAN Não É Suficiente

Um equívoco comum é que isolar o tráfego RADIUS em uma VLAN de gerenciamento dedicada fornece proteção adequada. Embora a segmentação de rede seja uma prática de segurança sólida, ela não elimina o risco do Blast-RADIUS. Um invasor que já tenha comprometido um dispositivo na rede de gerenciamento — por meio de um ataque de phishing, comprometimento da cadeia de suprimentos ou exploração de outra vulnerabilidade — pode se posicionar como um MitM no caminho do tráfego RADIUS. O ataque requer apenas acesso ao caminho da rede, não acesso externo à internet. A segmentação reduz a superfície de ataque, mas não elimina a fraqueza criptográfica subjacente.

Guia de Implementação

Fase 1: Endurecimento Imediato (Semanas 1–2)

A primeira prioridade é aplicar os patches dos fornecedores para a CVE-2024-3596 em toda a infraestrutura RADIUS. Todos os principais fornecedores — incluindo Cisco ISE, Microsoft NPS, FreeRADIUS, Juniper, Aruba e Ruckus — lançaram atualizações. Juntamente com a aplicação de patches, a mudança de configuração crítica é impor o atributo Message-Authenticator em todos os clientes e servidores RADIUS.

O atributo Message-Authenticator (definido na RFC 2869) fornece uma verificação de integridade HMAC-MD5 em todo o pacote RADIUS. Ao contrário do Response Authenticator, essa construção não é vulnerável ao ataque de colisão de prefixo escolhido porque a construção HMAC vincula o hash ao segredo compartilhado de uma forma que impede o invasor de criar uma falsificação válida. Configurar clientes e servidores para exigir esse atributo — e rejeitar qualquer mensagem que não o inclua — fecha o vetor de ataque imediato.

Para o FreeRADIUS, isso envolve definir require_message_authenticator = yes no arquivo clients.conf. Para o Microsoft NPS, a política equivalente é imposta por meio das configurações de Diretiva de Rede. Para o Cisco ISE, a configuração está disponível na configuração do cliente RADIUS sob a política de autenticação. Consulte o aviso específico do seu fornecedor para a CVE-2024-3596 para obter as etapas exatas de configuração.

Fase 2: Modernização da Autenticação (Meses 1–3)

O objetivo de médio prazo é migrar a autenticação WiFi de modos legados PAP/CHAP para métodos baseados em EAP. Para ambientes WiFi corporativos, o caminho recomendado é WPA3-Enterprise com EAP-TLS. Isso requer a implantação de uma Infraestrutura de Chaves Públicas (ICP/PKI) para emitir certificados de dispositivo e/ou usuário, configurar seu servidor RADIUS para validar esses certificados e provisionar os dispositivos clientes com os certificados apropriados e as âncoras de confiança do servidor RADIUS.

Para ambientes onde a implantação de certificados é complexa — como locais com alta rotatividade de dispositivos ou políticas de BYOD — o PEAP com MSCHAPv2 oferece uma etapa intermediária aceitável, desde que os clientes estejam configurados para validar o certificado do servidor RADIUS. Sem a validação do certificado do servidor, o PEAP fica vulnerável a ataques de rogue access point. O controle de acesso baseado em porta IEEE 802.1X deve ser implementado na infraestrutura cabeada simultaneamente para garantir uma política de autenticação consistente em toda a rede.

Fase 3: Transport Layer Security (Meses 3–12)

O objetivo arquitetônico de longo prazo é encapsular todo o tráfego RADIUS dentro de um túnel TLS usando RADIUS over TLS (RADSEC), padronizado na RFC 6614. O RADSEC substitui o UDP pelo TCP e envolve toda a sessão RADIUS em uma conexão TLS mutuamente autenticada. Isso fornece confidencialidade, integridade e proteção contra replay para todo o tráfego de autenticação, tornando o MD5 Response Authenticator irrelevante, pois a própria camada de transporte é criptograficamente segura.

O RADSEC é particularmente valioso em implantações distribuídas — como redes de hotéis, redes de varejo ou ambientes de estádios — onde o tráfego RADIUS pode atravessar segmentos de rede intermediários. O IETF está atualmente avançando o RADIUS over TLS e DTLS para o status de padrão, refletindo o consenso do setor de que o RADIUS/UDP deve ser descontinuado para implantações confidenciais.

Melhores Práticas

As seguintes melhores práticas neutras em relação a fornecedores refletem os padrões atuais do setor e as orientações regulatórias para a segurança de autenticação de WiFi corporativo.

Imponha o Message-Authenticator universalmente. Cada cliente e servidor RADIUS em sua infraestrutura deve ser configurado para enviar e exigir o atributo Message-Authenticator. Esta é a ação de maior impacto e menor interrupção disponível hoje. De acordo com as orientações da equipe de pesquisa do Blast-RADIUS, este atributo deve aparecer como o primeiro atributo nas respostas Access-Accept e Access-Reject.

Adote o EAP-TLS como o padrão de autenticação. O IEEE 802.1X com EAP-TLS fornece autenticação mútua baseada em certificado que é imune à classe de ataque Blast-RADIUS e se alinha com as recomendações do NIST SP 800-120 para métodos EAP em acesso à rede sem fio. O WPA3-Enterprise exige o modo de segurança de 192 bits com EAP-TLS para o nível de segurança mais alto.

Rotacione os segredos compartilhados do RADIUS regularmente. Embora o ataque Blast-RADIUS não exija o conhecimento do segredo compartilhado, segredos compartilhados fortes e exclusivos (mínimo de 32 caracteres, gerados aleatoriamente) reduzem o risco de outras classes de ataque. Os segredos devem ser rotacionados pelo menos anualmente e imediatamente após qualquer suspeita de comprometimento.

Implemente a contabilização RADIUS e o monitoramento de anomalias. Os logs de contabilização RADIUS fornecem uma trilha de auditoria dos eventos de autenticação. O monitoramento de padrões anômalos — como autenticações bem-sucedidas de tipos de dispositivos inesperados, endereços MAC ou em horários incomuns — pode fornecer um aviso prévio de exploração. Integre a contabilização RADIUS ao seu SIEM para alertas automatizados.

Segmente o tráfego RADIUS. Embora não seja uma mitigação completa, colocar o tráfego RADIUS em uma VLAN de gerenciamento dedicada com ACLs rígidas reduz a população de dispositivos que poderiam ser usados como um ponto de articulação MitM. Combine com o controle de acesso à rede para garantir que apenas dispositivos autorizados possam alcançar o servidor RADIUS.

Alinhe-se com os requisitos do PCI DSS. O Requisito 8.6 do PCI DSS v4.0 exige autenticação forte para todas as contas. O Requisito 1.3 exige controles de segmentação de rede. As organizações que processam dados de cartões de pagamento devem garantir que sua arquitetura de autenticação WiFi atenda a esses requisitos, e a vulnerabilidade Blast-RADIUS afeta diretamente a postura de conformidade para qualquer segmento de rede no escopo.

Solução de Problemas e Mitigação de Riscos

Modos de Falha Comuns Durante o Endurecimento (Hardening)

O problema mais frequente encontrado ao impor o Message-Authenticator é a incompatibilidade de dispositivos legados. Pontos de acesso mais antigos, switches ou concentradores VPN podem não suportar o atributo, causando falhas de autenticação após o servidor ser configurado para exigi-lo. A abordagem recomendada é auditar todos os clientes RADIUS antes de impor o requisito no lado do servidor e manter uma lista de dispositivos que exigem atualizações de firmware ou substituição.

Um segundo problema comum são as falhas de validação de certificado durante a migração EAP-TLS. Se os dispositivos clientes não forem provisionados com a âncora de confiança do certificado do servidor RADIUS correta, eles rejeitarão o certificado do servidor e falharão na autenticação. Isso é particularmente comum em ambientes BYOD. A implantação de uma solução de Gerenciamento de Dispositivos Móveis (MDM) para enviar perfis de certificado é a resolução padrão.

Incompatibilidades de segredo compartilhado podem ocorrer durante a migração RADSEC se o Common Name do certificado TLS não corresponder ao identificador de cliente esperado. Certifique-se de que os nomes de assunto do certificado sejam consistentes com os endereços IP ou nomes de host do cliente RADIUS configurados no servidor.

Mitigação de Riscos para Ambientes que Não Podem Aplicar Patches Imediatamente

Para ambientes onde a aplicação imediata de patches não é viável — como sistemas de controle industrial legados ou dispositivos de rede incorporados —, o risco pode ser parcialmente mitigado implementando controles rígidos de acesso à rede que limitem quais hosts podem se comunicar com o servidor RADIUS, reduzindo a oportunidade de um invasor MitM interceptar o tráfego. Esta é apenas uma medida temporária; um roteiro de aplicação de patches e substituição deve ser estabelecido.

ROI e Impacto nos Negócios

Quantificando o Risco

The business case for RADIUS hardening is straightforward when framed in terms of breach cost and compliance liability. A successful Blast-RADIUS exploit in a hotel or retail environment could provide an attacker with access to the corporate network, potentially reaching point-of-sale systems, guest data repositories, and back-office infrastructure. The average cost of a data breach in the hospitality sector exceeds £3 million, according to industry benchmarks, with regulatory fines under GDPR potentially adding up to 4% of global annual turnover.

For organisations in scope for PCI DSS, a network authentication failure that results in cardholder data exposure can trigger mandatory forensic investigations, card brand fines, and potential loss of card processing privileges — costs that far exceed the investment required to implement EAP-TLS and RADSEC.

Implementation Cost Benchmarks

The following table provides indicative cost and effort estimates for the three-phase hardening roadmap across typical venue environments:

Operational Benefits Beyond Security

Migrating to EAP-TLS and RADSEC delivers operational benefits beyond security hardening. Certificate-based authentication eliminates the operational overhead of managing and rotating shared passwords across large device fleets. WPA3-Enterprise improves connection reliability in dense environments — a measurable benefit for stadiums and conference centres where hundreds of devices compete for authentication. RADSEC's TCP transport also provides better reliability than UDP in high-latency or lossy network conditions, improving the authentication experience for end users.