PEAP-MSCHAPv2: Por qué sigue siendo común, por qué es riesgoso y cómo avanzar

Hola y bienvenidos a esta sesión técnica de Purple. Soy su anfitrión y hoy abordaremos un tema que se encuentra en la intersección de la arquitectura de red, el cumplimiento de seguridad y, francamente, la deuda técnica heredada. Estamos hablando de PEAP-MSCHAPv2. Específicamente, analizaremos por qué sigue siendo el método de autenticación más común en el WiFi empresarial, por qué es fundamentalmente riesgoso en el panorama de amenazas actual y, lo más importante, cómo puede trasladar de manera práctica a su organización hacia algo mejor. Comencemos con el contexto. Si usted es director de TI o arquitecto de redes en un hotel, una cadena de retail o un gran recinto público, es muy probable que la red WiFi de su personal —y quizás sus dispositivos corporativos— se estén autenticando mediante PEAP-MSCHAPv2. Ha sido el estándar predeterminado para las redes WPA2-Enterprise durante casi dos décadas. ¿Por qué? Porque es increíblemente fácil de implementar. Se conecta directamente a Active Directory a través de un servidor RADIUS y los usuarios simplemente ingresan su nombre de usuario y contraseña estándar de Windows. Sin certificados que administrar, sin una infraestructura compleja de clave pública que construir. Simplemente funciona. Pero "simplemente funcionar" ya no es suficiente. La arquitectura de seguridad que sustenta a PEAP-MSCHAPv2 está, para decirlo sin rodeos, obsoleta. Profundicemos en la realidad técnica. MSCHAPv2 se basa en el algoritmo de hash MD4 y el cifrado DES. Ambos estándares criptográficos se diseñaron en la década de 1990 y se consideran débiles desde hace más de una década. En 2012, en la conferencia de seguridad DEF CON, el investigador Moxie Marlinspike demostró que el saludo de conexión (handshake) de MSCHAPv2 se podía descifrar de forma determinista. Lanzó una herramienta que redujo el proceso de descifrado a un solo descifrado de clave DES, lo que significa que un atacante con una potencia informática modesta —o acceso a un servicio de descifrado en la nube— podría recuperar la contraseña de Active Directory en texto plano de un usuario a partir de un saludo de conexión capturado en cuestión de horas, si no de minutos. Entonces, ¿cómo captura realmente un atacante ese saludo de conexión en el mundo real? Esto nos lleva al ataque "Evil Twin" (Gemelo Malvado). Imagine una oficina corporativa o el área de operaciones internas de un hotel. Un atacante entra con un punto de acceso no autorizado, a menudo algo tan pequeño como un Wi-Fi Pineapple en su mochila. Configuran este AP no autorizado para transmitir exactamente el mismo SSID que su red corporativa, por ejemplo, "Staff-WiFi". Aumentan la intensidad de la señal para que los dispositivos cercanos lo prefieran de forma natural sobre sus puntos de acceso legítimos. Cuando la laptop o el teléfono de un empleado intenta conectarse, el AP malicioso actúa como el autenticador y apunta a un servidor RADIUS falso controlado por el atacante. El dispositivo del empleado inicia el túnel PEAP. Ahora, aquí está el punto crítico de falla: PEAP depende de que el dispositivo cliente verifique el certificado digital del servidor para asegurarse de que se está comunicando con el servidor RADIUS corporativo real. Sin embargo, en la gran mayoría de las implementaciones, los dispositivos cliente están mal configurados o simplemente se les presenta a los usuarios una ventana emergente que dice "¿Confía en este certificado?" y hacen clic en "Sí" solo para conectarse. Una vez que se acepta ese certificado falso, el dispositivo envía el desafío-respuesta MSCHAPv2 a través del túnel. El atacante lo captura, se retira y descifra el hash fuera de línea. Ahora tienen credenciales válidas de Active Directory, que pueden usar para iniciar sesión en su VPN, su sistema de correo electrónico o cualquier otro servicio corporativo. Este no es un riesgo teórico. Es un procedimiento operativo estándar tanto para los evaluadores de penetración como para los actores maliciosos. Y si está sujeto a marcos de cumplimiento como PCI DSS o GDPR, confiar en un protocolo de autenticación comprometido es una responsabilidad significativa. Entonces, si los riesgos son tan altos, ¿por qué no hemos hecho la transición? La respuesta suele ser una mezcla de complejidad percibida y hardware heredado. Dejar atrás PEAP significa avanzar hacia la autenticación basada en certificados, específicamente EAP-TLS. EAP-TLS es el estándar de oro. Requiere que tanto el servidor como el dispositivo cliente presenten un certificado digital válido. No se transmiten contraseñas, cifradas ni de ninguna otra forma. Es completamente inmune a los ataques de diccionario fuera de línea y altamente resistente a los ataques de Evil Twin porque el cliente rechazará silenciosamente cualquier servidor RADIUS falso que no tenga un certificado firmado por su Autoridad de Certificación de confianza. Pero implementar EAP-TLS significa que necesita una Infraestructura de Clave Pública, o PKI. Necesita una forma de generar certificados y distribuirlos de manera segura a cada laptop, teléfono y tableta de su flota. Hace cinco años, construir una infraestructura de Microsoft Active Directory Certificate Services era un proyecto desalentador y costoso. Hoy, sin embargo, el panorama ha cambiado. El camino de implementación es mucho más claro. Si está planeando una migración, este es el enfoque pragmático que recomendamos a nuestros clientes en Purple. Primero, no tiene que hacer una transición abrupta. Los servidores RADIUS modernos, ya sea Cisco ISE, Aruba ClearPass o soluciones nativas de la nube, le permiten ejecutar PEAP-MSCHAPv2 y EAP-TLS simultáneamente en el mismo SSID. El primer paso es implementar su PKI. Ya no necesita necesariamente construir esto de forma local. Las soluciones de PKI en la nube se integran directamente con su proveedor de identidad, como Entra ID o Google Workspace, y sus plataformas de gestión de dispositivos móviles como Intune o Jamf. El paso dos consiste en utilizar su MDM para enviar de forma silenciosa certificados de cliente a sus dispositivos gestionados. Puede configurar el perfil de WiFi a través de MDM para que prefiera EAP-TLS. Esto significa que sus laptops corporativas cambiarán automáticamente al método seguro basado en certificados sin ninguna interacción del usuario. El paso tres es la fase de transición. Usted monitorea sus registros de RADIUS. Verá que sus dispositivos gestionados se autentican a través de EAP-TLS, mientras que los dispositivos no gestionados o heredados continúan utilizando PEAP. Esto nos lleva al error común: los dispositivos heredados. ¿Qué hacer con los escáneres de códigos de barras de hace diez años en su almacén, o las terminales de punto de venta más antiguas que simplemente no son compatibles con EAP-TLS? La solución es la segmentación. Nunca debe degradar la seguridad de su red principal de personal para adaptarse al mínimo común denominador. En su lugar, aísle esos dispositivos heredados en una VLAN dedicada. Puede utilizar la autenticación basada en MAC combinada con controles estrictos de acceso a la red, garantizando que esos dispositivos solo puedan comunicarse con los servidores internos específicos que necesitan, y absolutamente nada más. Una vez que su flota gestionada se haya migrado por completo a EAP-TLS, finalmente podrá desactivar PEAP-MSCHAPv2 en su SSID corporativo principal, cerrando la ventana de vulnerabilidad para siempre. Hagamos una sesión rápida de preguntas y respuestas basada en las dudas más comunes que recibimos de los directores de TI. Pregunta uno: "¿WPA3 soluciona el problema de PEAP-MSCHAPv2?" Respuesta: No. WPA3 mejora el cifrado de forma inalámbrica, pero el método de autenticación EAP subyacente sigue siendo el mismo. Si utiliza WPA3-Enterprise con PEAP-MSCHAPv2, sigue siendo vulnerable a la captura de credenciales a través de un Evil Twin si el cliente no valida estrictamente el certificado del servidor. Pregunta dos: "¿Qué pasa con EAP-TTLS?" Respuesta: EAP-TTLS es mejor que PEAP porque tuneliza la autenticación, a menudo utilizando PAP en lugar de MSCHAPv2, lo que evita las debilidades criptográficas específicas de MSCHAPv2. Sin embargo, sigue dependiendo de contraseñas y sigue siendo vulnerable si no se valida el certificado del servidor. Es un paso intermedio, pero el objetivo final debe ser EAP-TLS. Pregunta tres: "¿Cómo afecta esto a nuestro WiFi de invitados de Purple?" Respuesta: No afecta directamente. El WiFi de invitados suele utilizar redes abiertas con Captive Portals o WPA2/3-Personal, que son independientes de su autenticación empresarial 802.1X. Sin embargo, proteger la red interna es fundamental para salvaguardar la infraestructura que soporta todas las operaciones de su establecimiento, incluidos sus servicios para invitados y plataformas de analítica. En resumen: PEAP-MSCHAPv2 nos ha sido de gran utilidad, pero su tiempo ha pasado. Las fallas criptográficas son públicas y las herramientas de ataque están automatizadas. La migración a EAP-TLS ya no es un proyecto de vanguardia experimental; es una actualización estándar y alcanzable, facilitada significativamente por las soluciones modernas de MDM y PKI en la nube. El riesgo de no hacer nada —una contraseña de Active Directory comprometida que resulte en una brecha de red más amplia— supera por mucho el esfuerzo operativo de la migración. Comience hoy mismo con una auditoría de sus registros de RADIUS, identifique sus dispositivos heredados y empiece a planificar su transición hacia la autenticación basada en certificados. Gracias por escuchar este informe técnico de Purple. Para obtener guías de implementación más detalladas y diagramas de arquitectura, asegúrese de leer la guía de referencia técnica completa que acompaña a este podcast.