Atenuar Vulnerabilidades de RADIUS: Um Guia de Reforço de Segurança
Este guia fornece uma referência abrangente e prática para gestores de TI, arquitetos de rede e CTOs responsáveis pela infraestrutura de WiFi empresarial nos setores da hotelaria, retalho, eventos e setor público. Abrange toda a superfície de ataque das implementações de servidores RADIUS — desde vulnerabilidades de colisão MD5 e segredos partilhados fracos até transporte UDP não encriptado e métodos EAP incorretamente configurados — e apresenta um roteiro de reforço prioritário alinhado com os requisitos IEEE 802.1X, PCI DSS e GDPR. As organizações que implementarem estas recomendações irão reduzir materialmente a sua exposição a ataques de rede baseados em credenciais, cumprir as obrigações de conformidade e construir uma postura de segurança defensável para a sua infraestrutura de WiFi corporativa e de convidados.
Ouça este guia
Ver transcrição do podcast
Resumo Executivo
O RADIUS (Remote Authentication Dial-In User Service) continua a ser o protocolo dominante para o controlo de acessos à rede em implementações de WiFi empresariais, servindo de base para a autenticação IEEE 802.1X em hotéis, superfícies comerciais, estádios, centros de conferências e edifícios do setor público. No entanto, o RADIUS foi concebido na década de 1990 e várias das suas decisões de design fundamentais — a dependência de hashing MD5, o transporte UDP sem encriptação nativa e segredos partilhados estáticos — tornaram-se vulnerabilidades materiais no atual panorama de ameaças.
Em julho de 2024, a vulnerabilidade BlastRADIUS (CVE-2024-3596) demonstrou que um atacante do tipo "man-in-the-middle" consegue forjar respostas RADIUS Access-Accept ao explorar a fragilidade de integridade do MD5 em pacotes Access-Request. Isto afeta todas as principais implementações de RADIUS, incluindo FreeRADIUS, Cisco ISE e Microsoft NPS. As implementações sem patch aplicado continuam expostas.
Este guia fornece um roteiro de reforço de segurança prioritário que abrange a gestão de patches, a higiene de segredos partilhados, a seleção de métodos EAP, a implementação de RadSec, a autenticação multifator para acesso administrativo e a integração de SIEM para deteção de anomalias. Foi escrito para o profissional de TI que precisa de tomar uma decisão defensável neste trimestre, e não no próximo ano.
Análise Técnica Detalhada
Como Funciona o RADIUS e Onde Falha
O RADIUS opera como um protocolo cliente-servidor entre um Network Access Server (NAS) — tipicamente um ponto de acesso WiFi, switch ou concentrador VPN — e um servidor RADIUS que valida as credenciais num repositório de identidades backend, como o Active Directory ou LDAP. A troca de autenticação segue um modelo de pedido-desafio-resposta definido no RFC 2865, com a faturação (accounting) a ser tratada separadamente ao abrigo do RFC 2866.
O protocolo transmite pacotes de autenticação através de UDP, porta 1812 para autenticação e porta 1813 para faturação. O segredo partilhado — uma chave pré-partilhada configurada tanto no NAS como no servidor RADIUS — é utilizado para gerar o campo Response Authenticator e para ofuscar o atributo User-Password através de uma cifra XOR baseada em MD5. Isto não é encriptação no sentido moderno; é ofuscação e depende inteiramente do segredo e da robustez do segredo partilhado.
As cinco principais classes de vulnerabilidade numa implementação típica de RADIUS são as seguintes.
Vulnerabilidades de Integridade e Colisão MD5. O ataque BlastRADIUS (CVE-2024-3596) explora a ausência de proteção de integridade nos pacotes Access-Request. Como o NAS não inclui um atributo Message-Authenticator por predefinição em muitas configurações, um atacante posicionado como man-in-the-middle pode injetar um atributo manipulado no pacote antes que este chegue ao servidor RADIUS. Ao explorar técnicas de colisão de prefixo escolhido em MD5, o atacante pode manipular o pacote de modo a que o servidor RADIUS calcule um Response Authenticator válido para o pacote modificado, devolvendo um Access-Accept para um pedido que deveria ter sido rejeitado. A mitigação consiste em impor o atributo Message-Authenticator em todos os pacotes Access-Request, o que fornece proteção de integridade HMAC-MD5 sobre a totalidade do pacote. Trata-se de uma alteração de configuração tanto no NAS como no servidor RADIUS, e não apenas de um patch de servidor.
Segredos Partilhados Fracos ou Estáticos. O segredo partilhado é a âncora criptográfica da troca RADIUS. Se for curto, adivinhável ou não tiver sido rodado, um atacante que capture o tráfego RADIUS — viável através de ARP spoofing ou de um dispositivo de rede comprometido — pode realizar um ataque de força bruta offline contra o atributo User-Password. As diretrizes da norma NIST SP 800-63B sobre segredos memorizados aplicam-se aqui: os segredos devem ter um mínimo de 20 caracteres, ser gerados aleatoriamente e ser armazenados num sistema de gestão de segredos. Para infraestruturas de grande dimensão com dezenas ou centenas de dispositivos NAS, a rotação manual é operacionalmente inviável; a automatização através do HashiCorp Vault ou de um gestor de segredos comparável é a abordagem correta.
Transporte UDP Não Encriptado. O RADIUS padrão sobre UDP não oferece confidencialidade na camada de transporte. O atributo User-Password é ofuscado, mas não encriptado. Todos os outros atributos — incluindo o nome de utilizador, o IP do NAS e os metadados da sessão — são transmitidos em texto simples. O RadSec (RADIUS sobre TLS), definido no RFC 6614 e atualizado no RFC 7360, resolve este problema ao encapsular o protocolo RADIUS numa sessão TLS 1.2 ou TLS 1.3 sobre a porta TCP 2083. O RadSec fornece autenticação mútua por certificado entre o NAS e o servidor RADIUS, encriptação total do payload e proteção contra ataques de repetição. É o transporte correto para qualquer tráfego RADIUS que atravesse uma fronteira de rede não confiável.
Seleção do Método EAP. O Extensible Authentication Protocol (EAP) define o método de autenticação interno utilizado na estrutura 802.1X. O EAP-MD5 foi descontinuado e deve ser removido de todas as implementações imediatamente — não fornece autenticação mútua nem proteção contra a recolha de credenciais. O PEAP (Protected EAP) e o EAP-TTLS estabelecem um túnel TLS utilizando um certificado de servidor antes de transmitir as credenciais, fornecendo autenticação mútua e protegendo o método interno contra a espionagem. O EAP-TLS elimina totalmente as palavras-passe, exigindo que tanto o servidor como o cliente apresentem certificados X.509. É imune a ataques de phishing e de força bruta, sendo o método recomendado para ambientes de alta segurança.
Registo e Monitorização Insuficientes. O registo de atividade (accounting) RADIUS regista todos os eventos de autenticação — sucesso, falha, início de sessão, fim de sessão. Estes dados são operacionalmente valiosos para o planeamento de capacidade e comercialmente valiosos para WiFi Analytics , mas são também uma fonte crítica de telemetria de segurança. Picos de falhas de autenticação, autenticações a partir de endereços MAC inesperados e padrões de acesso fora de horas são todos detetáveis a partir dos registos de atividade RADIUS. A maioria das organizações não está a integrar estes dados num SIEM, e as que o fazem, frequentemente não têm limiares de alerta configurados.
O Ataque BlastRADIUS em Detalhe
O BlastRADIUS foi divulgado em julho de 2024 por investigadores da Universidade de Boston e da Universidade da Califórnia em San Diego. O ataque requer uma posição de man-in-the-middle entre o NAS e o servidor RADIUS — realizável através de envenenamento ARP num segmento de rede partilhado, um router comprometido ou um utilizador interno malicioso com acesso à rede.
O ataque processa-se da seguinte forma: o atacante interpeta um pacote Access-Request do NAS. Como o pacote carece de um atributo Message-Authenticator (o padrão em muitas configurações), o atacante tem a liberdade de modificar a lista de atributos do pacote. Utilizando uma colisão de prefixo escolhido em MD5, o atacante cria um pacote modificado que, quando processado pelo servidor RADIUS, produz o mesmo Response Authenticator que o pacote original produziria. O servidor, portanto, devolve um Access-Accept para um pedido que contém atributos controlados pelo atacante — incluindo um Service-Type de Administrative, que concede acesso total à rede.
O ataque é viável contra implementações PEAP e EAP-TTLS onde o método interno utiliza MSCHAPv2. Não afeta implementações EAP-TLS, porque a autenticação mútua baseada em certificados fornece uma proteção de integridade que o MD5 não consegue comprometer.
Para organizações que executam Guest WiFi em conjunto com o 802.1X corporativo, a instância RADIUS da rede de convidados também deve ser corrigida, mesmo que utilize MAC Authentication Bypass em vez de EAP. A higiene do segredo partilhado e os requisitos do Message-Authenticator aplicam-se de igual forma.
Guia de Implementação
Fase 1: Remediação Imediata (Semanas 1–2)
A primeira prioridade é a aplicação de patches. O FreeRADIUS 3.2.5 e o 3.0.27 incluem a correção para o BlastRADIUS e impõem o Message-Authenticator por predefinição. O Cisco ISE 3.1 Patch 8, 3.2 Patch 4 e 3.3 Patch 1 abordam a vulnerabilidade. A Microsoft lançou o KB5040434 para o Windows Server 2022 NPS em julho de 2024. Verifique as suas versões atuais e aplique os patches na sua próxima janela de alteração agendada.
Simultaneamente, audite o firmware dos seus dispositivos NAS. A imposição do Message-Authenticator só é eficaz se o NAS também enviar o atributo. Verifique os avisos de segurança dos fabricantes dos seus pontos de acesso e switches — a Aruba, Ruckus, Cisco e Juniper lançaram atualizações de firmware que abordam o BlastRADIUS. Se utiliza hardware Ruckus, o wireless access point Ruckus guide fornece o contexto relevante para a gestão de firmware.
Para a resolução de problemas em Troubleshooting Windows 11 802.1X Authentication Issues que possam surgir após a aplicação do patch, a causa mais comum é o servidor NPS rejeitar ligações de clientes que não incluem o Message-Authenticator — um comportamento de segurança correto que pode exigir a reconfiguração do suplicante em clientes Windows mais antigos.
Fase 2: Higiene do Segredo Partilhado (Semanas 2–4)
Exporte a lista completa de clientes NAS registados no seu servidor RADIUS. Para cada entrada, registe o comprimento do segredo partilhado e a data da última alteração. Qualquer segredo com menos de 20 caracteres ou inalterado há mais de 24 meses deve ser rodado imediatamente.
Para novos segredos, utilize um gerador criptograficamente aleatório — openssl rand -base64 32 produz uma string base64 de 44 caracteres adequada para utilização como segredo partilhado RADIUS. Armazene todos os segredos num sistema de gestão de segredos. Implemente um calendário de rotação: anualmente para dispositivos NAS de baixo risco, a cada seis meses para dispositivos NAS no âmbito do PCI DSS.
Fase 3: Racionalização do Método EAP (Meses 1–2)
Audite os métodos EAP permitidos no seu servidor RADIUS. Desative o EAP-MD5. Se estiver a executar PEAP-MSCHAPv2, verifique se a validação do certificado do servidor é imposta em todos os suplicantes — um suplicante mal configurado que aceite qualquer certificado de servidor é vulnerável a ataques de servidores RADIUS falsos. Para ambientes no âmbito do PCI DSS, o EAP-TLS é o caminho recomendado. Inicie o planeamento de PKI se não possuir uma infraestrutura de certificados existente.
Para a segurança em Securing Guest WiFi Networks , note que as redes de convidados utilizam normalmente autenticação por Captive Portal em vez de 802.1X, pelo que o reforço do método EAP se aplica principalmente a SSIDs corporativos e de colaboradores.
Fase 4: Implementação de RadSec (Meses 2–3)
Identifique todos os caminhos de tráfego RADIUS que cruzam limites de rede não confiáveis. Os cenários comuns incluem: um servidor RADIUS central que atende propriedades hoteleiras remotas através da internet; um serviço RADIUS alojado na nuvem acedido por dispositivos NAS locais; e cadeias de proxy RADIUS onde o tráfego passa por múltiplos domínios de rede.
Para cada caminho identificado, configure o RadSec. No FreeRADIUS, isto requer a ativação do listener tls na porta 2083 e a configuração de TLS mútuo com certificados da sua PKI. No Cisco ISE, o RadSec é configurado em Administration > Network Devices. Garanta que o TLS 1.2 é a versão mínima; desative explicitamente o TLS 1.0 e 1.1.
Fase 5: MFA para Acesso Administrativo (Mês 2–3)
A interface de gestão do servidor RADIUS é um alvo de alto valor. Um atacante que comprometa o servidor RADIUS pode modificar políticas de autenticação, extrair segredos partilhados e redirecionar o tráfego de autenticação. Imponha MFA para todos os inícios de sessão administrativos no servidor RADIUS e no seu sistema operativo subjacente. Restrinja o acesso de gestão a uma VLAN de gestão dedicada fora de banda (out-of-band). Implemente o controlo de acessos baseado em funções: os engenheiros de rede não devem ter os mesmos privilégios que os administradores de segurança.
Fase 6: Integração com SIEM e Alertas (Mês 3–4)
Configure o seu servidor RADIUS para encaminhar os registos de accounting para o seu SIEM em tempo real. Defina os seguintes limites de alerta como base de referência:
| Alerta | Limite | Gravidade |
|---|---|---|
| Falhas de autenticação de um único MAC | >5 em 60 segundos | Alta |
| Pico na taxa de Access-Reject | >200% da base de referência de 7 dias | Média |
| Autenticação de novo MAC no SSID corporativo | Primeira ocorrência | Média |
| Expiração do certificado do servidor RADIUS | 90 / 30 / 7 dias | Alta / Crítica / Crítica |
| Erros de incompatibilidade de segredo partilhado | Qualquer ocorrência | Alta |
Boas Práticas
As seguintes recomendações representam o consenso do IEEE 802.1X, NIST SP 800-63B, PCI DSS v4.0 e avisos de segurança dos fabricantes.
Gestão de Certificados. Qualquer implementação que utilize EAP-TLS ou RadSec possui certificados X.509 no caminho de autenticação. A expiração de certificados é a causa individual mais comum de falhas de autenticação súbitas e totais em implementações de WiFi empresariais. Implemente a gestão automatizada do ciclo de vida dos certificados. Defina alertas de monitorização para 90, 30 e 7 dias antes da expiração. Para certificados de servidor RADIUS, utilize um tamanho mínimo de chave de RSA de 2048 bits ou ECDSA de 256 bits, com algoritmos de assinatura SHA-256 ou superior. Não utilize SHA-1.
Segmentação de Rede. O servidor RADIUS deve residir num segmento de rede de gestão dedicado, isolado tanto da rede de convidados como da rede corporativa geral. O acesso às portas RADIUS (UDP 1812, 1813, TCP 2083 para RadSec) deve ser restringido por ACL de firewall aos endereços IP específicos dos dispositivos NAS registados. Sem acesso direto da internet às portas RADIUS. Redundância e Alta Disponibilidade. Um único servidor RADIUS é um ponto único de falha para toda a sua infraestrutura de controlo de acesso à rede. Implemente no mínimo dois servidores RADIUS numa configuração ativo-passivo ou ativo-ativo. Para implementações em Hospitalidade com requisitos de conectividade de hóspedes 24/7, o tempo de inatividade do servidor RADIUS é diretamente equivalente ao tempo de inatividade do WiFi dos hóspedes — um risco reputacional e comercial.
WPA3 e 802.1X. O WPA3-Enterprise exige a utilização do modo de segurança de 192 bits para implementações governamentais e de alta segurança, exigindo AES-256-GCMP para encriptação de dados e HMAC-SHA-384 para autenticação. Para a maioria das implementações empresariais, o WPA3-Enterprise com segurança padrão de 128 bits é uma melhoria significativa em relação ao WPA2-Enterprise, particularmente em combinação com EAP-TLS. Os ambientes de Retalho que processam pagamentos com cartão devem tratar a adoção do WPA3-Enterprise como uma medida de redução de risco PCI DSS.
Cadência de Patches do Fornecedor. Subscreva os avisos de segurança do seu fornecedor de servidores RADIUS e dos seus fornecedores de dispositivos NAS. O FreeRADIUS, a Cisco, a Microsoft, a Aruba e a Ruckus publicam notificações CVE. Integre-as no seu programa de gestão de vulnerabilidades com um SLA definido: vulnerabilidades críticas (CVSS ≥ 9.0) corrigidas em 72 horas; vulnerabilidades elevadas (CVSS 7.0–8.9) em 14 dias.
Resolução de Problemas e Mitigação de Riscos
Modos de Falha Comuns
Falhas de Autenticação Pós-Patch. Após a aplicação de patches BlastRADIUS, alguns dispositivos NAS podem falhar na autenticação se o seu firmware não suportar o Message-Authenticator. Sintomas: aumento súbito nas respostas Access-Reject sem alteração nas credenciais do utilizador. Diagnóstico: ative o registo de depuração (debug) do RADIUS e verifique se existem erros de "Message-Authenticator required but not present". Resolução: atualize o firmware do NAS ou, como medida temporária, configure o servidor RADIUS para aceitar pedidos sem Message-Authenticator de IPs NAS específicos enquanto as atualizações de firmware são agendadas.
Falhas de Validação de Certificados em EAP-TLS. Sintomas: os clientes recebem "Falha na Autenticação" sem o correspondente Access-Reject nos registos do RADIUS. Diagnóstico: verifique a cadeia de certificados do servidor RADIUS — a CA emissora é fidedigna para o suplicante do cliente? O certificado do servidor está dentro do seu período de validade? Resolução: garanta que a cadeia de certificados completa (folha + intermédio + raiz) está configurada no servidor RADIUS. Distribua o certificado da CA raiz para os dispositivos dos clientes via MDM ou Política de Grupo (Group Policy).
Falhas no Handshake TLS do RadSec. Sintomas: os dispositivos NAS falham no estabelecimento de ligações RadSec após alteração de configuração. Diagnóstico: verifique a compatibilidade da versão TLS — o firmware NAS mais antigo pode não suportar TLS 1.2. Verifique a autenticação mútua de certificados — ambas as extremidades devem confiar na CA uma da outra. Resolução: verifique o suporte da versão TLS nas notas de lançamento do firmware do NAS; garanta que os certificados dos dispositivos NAS são emitidos pela mesma CA fidedigna pelo servidor RADIUS. Incompatibilidade de Shared Secret. Sintomas: todas as autenticações de um NAS específico falham com erros de "Invalid authenticator". Diagnóstico: incompatibilidade de shared secret entre a configuração do NAS e o registo de cliente do servidor RADIUS. Resolução: reintroduza o shared secret em ambos os lados, garantindo que não existem espaços no final ou problemas de codificação de caracteres. Utilize copiar-colar a partir de um gestor de segredos para evitar erros de transcrição.
Registo de Riscos
| Risco | Probabilidade | Impacto | Controlo de Mitigação |
|---|---|---|---|
| Exploração de BlastRADIUS | Alta (sem patch) | Crítico | Patch + aplicação de Message-Authenticator |
| Força bruta de shared secret | Média | Alto | Segredos aleatórios de 32 carateres, rotação anual |
| Servidor RADIUS não autorizado | Média | Alto | Autenticação mútua EAP-TLS, pinning de certificado |
| Expiração do certificado do servidor RADIUS | Alta | Crítico | Monitorização automatizada, alertas de 90 dias |
| Credential stuffing via 802.1X | Média | Alto | Políticas de bloqueio de conta, alertas de SIEM |
| Compromisso do servidor RADIUS | Baixa | Crítico | MFA para acesso de administrador, segmentação de rede |
ROI e Impacto no Negócio
Quantificar o Risco
A justificação financeira para o reforço de segurança do RADIUS é simples quando enquadrada face aos custos de uma violação de dados. O custo médio de uma violação de dados no Reino Unido em 2024 foi de £3,58 milhões, incluindo coimas regulamentares, remediação, custos legais e danos na reputação. Para as organizações no âmbito do PCI DSS — o que inclui praticamente todos os operadores de Retalho e Hotelaria que processam pagamentos com cartão através de WiFi —, uma violação do controlo de acesso à rede que exponha dados de titulares de cartões desencadeia uma investigação forense obrigatória, potenciais coimas das marcas de cartões e a eventual suspensão dos privilégios de processamento de cartões.
Para as organizações de Saúde , uma violação do GDPR que envolva dados de doentes acedidos através de um servidor RADIUS comprometido acarreta coimas de até 4% do volume de negócios anual global ao abrigo do Artigo 83.º, n.º 5. O historial de aplicação de sanções do ICO demonstra que as falhas de segurança de rede são tratadas como negligência e não como acidentes técnicos.
Referências de Custos de Implementação
As seguintes estimativas de custos são indicativas para uma infraestrutura empresarial de 500 dispositivos:
| Atividade de Reforço de Segurança | Custo Estimado | Calendário |
|---|---|---|
| Aplicação de patches (FreeRADIUS / NPS / ISE) | Apenas mão de obra interna | 1–2 semanas |
| Auditoria e rotação de shared secrets | Mão de obra interna + licença de gestor de segredos (~£2.000/ano) | 2–4 semanas |
| Implementação de PKI EAP-TLS | £15.000–£30.000 (ferramentas + serviços profissionais) | 2–3 meses |
| Implementação de RadSec | Mão de obra interna + custos de certificados (~£1.500) | 4–6 semanas |
| Integração e alertas de SIEM | Dependente do SIEM existente; £0–£10.000 | 4–8 semanas |
Investimento total de reforço de segurança para uma infraestrutura de média dimensão: aproximadamente £20.000–£45.000. Face a uma base de custo de violação de dados de £3,58 milhões, o ROI ajustado ao risco é convincente, mesmo com estimativas baixas de probabilidade de violação.
Benefícios Operacionais Além da Segurança
Uma infraestrutura RADIUS robustecida também oferece benefícios operacionais. Uma autenticação fiável e bem monitorizada reduz os pedidos de suporte relacionados com a conectividade WiFi. Os dados de contabilização RADIUS, quando integrados com o WiFi Analytics , proporcionam visibilidade ao nível da sessão sobre os padrões de utilização da rede, tempos de permanência e tipos de dispositivos — dados que têm valor comercial direto para os operadores de espaços nos setores de Hospitality e Transport .
Para as organizações do setor público e de Healthcare , um programa documentado de robustecimento do RADIUS fornece provas de controlos técnicos para as avaliações Cyber Essentials Plus, ISO 27001 e NHS DSPT — reduzindo a carga de auditoria e demonstrando a devida diligência perante os reguladores.
Definições Principais
RADIUS (Remote Authentication Dial-In User Service)
Um protocolo cliente-servidor definido no RFC 2865 que fornece autenticação, autorização e contabilização (AAA) centralizadas para acesso à rede. Os servidores RADIUS validam as credenciais submetidas por dispositivos de rede (NAS) contra um repositório de identidades backend, como o Active Directory ou LDAP.
As equipas de TI deparam-se com o RADIUS como o backend de autenticação para WiFi 802.1X, autenticação de portas com fios, acesso VPN e gestão de dispositivos de rede. É o protocolo que decide quem acede à rede.
IEEE 802.1X
Uma norma IEEE para controlo de acesso à rede baseado em portas que define a encapsulação de EAP sobre LAN (EAPOL). Fornece uma estrutura de autenticação para redes com e sem fios, exigindo que os dispositivos se autentiquem antes de lhes ser concedido acesso à rede.
O 802.1X é a norma que faz funcionar a autenticação WiFi empresarial. Quando um colaborador se liga a um SSID corporativo e lhe são solicitadas credenciais, o 802.1X é a estrutura que orquestra essa troca, com o RADIUS como backend.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Um método EAP que utiliza certificados X.509 para autenticação mútua entre o cliente e o servidor RADIUS. Ambas as partes devem apresentar certificados válidos, eliminando totalmente as palavras-passe da troca de autenticação.
O EAP-TLS é o padrão de excelência para a autenticação WiFi empresarial. É imune a phishing de credenciais e a ataques de força bruta. O requisito operacional é uma infraestrutura PKI para emitir e gerir certificados de cliente.
RadSec (RADIUS over TLS)
Um protocolo definido no RFC 6614 que encapsula pacotes RADIUS dentro de uma sessão TLS sobre a porta TCP 2083. Fornece encriptação na camada de transporte, autenticação mútua de certificados e proteção contra ataques de repetição para o tráfego RADIUS.
O RadSec é necessário para qualquer tráfego RADIUS que atravesse uma fronteira de rede não confiável — ligações WAN, ligações à Internet ou infraestruturas de rede partilhadas. É o substituto correto para o RADIUS padrão sobre UDP em implementações multi-site.
BlastRADIUS (CVE-2024-3596)
Um ataque man-in-the-middle divulgado em julho de 2024 que explora a ausência de proteção de integridade nos pacotes Access-Request do RADIUS. Utilizando técnicas de colisão de prefixo escolhido em MD5, um atacante pode forjar uma resposta Access-Accept, concedendo acesso à rede a um utilizador não autenticado.
O BlastRADIUS afeta todas as principais implementações de RADIUS, incluindo FreeRADIUS, Cisco ISE e Microsoft NPS. As organizações que não aplicaram as correções lançadas em julho de 2024 continuam expostas a este ataque.
Message-Authenticator
Um atributo RADIUS (Atributo 80) que fornece proteção de integridade HMAC-MD5 sobre todo o pacote RADIUS. Quando presente num Access-Request, impede o ataque de modificação de pacotes utilizado no BlastRADIUS.
Impor o Message-Authenticator em todos os pacotes Access-Request é a principal mitigação para o BlastRADIUS. Deve ser configurado tanto no servidor RADIUS (para exigir o atributo) como no dispositivo NAS (para incluir o atributo nos pedidos).
NAS (Network Access Server)
Na terminologia RADIUS, o NAS é o dispositivo de rede — normalmente um ponto de acesso WiFi, switch ou concentrador VPN — que atua como o cliente RADIUS. Interceta os pedidos de ligação dos dispositivos finais e encaminha os pedidos de autenticação para o servidor RADIUS.
Os dispositivos NAS são os clientes RADIUS numa implementação. Os segredos partilhados são configurados por NAS. A mitigação do BlastRADIUS requer atualizações de firmware nos dispositivos NAS, bem como correções no servidor RADIUS.
PEAP (Protected Extensible Authentication Protocol)
Um método EAP que estabelece um túnel TLS utilizando um certificado do lado do servidor antes de transmitir o método de autenticação interno (normalmente MSCHAPv2). Fornece autenticação mútua e protege as credenciais contra a interceção de tráfego.
O PEAP-MSCHAPv2 é o método de autenticação WiFi empresarial mais amplamente implementado. Está em conformidade com o PCI DSS e é operacionalmente mais simples do que o EAP-TLS porque não requer certificados de cliente. No entanto, é vulnerável a ataques de servidores RADIUS falsos se a validação de certificados do lado do cliente não for imposta.
Shared Secret
Uma chave pré-partilhada configurada tanto no servidor RADIUS como em cada dispositivo NAS. É utilizada para gerar o campo Response Authenticator e para ofuscar o atributo User-Password. Não é uma palavra-passe para utilizadores finais — é uma credencial de autenticação servidor-a-servidor.
Segredos partilhados fracos ou estáticos são uma das vulnerabilidades mais comuns do RADIUS. Um atacante que capture tráfego RADIUS pode realizar um ataque de força bruta offline contra um segredo partilhado fraco. O comprimento mínimo recomendado é de 32 caracteres, gerados aleatoriamente.
PCI DSS (Payment Card Industry Data Security Standard)
Um conjunto de normas de segurança exigido pelas principais marcas de cartões (Visa, Mastercard, Amex) para organizações que processam, armazenam ou transmitem dados de titulares de cartões. A Versão 4.0, em vigor a partir de março de 2024, inclui requisitos específicos para controlo de acesso à rede e autenticação forte.
As organizações de retalho e hotelaria com terminais de pagamento (POS) ligados por WiFi estão no âmbito do PCI DSS. As vulnerabilidades do servidor RADIUS que possam permitir o acesso não autorizado à rede a ambientes de dados de titulares de cartões representam um risco direto de conformidade.
Exemplos Práticos
Um grupo hoteleiro de 12 propriedades com 350 quartos utiliza um servidor RADIUS centralizado alojado no centro de dados da sua sede. Cada propriedade liga-se através de uma WAN MPLS partilhada. Uma auditoria de segurança sinalizou que o tráfego RADIUS não é encriptado através da WAN, os segredos partilhados são strings de 8 caracteres definidos durante a implementação inicial há cinco anos, e o servidor RADIUS está a executar o FreeRADIUS 3.0.21. O grupo processa pagamentos com cartão através de terminais POS ligados por WiFi nas suas instalações de restaurante e spa. Qual é a prioridade de remediação e a sequência de implementação?
A sequência de remediação deve ser ordenada pela gravidade do risco e pela velocidade de implementação. Passo 1 (imediato, num prazo de 72 horas): Aplicar patch no FreeRADIUS para a versão 3.2.5 ou 3.0.27. Isto resolve a vulnerabilidade BlastRADIUS e força o Message-Authenticator por predefinição. Simultaneamente, verificar as versões de firmware dos pontos de acesso em todas as 12 propriedades e agendar atualizações de firmware para quaisquer dispositivos NAS que não suportem o Message-Authenticator. Passo 2 (semana 1–2): Rodar todos os segredos partilhados. Gerar segredos aleatórios de 32 caracteres utilizando openssl rand -base64 32 para cada um dos registos NAS das 12 propriedades. Armazenar no HashiCorp Vault ou equivalente. Documentar a data de rotação. Passo 3 (mês 1–2): Implementar RadSec no caminho da WAN. Configurar o servidor FreeRADIUS para aceitar ligações RadSec em TCP 2083. Emitir certificados TLS de uma CA interna para os dispositivos NAS de cada propriedade. Atualizar as regras de firewall para permitir TCP 2083 a partir das gamas de IP dos NAS das propriedades para o servidor RADIUS. Desativar UDP 1812/1813 das interfaces expostas à WAN assim que o funcionamento do RadSec for confirmado. Passo 4 (mês 2–3): Para o SSID de WiFi dos POS abrangido pelo PCI DSS, migrar de PEAP-MSCHAPv2 para EAP-TLS. Implementar uma PKI interna (Microsoft ADCS ou motor PKI do HashiCorp Vault). Emitir certificados de cliente para os terminais POS via MDM. Atualizar a política do RADIUS para exigir EAP-TLS para o SSID dos POS. Passo 5 (mês 3): Integrar os registos de accounting do RADIUS no SIEM. Configurar alertas para picos de falhas de autenticação e expiração de certificados.
Uma cadeia de retalho regional com 45 lojas utiliza WPA2-Personal (chave pré-partilhada) para o WiFi dos funcionários e uma rede aberta para o WiFi dos clientes. O diretor de TI pretende migrar o WiFi dos funcionários para autenticação 802.1X utilizando o Microsoft NPS como servidor RADIUS, integrado com o Active Directory. As lojas têm uma mistura de pontos de acesso Aruba e Cisco. A cadeia está no âmbito do PCI DSS. Que arquitetura devem implementar e quais são as principais decisões de configuração?
A arquitetura recomendada é o 802.1X com PEAP-MSCHAPv2 como método EAP inicial, com um roteiro documentado para EAP-TLS. O servidor NPS deve ser implementado num par redundante (primário + secundário) no centro de dados central, com configuração de proxy RADIUS nos pontos de acesso para failover automático. Decisões de configuração: (1) Política de Rede NPS: criar uma política correspondente ao SSID dos funcionários com PEAP-MSCHAPv2, exigindo a pertença a um grupo de segurança do AD (por exemplo, 'WiFi-Staff-Access'). Definir o tempo limite da sessão para 8 horas para forçar a reautenticação. (2) Certificado: implementar um certificado de servidor NPS a partir de uma CA interna do Microsoft ADCS. Distribuir o certificado da CA raiz para todos os dispositivos dos funcionários via Política de Grupo (Windows) e MDM (iOS/Android). (3) Configuração do suplicante: configurar os dispositivos Windows via Política de Grupo (Configuração do Computador > Definições do Windows > Definições de Segurança > Políticas de Rede Sem Fios). Para dispositivos iOS e Android, utilizar um perfil MDM. Impor a validação do certificado do servidor — não permitir que os utilizadores aceitem certificados arbitrários. (4) Configuração do ponto de acesso: em Aruba, configurar o servidor RADIUS em Autenticação > Servidores. Definir o segredo partilhado para uma string aleatória de 32 caracteres. Ativar o RadSec se o firmware Aruba o suportar (AOS 8.9+). Em Cisco, configurar em Segurança > AAA > RADIUS. (5) Registo NPS: ativar o registo de accounting do NPS para uma base de dados SQL Server. Configurar um período de retenção de registos de, no mínimo, 90 dias para conformidade com o PCI DSS. (6) Pós-migração: desativar o WPA2-Personal no SSID dos funcionários. Mantê-lo apenas como um SSID de emergência com uma PSK complexa armazenada no gestor de segredos, para utilização exclusiva quando o NPS estiver indisponível.
Perguntas de Prática
Q1. A sua organização gere um servidor FreeRADIUS 3.0.21 que suporta autenticação 802.1X para 800 dispositivos de funcionários num campus de local único. O servidor RADIUS está na mesma VLAN de gestão que todos os pontos de acesso. Um teste de intrusão identificou que os pontos de acesso estão a enviar pacotes Access-Request sem o atributo Message-Authenticator. A equipa de segurança quer impor o Message-Authenticator imediatamente, mas a equipa de operações de rede está preocupada em interromper a autenticação de 800 utilizadores. Como deve sequenciar a remediação para minimizar a interrupção do serviço?
Dica: Considere a diferença entre o servidor RADIUS exigir o Message-Authenticator e os dispositivos NAS o enviarem. Estas são duas alterações de configuração distintas com perfis de risco diferentes.
Ver resposta modelo
A sequência correta é: (1) Primeiro, atualize o FreeRADIUS para a versão 3.2.5. Esta versão impõe o Message-Authenticator por predefinição, mas inclui um modo de compatibilidade que regista um aviso em vez de rejeitar pacotes que não tenham o atributo. Isto permite aplicar a correção sem interromper imediatamente a autenticação. (2) Audite as versões de firmware dos pontos de acesso. Identifique quais os modelos e versões de firmware que suportam Message-Authenticator em pacotes Access-Request. (3) Atualize o firmware dos pontos de acesso em lotes, começando com um grupo piloto de 50 dispositivos. Verifique se a autenticação continua a funcionar após cada lote. (4) Assim que estiver confirmado que todos os pontos de acesso estão a enviar o Message-Authenticator, ative a imposição estrita no servidor FreeRADIUS (require_message_authenticator = yes em clients.conf). (5) Monitorize os registos do RADIUS para detetar quaisquer avisos restantes de 'Message-Authenticator em falta', o que indicaria dispositivos NAS que não receberam a atualização de firmware. O princípio fundamental é que pode atualizar o servidor primeiro sem quebrar nada, porque o modo de compatibilidade permite um período de transição. Impor a rejeição estrita no servidor deve ser o último passo, após a atualização de todos os dispositivos NAS.
Q2. O operador de um centro de conferências gere um único servidor RADIUS que suporta tanto o SSID corporativo dos funcionários (802.1X com PEAP-MSCHAPv2) como o WiFi de convidados de eventos (Captive Portal com MAC Authentication Bypass). O gestor de TI pergunta se a instância RADIUS do WiFi de convidados precisa de ser protegida com o mesmo nível de exigência que a instância RADIUS corporativa, dado que os convidados não se autenticam com credenciais corporativas. Qual é a sua recomendação?
Dica: Considere os vetores de ataque que se aplicam ao MAC Authentication Bypass versus autenticação baseada em EAP, e o risco de movimento lateral entre as instâncias de RADIUS de convidados e corporativa.
Ver resposta modelo
A instância RADIUS do WiFi de convidados requer proteção, mas os controlos específicos diferem da instância corporativa. A correção BlastRADIUS aplica-se de igual forma — a vulnerabilidade afeta o servidor RADIUS independentemente do método de autenticação utilizado pelos clientes. A higiene do segredo partilhado aplica-se de igual forma — um segredo partilhado fraco entre o controlador do Captive Portal de convidados e o servidor RADIUS é explorável independentemente de o EAP estar ou não em uso. O principal risco adicional é o servidor RADIUS partilhado: se os pedidos de autenticação do SSID de convidados e corporativo forem processados pelo mesmo processo de servidor RADIUS, uma vulnerabilidade no caminho do RADIUS de convidados poderá ser utilizada para transitar para a política de autenticação corporativa. A arquitetura recomendada é executar instâncias RADIUS separadas (ou, no mínimo, servidores virtuais separados dentro do FreeRADIUS) para autenticação de convidados e corporativa, com segredos partilhados e conjuntos de políticas separados. Isto proporciona isolamento, de modo a que um comprometimento do caminho do RADIUS de convidados não exponha as credenciais corporativas. Especificamente para a instância de convidados: aplique a correção para BlastRADIUS, rode os segredos partilhados e garanta que a instância RADIUS de convidados não tem acesso ao Active Directory corporativo. Os requisitos de EAP-TLS e RadSec são menos relevantes para uma implementação de Captive Portal, mas o RadSec deve ainda assim ser considerado se o controlador do Captive Portal estiver num segmento de rede diferente do servidor RADIUS.
Q3. Uma fundação de saúde está a planear migrar o seu WiFi clínico de WPA2-Personal para autenticação 802.1X. A fundação possui 1.200 dispositivos clínicos, incluindo portáteis Windows, tablets iOS e dispositivos portáteis Android. O CISO deseja o EAP-TLS como estado-alvo. O diretor de TI está preocupado com a complexidade de implementação da PKI e propõe o PEAP-MSCHAPv2 como uma solução permanente. Como aconselha o CISO e o diretor de TI, e qual é o caminho de implementação recomendado?
Dica: Considere o modelo de ameaça específico para um ambiente de saúde — quais são as consequências de um comprometimento de credenciais e como é que o EAP-TLS aborda riscos que o PEAP-MSCHAPv2 não aborda?
Ver resposta modelo
O instinto do CISO está correto, mas a preocupação do diretor de TI é válida. O conselho recomendado é: implementar o PEAP-MSCHAPv2 agora como uma solução provisória, com um roteiro comprometido de 12 meses para o EAP-TLS. A justificação para não aceitar o PEAP-MSCHAPv2 como uma solução permanente na área da saúde é: (1) O PEAP-MSCHAPv2 é vulnerável a ataques de servidores RADIUS falsos se a validação de certificados do lado do cliente não for imposta. Num ambiente de saúde onde a equipa clínica pode ligar dispositivos pessoais, impor a configuração do suplicante de forma consistente em 1.200 dispositivos é um desafio operacional. (2) As credenciais MSCHAPv2, se capturadas através de um ataque de RADIUS falso, podem ser decifradas offline utilizando ferramentas como o hashcat. Num contexto de saúde, essas credenciais provavelmente também fornecem acesso a sistemas clínicos. (3) As avaliações do NHS DSPT e da CQC exigem cada vez mais controlos de autenticação fortes para o acesso à rede clínica. O EAP-TLS fornece uma posição de evidência de auditoria mais forte. O caminho de implementação: Meses 1-2: Implementar PEAP-MSCHAPv2 com validação forçada de certificado de servidor através de perfis MDM em todos os 1.200 dispositivos. Meses 3-6: Implementar o Microsoft ADCS como infraestrutura PKI. Registar dispositivos Windows através de registo automático de Política de Grupo. Meses 6-9: Registar dispositivos iOS e Android através de perfis de certificado MDM. Meses 9-12: Migrar a política de SSID clínico de PEAP para EAP-TLS. Manter o PEAP como alternativa para quaisquer dispositivos que falhem o registo de certificado, com monitorização melhorada. Para mais informações sobre arquitetura de segurança de rede clínica, o WiFi in Hospitals guide fornece o contexto de implementação relevante.
Continue a ler esta série
Três SSIDs para a todos governar: guia de configuração de WiFi para convidados, funcionários e IoT
Este guia de referência técnica autoritário fornece um plano passo a passo para implementar uma arquitetura de três SSIDs de WiFi. Explica como segmentar o tráfego de convidados, funcionários e IoT utilizando Captive Portals, 802.1X RADIUS e PSK por dispositivo (xPSK) para otimizar o desempenho e garantir a conformidade com o PCI DSS.
Integração do CommScope Ruckus com o Purple WiFi: Guia de Instalação e Configuração
Este guia de referência técnica fornece um manual de configuração autoritativo para integrar arquiteturas CommScope Ruckus com o Purple WiFi. Detalha implementações passo a passo para Captive Portals de Guest WiFi, WiFi seguro para funcionários via 802.1X e isolamento de rede multi-tenant utilizando Ruckus Dynamic PSK.
Integração de Access Points Allied Telesis com Purple WiFi
Este guia fornece um manual de configuração abrangente para integrar access points Allied Telesis da Série TQ com o Purple WiFi. Abrange o redirecionamento de Captive Portal externo, autenticação RADIUS 802.1X e direcionamento dinâmico de VLAN usando Private Pre-Shared Keys (PPSK) para implementações multi-tenant seguras.