Usted puede usar los protocolos más fuertes de autenticación (PEAP, EAP-FAST, o EAP-TTLS) y los más robustos algoritmos de encriptación (AES), pero usted sigue siendo fácilmente vulnerable por el pobre diseño de los clientes wireless.

El problema con la autenticación LAN EAP es que no hay una forma natural e intuitiva para hacer coincidir el nombre en el certificado digital con el nombre de SSID. Más específicamente el campo “asunto” ((AKA CN “Common Name” o DN - “Designated Name”) en el certificado digital del server puede ser llamado de cualquier manera. La mayoría de las organizaciones tendrán parte de su nombre en el certificado y si el certificado fue comprado a una autoridad certificante el nombre del dominio estará al final del campo “asunto”.

En contraste, este problema no existe en los clientes HTTPS (Exploradores web), ya que ellos automáticamente comparan el nombre del dominio en la URL con el campo “asunto” del certificado digital. Entonces, cuando un usuario utiliza SSL/TLS para acceder a https://accesoseguro.mibanco.com y el campo “asunto” contiene accesoseguro.mibanco.com un pequeño y simpático candado se ilumina y asegura al usuario que una entidad confiable como VeriSign o Entrust garantiza que está ingresando a accesoseguro.mibanco.com. Pero no es tan simple para un cliente wireless que utiliza la autentificación EAP basada en TLS. Si ve una red wireless con el SSID “MiCompañia”, el certificado puede ser “algo.criptico.empresa.IT.nombre” que no se parece en nada al SSID.

El cliente de Windows XP SP2 y Vista de Microsoft implementados usando Políticas de Grupo ofrece el mayor nivel de seguridad si el administrador sabe cómo hacerlo. En el otro extremo está la configuración independiente del cliente wireless de Microsoft, que no solo es confusa sino que es engañosa por el hecho de que oculta el nombre del certificado. Cuando se le presenta un nuevo certificado al usuario y todo lo que ve es una red avalada por VeriSign pero el nombre del certificado “hacker.decualquier.lado” está oculto, el puede ser engañado fácilmente para que establezca la conexión.

Si bien Windows XP SP2 y Vista se pueden configurar de tal manera que nunca se presente la opción de un servidor RADIUS corrupto, esto depende de la configuración correcta del cliente y este tipo de vulnerabilidades no puede estar atada a la configuración del cliente.

Para llevar esto al punto de partida, los investigadores de seguridad Joshua Wright y Brad Antoniewicz crearon una herramienta de penetración que explota esta debilidad de implementación. ¿Por qué lo han hecho?. Para disparar la alerta, ya que nadie le presta a tención a estas cosas hasta que las ven con sus propios ojos o las leen en las noticias. Sin esta herramienta, el problema masivo sigue existiendo y puede ser explotado con métodos más engorrosos pero igualmente de efectivos, nadie haría nada al respecto dado que no está en su lista de ítems a auditar. Ahora que la herramienta es de conocimiento público, los auditores de seguridad tendrán que usarla para realizar pruebas de penetración antes que el tipo malo lo haga antes que ellos.

Traducción y resumen. Fuenteblogs.zdnet.com