PEAP-MSCHAPv2: Por que ainda é comum, por que é arriscado e como migrar

Olá e boas-vindas a este briefing técnico da Purple. Sou o seu anfitrião e hoje estamos abordando um assunto que fica na interseção entre arquitetura de rede, conformidade de segurança e, francamente, débito técnico legado. Estamos falando sobre PEAP-MSCHAPv2. Especificamente, estamos analisando por que ele ainda é o método de autenticação mais comum em redes WiFi corporativas, por que é fundamentalmente arriscado no cenário de ameaças atual e, o mais importante, como você pode, na prática, migrar sua organização para algo melhor. Vamos começar com o contexto. Se você é um diretor de TI ou arquiteto de rede em um hotel, uma rede de varejo ou um grande local público, as chances são muito altas de que a rede WiFi de seus funcionários — e talvez seus dispositivos corporativos — estejam se autenticando usando PEAP-MSCHAPv2. Ele tem sido o padrão padrão para redes WPA2-Enterprise por quase duas décadas. Por quê? Porque é incrivelmente fácil de implantar. Ele se conecta diretamente ao Active Directory por meio de um servidor RADIUS, e os usuários apenas digitam seu nome de usuário e senha padrão do Windows. Sem certificados para gerenciar, sem infraestrutura complexa de chaves públicas para criar. Ele simplesmente funciona. Mas "simplesmente funcionar" não é mais suficiente. A arquitetura de segurança que sustenta o PEAP-MSCHAPv2 está, para ser franco, quebrada. Vamos mergulhar na realidade técnica. O MSCHAPv2 depende do algoritmo de hash MD4 e da criptografia DES. Ambos os padrões criptográficos foram projetados 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 pesquisador Moxie Marlinspike demonstrou que o handshake do MSCHAPv2 poderia ser quebrado de forma determinística. Ele lançou uma ferramenta que reduziu o processo de quebra a uma única quebra de chave DES, o que significa que um invasor com poder de computação modesto — ou acesso a um serviço de quebra na nuvem — poderia recuperar a senha do Active Directory em texto simples de um usuário a partir de um handshake capturado em questão de horas, se não minutos. Então, como um invasor realmente captura esse handshake no mundo real? Isso nos leva ao ataque "Evil Twin". Imagine um escritório corporativo ou uma área de bastidores de um hotel. Um invasor entra com um ponto de acesso não autorizado — geralmente algo tão pequeno quanto um Wi-Fi Pineapple em sua mochila. Eles configuram esse AP não autorizado para transmitir exatamente o mesmo SSID da sua rede corporativa, por exemplo, "Staff-WiFi". Eles aumentam a força do sinal para que os dispositivos próximos naturalmente o prefiram em relação aos seus pontos de acesso legítimos. Quando o laptop ou celular de um funcionário tenta se conectar, o AP invasor age como o autenticador e aponta para um servidor RADIUS falso controlado pelo invasor. O dispositivo do funcionário inicia o túnel PEAP. Agora, aqui está o ponto crítico de falha: o PEAP depende do dispositivo cliente verificar o certificado digital do servidor para garantir que está se comunicando com o servidor RADIUS corporativo real. No entanto, na grande maioria das implantações, os dispositivos clientes estão mal configurados ou os usuários simplesmente recebem um pop-up perguntando "Você confia neste certificado?" e clicam em "Sim" apenas para se conectar. Uma vez que esse certificado falso é aceito, o dispositivo envia o desafio-resposta MSCHAPv2 pelo túnel. O invasor o captura, vai embora e quebra o hash offline. Agora eles têm credenciais válidas do Active Directory, que podem usar para fazer login na sua VPN, no seu sistema de e-mail ou em qualquer outro serviço corporativo. Isso não é um risco teórico. É um procedimento operacional padrão tanto para testadores de invasão quanto para agentes maliciosos. E se você está sujeito a frameworks de conformidade como PCI DSS ou GDPR, depender de um protocolo de autenticação comprometido é uma responsabilidade significativa. Então, se os riscos são tão altos, por que todos nós ainda não mudamos? A resposta geralmente é uma mistura de complexidade percebida e hardware legado. Afastar-se do PEAP significa avançar em direção à autenticação baseada em certificados, especificamente o EAP-TLS. O EAP-TLS é o padrão ouro. Ele exige que tanto o servidor quanto o dispositivo cliente apresentem um certificado digital válido. Não há senhas transmitidas, em hash ou de outra forma. Ele é 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 Certificadora confiável. Mas implantar o EAP-TLS significa que você precisa de uma Infraestrutura de Chaves Públicas, ou PKI. Você precisa de uma maneira de gerar certificados e distribuí-los com segurança para cada laptop, celular e tablet da sua frota. Cinco anos atrás, construir uma infraestrutura do Microsoft Active Directory Certificate Services era um projeto assustador e caro. Hoje, no entanto, o cenário mudou. O caminho de implementação é muito mais claro. Se você está planejando uma migração, aqui está a abordagem pragmática que recomendamos aos nossos clientes na Purple. Primeiro, você não precisa fazer uma transição abrupta. Servidores RADIUS modernos — seja o Cisco ISE, Aruba ClearPass ou soluções nativas da nuvem — permitem que você execute PEAP-MSCHAPv2 e EAP-TLS simultaneamente no mesmo SSID. O passo um é implantar sua PKI. Você não precisa necessariamente construir isso localmente (on-premise) hoje em dia. As soluções de PKI em nuvem se integram diretamente com seu provedor de identidade — como Entra ID ou Google Workspace — e suas plataformas de Gerenciamento de Dispositivos Móveis (MDM), como Intune ou Jamf. A etapa dois consiste em usar seu MDM para enviar silenciosamente certificados de cliente para seus dispositivos gerenciados. Você pode configurar o perfil de WiFi via MDM para preferir EAP-TLS. Isso significa que seus laptops corporativos mudarão automaticamente para o método seguro baseado em certificado, sem qualquer interação do usuário. A etapa três é a fase de transição. Você monitora seus logs do RADIUS. Você verá seus dispositivos gerenciados se autenticando via EAP-TLS, enquanto os dispositivos não gerenciados ou legados continuam a usar PEAP. Isso nos leva ao erro comum: dispositivos legados. O que fazer com os leitores de código de barras de dez anos atrás em seu depósito, ou com os terminais de ponto de venda mais antigos que simplesmente não suportam EAP-TLS? A solução é a segmentação. Você nunca deve degradar a segurança da sua rede principal de funcionários para acomodar o menor denominador comum. Em vez disso, isole esses dispositivos legados em uma VLAN dedicada. Você pode usar autenticação baseada em MAC combinada com controles rígidos de acesso à rede, garantindo que esses dispositivos só possam se comunicar com os servidores internos específicos de que precisam, e absolutamente mais nada. Assim que sua frota gerenciada estiver totalmente migrada para EAP-TLS, você poderá finalmente desativar o PEAP-MSCHAPv2 no seu SSID corporativo principal, fechando a janela de vulnerabilidade de vez. Vamos fazer um rápido perguntas e respostas com base nas dúvidas mais comuns que recebemos de diretores de TI. Pergunta um: "O WPA3 corrige o problema do PEAP-MSCHAPv2?" Resposta: Não. O WPA3 melhora a criptografia pelo ar, mas o método de autenticação EAP subjacente permanece o mesmo. Se você usar WPA3-Enterprise com PEAP-MSCHAPv2, ainda estará vulnerável à captura de credenciais por meio de um Evil Twin se o cliente não validar estritamente o certificado do servidor. Pergunta dois: "E quanto ao EAP-TTLS?" Resposta: O EAP-TTLS é melhor que o PEAP porque ele tunela a autenticação, geralmente usando PAP em vez de MSCHAPv2, o que evita as fraquezas criptográficas específicas do MSCHAPv2. No entanto, ele ainda depende de senhas e continua vulnerável se o certificado do servidor não for validado. É um degrau intermediário, mas o EAP-TLS deve ser o objetivo final. Pergunta três: "Como isso afeta o nosso Purple guest WiFi?" Resposta: Não afeta diretamente. O guest WiFi normalmente usa redes abertas com Captive Portals ou WPA2/3-Personal, que são separados da sua autenticação empresarial 802.1X. No entanto, proteger a rede de back-of-house é fundamental para proteger a infraestrutura que suporta todas as operações do seu local, incluindo seus serviços de visitantes e plataformas de analytics. Para resumir: o PEAP-MSCHAPv2 nos atendeu bem, mas seu tempo passou. As falhas criptográficas são públicas e as ferramentas de ataque são automatizadas. A migração para EAP-TLS não é mais um projeto experimental de ponta; é uma atualização padrão e alcançável, facilitada significativamente pelas soluções modernas de MDM e PKI em nuvem. O risco de não fazer nada — uma senha comprometida do Active Directory levando a uma violação de rede mais ampla — supera em muito o esforço operacional da migração. Comece com uma auditoria de seus logs RADIUS hoje mesmo, identifique seus dispositivos legados e comece a mapear sua transição para a autenticação baseada em certificados. Obrigado por ouvir este briefing técnico da Purple. Para guias de implantação mais detalhados e diagramas de arquitetura, certifique-se de ler o guia de referência técnica completo que acompanha este podcast.