PEAP-MSCHAPv2: Porque Ainda É Comum, Porque É Arriscado e Como Mudar

Olá e bem-vindo a este briefing técnico da Purple. Sou o vosso anfitrião e hoje vamos abordar um tema que se situa na interseção da arquitetura de rede, conformidade de segurança e, francamente, dívida técnica herdada. Estamos a falar de PEAP-MSCHAPv2. Especificamente, vamos analisar por que razão ainda é o método de autenticação mais comum no WiFi empresarial, por que razão é fundamentalmente arriscado no panorama de ameaças atual e, mais importante, como pode mover praticamente a sua organização para algo melhor. Comecemos pelo contexto. Se é um diretor de TI ou arquiteto de rede num hotel, numa cadeia de retalho ou num grande espaço público, as probabilidades de a rede WiFi dos seus funcionários — e talvez os seus dispositivos corporativos — estarem a autenticar-se usando PEAP-MSCHAPv2 são muito elevadas. Tem sido o padrão predefinido para redes WPA2-Enterprise há quase duas décadas. Porquê? Porque é incrivelmente fácil de implementar. Liga-se diretamente ao Active Directory através de um servidor RADIUS e os utilizadores apenas introduzem o seu nome de utilizador e palavra-passe padrão do Windows. Sem certificados para gerir, sem infraestrutura complexa de chaves públicas para construir. Simplesmente funciona. Mas "simplesmente funcionar" já não é suficiente. A arquitetura de segurança que sustenta o PEAP-MSCHAPv2 está, para ser direto, ultrapassada. Vamos mergulhar na realidade técnica. O MSCHAPv2 depende do algoritmo de hashing MD4 e da encriptação DES. Ambos os padrões criptográficos foram concebidos na década de 1990 e são considerados fracos há mais de uma década. Em 2012, na conferência de segurança DEF CON, o investigador Moxie Marlinspike demonstrou que o handshake MSCHAPv2 podia ser decifrado de forma determinística. Ele lançou uma ferramenta que reduziu o processo de quebra a uma única chave DES, o que significa que um atacante com poder de computação modesto — ou acesso a um serviço de quebra na nuvem — poderia recuperar a palavra-passe do Active Directory em texto limpo de um utilizador a partir de um handshake capturado em poucas horas, se não minutos. Então, como é que um atacante realmente captura esse handshake no mundo real? Isto leva-nos ao ataque "Evil Twin". Imagine um escritório corporativo ou uma área de apoio de um hotel. Um atacante entra com um ponto de acesso fraudulento — muitas vezes algo tão pequeno como um Wi-Fi Pineapple na mochila. Configura este AP fraudulento para transmitir exatamente o mesmo SSID que a sua rede corporativa, por exemplo, "Staff-WiFi". Aumenta a força do sinal para que os dispositivos próximos o prefiram naturalmente em detrimento dos seus pontos de acesso legítimos. Quando o portátil ou telemóvel de um funcionário tenta ligar-se, o AP fraudulento age como o autenticador e aponta para um servidor RADIUS falso controlado pelo atacante. O dispositivo do funcionário inicia o túnel PEAP. Agora, aqui está o ponto crítico de falha: o PEAP depende de o dispositivo cliente verificar o certificado digital do servidor para garantir que está a falar com o servidor RADIUS corporativo real. No entanto, na grande maioria das implementações, os dispositivos clientes estão mal configurados ou os utilizadores são simplesmente confrontados com uma janela pop-up que pergunta "Confia neste certificado?" e clicam em "Sim" apenas para ficarem online. Assim que esse certificado falso é aceite, o dispositivo envia o desafio-resposta MSCHAPv2 através do túnel. O atacante captura-o, afasta-se e decifra o hash offline. Agora tem credenciais válidas do Active Directory, que pode utilizar para iniciar sessão na sua VPN, no seu sistema de e-mail ou em qualquer outro serviço corporativo. Isto não é um risco teórico. É um procedimento operacional padrão tanto para avaliadores de penetração como para agentes maliciosos. E se estiver sujeito a quadros de conformidade como o PCI DSS ou GDPR, depender de um protocolo de autenticação comprometido é uma responsabilidade significativa. Então, se os riscos são tão elevados, por que razão não mudámos todos ainda? A resposta é normalmente uma mistura de complexidade percebida e hardware antigo. Afastar-se do PEAP significa avançar para a autenticação baseada em certificados, especificamente o EAP-TLS. O EAP-TLS é o padrão de excelência. Exige que tanto o servidor como o dispositivo cliente apresentem um certificado digital válido. Não são transmitidas palavras-passe, em hash ou de outra forma. É completamente imune a ataques de dicionário offline e altamente resistente a ataques Evil Twin, porque o cliente rejeitará silenciosamente qualquer servidor RADIUS falso que não tenha um certificado assinado pela sua Autoridade de Certificação fidedigna. Mas implementar o EAP-TLS significa que precisa de uma Infraestrutura de Chaves Públicas, ou PKI. Precisa de uma forma de gerar certificados e distribuí-los de forma segura para cada portátil, telemóvel e tablet na sua frota. Há cinco anos, construir uma infraestrutura de Active Directory Certificate Services da Microsoft era um projeto assustador e dispendioso. Hoje, no entanto, o cenário mudou. O caminho de implementação é muito mais claro. Se está a planear uma migração, aqui está a abordagem pragmática que recomendamos aos nossos clientes na Purple. Primeiro, não tem de fazer uma transição abrupta. Os servidores RADIUS modernos — seja o Cisco ISE, o Aruba ClearPass ou soluções nativas da nuvem — permitem-lhe executar PEAP-MSCHAPv2 e EAP-TLS em simultâneo no mesmo SSID. O passo um é implementar a sua PKI. Já não precisa necessariamente de construir isto localmente. As soluções de Cloud PKI integram-se diretamente com o seu fornecedor de identidade — como o Entra ID ou Google Workspace — e com as suas plataformas de Mobile Device Management, como o Intune ou Jamf. O passo dois é utilizar o seu MDM para enviar silenciosamente certificados de cliente para os seus dispositivos geridos. Pode configurar o perfil de WiFi via MDM para preferir o EAP-TLS. Isto significa que os portáteis corporativos mudarão automaticamente para o método seguro baseado em certificados, sem qualquer interação do utilizador. O passo três é a fase de transição. Monitoriza os registos do seu RADIUS. Verá os seus dispositivos geridos a autenticarem-se via EAP-TLS, enquanto os dispositivos não geridos ou antigos continuam a utilizar PEAP. Isto leva-nos ao obstáculo comum: os dispositivos antigos. O que fazer com os leitores de códigos de barras com dez anos no seu armazém, ou com os terminais de ponto de venda mais antigos que simplesmente não suportam EAP-TLS? A solução é a segmentação. Nunca deve reduzir a segurança da sua rede principal de funcionários para acomodar o menor denominador comum. Em vez disso, isole esses dispositivos antigos numa VLAN dedicada. Pode utilizar a autenticação baseada em MAC combinada com controlos rigorosos de acesso à rede, garantindo que esses dispositivos apenas conseguem falar com os servidores internos específicos de que necessitam, e absolutamente mais nada. Assim que a sua frota gerida estiver totalmente migrada para o EAP-TLS, pode finalmente desativar o PEAP-MSCHAPv2 no seu SSID corporativo principal, fechando a janela de vulnerabilidade de vez. Vamos fazer uma sessão rápida de perguntas e respostas com base nas dúvidas mais comuns que recebemos dos diretores de TI. Pergunta um: "O WPA3 resolve o problema do PEAP-MSCHAPv2?" Resposta: Não. O WPA3 melhora a encriptação pelo ar, mas o método de autenticação EAP subjacente permanece o mesmo. Se utilizar WPA3-Enterprise com PEAP-MSCHAPv2, continua vulnerável à captura de credenciais através de um Evil Twin se o cliente não validar rigorosamente o certificado do servidor. Pergunta dois: "E quanto ao EAP-TTLS?" Resposta: O EAP-TTLS é melhor do que o PEAP porque cria um túnel para a autenticação, utilizando frequentemente PAP em vez de MSCHAPv2, o que evita as fraquezas criptográficas específicas do MSCHAPv2. No entanto, ainda depende de palavras-passe e continua vulnerável se o certificado do servidor não for validado. É um passo intermédio, mas o EAP-TLS deve ser o objetivo final. Pergunta três: "Como é que isto afeta o nosso WiFi de convidados da Purple?" Resposta: Não afeta diretamente. O WiFi de convidados utiliza normalmente redes abertas com portais cativos ou WPA2/3-Personal, que são independentes da sua autenticação empresarial 802.1X. No entanto, proteger a sua rede de apoio é fundamental para proteger a infraestrutura que suporta todas as operações do seu espaço, incluindo os seus serviços de convidados e plataformas de análise. Para resumir: o PEAP-MSCHAPv2 serviu-nos bem, mas o seu tempo passou. As falhas criptográficas são públicas e as ferramentas de ataque estão automatizadas. A migração para o EAP-TLS já não é um projeto experimental; é uma atualização padrão e alcançável, facilitada significativamente pelas soluções modernas de MDM e Cloud PKI. O risco de não fazer nada — uma palavra-passe do Active Directory comprometida que leva a uma violação mais ampla da rede — supera de longe o esforço operacional da migração. Comece hoje mesmo com uma auditoria aos registos do seu RADIUS, identifique os seus dispositivos antigos e comece a planear a sua transição para a autenticação baseada em certificados. Obrigado por ouvir este briefing técnico da Purple. Para guias de implementação mais detalhados e diagramas de arquitetura, não se esqueça de ler o guia de referência técnica completo que acompanha este podcast.