Page tree
Skip to end of metadata
Go to start of metadata

A riesgo de ser pesado, pero a la vista de que todavía hay organizaciones que tienen una configuración insegura de SecureW2, hago este documento.

He de advertir, también, que hay organizaciones con PEAP que incumplen alguna de las buenas prácticas que se indican aquí.

nicolas.velazquez@uam.es

Objeto.

Una correcta configuración de SecureW2 (o cualquier otro cliente 802.1X) hace posible que la contraseña del usuario solo pueda verse en el radius de la organización de origen del usuario.

Una incorrecta configuración, dependiendo del grado de incorrección, hace que cualquier ordenador cercano, capturando la emisión inalámbrica, pueda capturar usernames con extrema facilidad y contraseñas con algo mas de esfuerzo.

Habitualmente, el descuido en la configuración de clientes se produce por el error en suponer que la encriptacion WPA y WPA2 empieza antes de lo que realmente lo hace.

WPA y WPA2 empiezan DESPUÉS del intercambio usuario y contraseña.

Se considerará aquí el caso mas general de un usuario de nuestra organización (visitante.es) que está visitando otra organización eduroam (visitada.es).

Dejo como ejercicio para el lector el caso de un usuario en su propia organización. Eso sí, los problemas y sus consecuencias no cambian.


Conceptos previos.

*Clave pública y privada del radius:

Conjunto de claves asimétricas para encriptar transmisiones o datos. La pública es de libre distribución y la privada sólo debe residir en el radius.

*Outer identity:

Solicitud de clave pública del radius.

*Inner identity:

Usuario real y contraseña.


Condiciones que debe cumplir una configuración segura de un SecureW2.

  1. La outer identity debe ser no significativa. Sólo debe ser significativo el dominio. (anonymous@visitante.es)
  2. La outer identity debe ser del dominio del usuario. No debe ser del dominio visitado.
  3. El cliente debe comprobar que la clave pública que le llega es la del radius de su organización.
  4. La clave pública debe ser obtenida o deducida de forma completamente segura.
  5. La inner identity debe incluir el dominio. Si se cumple la condición 1, el usuario de la la inner podría ser solo el username a la izquierda de la @. Pero, en ese caso, la red inalámbrica de la organización visitada no podría reportar adecuadamente el inicio y fin de sesión a la organización visitante.

Incumplimiento de la condición 1. La outer es significativa.

El caso mas habitual es que se ponga como outer identity el usuario real (nombre.apellido@visitante.es).

Basta con un analizador de red para verlas y capturarlas.

Atención: Según el RFC 4282, la outer identity adecuada debería ser @dominio.es, sin username. SecureW2 incorporó el cumplimiento del RFC 4282 en la 3.2.0. Sin embargo Freeradius y Windows Mobile no soportaban que el código de usuario de la outer estuviese vacío. En la 3.3.0 mejoró la implementación para adecuarse al modo habitual de funcionamiento de Freeradius y Mobile y dejar a elección del usuario o administrador el cumplimiento o no del rfc.


Incumplimiento de la condición 2. La outer no lleva dominio o lleva el de la organización visitada.

Eso hace que la red haga llegar al cliente la clave pública del radius mas cercano (anonymous) o la de la organización visitada (anonymous@visitada.es).

La cuestión es que el cliente, un visitante, va a recibir una clave pública que no conoce.

Nota: Si el cliente incumple de forma conjunta la condición 2 y 3 (no comprueba clave pública), y cumple las demás, la validación se producirá, pero será visible, en el mejor de los casos, por toda la jerarquía de radius eduroam hasta el de su organización. En el peor de los casos, está a merced del Man in the Middle que pueda estar a su lado.


Incumplimiento de la condición 3. El cliente no comprueba la clave pública que le llega.

Esta es la incorrección mas grave de todas.

Puede ser por varias razones.

  • Cumple la regla 2. Pone su dominio y, por tanto, conoce o puede deducir la clave pública del radius de su organización. Pero "se fía" y no se toma la molestia de comprobar.
  • Incumple la regla 2. No pone dominio o pone el de la organización visitada. Por tanto, pide la clave del radius local y como NO SABE su clave pública, no la comprueba.

Lo importante, aquí, es entender que el cliente utiliza la clave pública que le llega por la red para encriptar la inner identity completa.

Así, el sistema que tenga la clave privada asociada, será el único que pueda ver el usuario y la contraseña.

Por tanto, si el cliente no comprueba que la clave pública es la correcta, puede estar recibiendo una clave pública de un Man in the Middle que está sentado a su lado. !!!!!!!

Nota: Desde la versión 3.3.0, SecureW2 permite validar toda la cadena de claves públicas desde la CA root sin tener que decir de forma explícita todas las sub CAs implicadas para llegar a la clave pública del radius. Esto hace que la configuración del SecureW2 para comprobar clave pública se simplifique en extremo.


Incumplimiento de la condición 4. Obtiene la clave pública del radius por la misma red inalámbrica.

Esto se hace en SecureW2 con la opción Advanced > Allow users to setup new connections.

No es una buena práctica.

El usuario, por tanto, puede aceptar cualquier clave pública que un Man in the Middle está emitiendo.

Nota: El cliente TTLS de MacOS está SIEMPRE configurado de forma que, ante la presentación de una clave pública nueva, pide al usuario final la aceptación o no de esa clave como válida. El fallo de seguridad es evidente. Pendiente saber como gestiona esto el nuevo MacOS Leopard.


Incumplimiento de la condición 5. El usuario pone como inner su username SIN DOMINIO y su contraseña.

Esto sólo funciona cuando la outer es completa (anonymous@visitante.es).

La validación, en este caso, se produce sin problema. Pero el accounting no llegará a la organización visitada.


Pantallazos

Nota de la US.ES: SecureW2 hace distinción entre may�sculas y minúsculas en el nombre del servidor del certificado, por lo que si el nombre del servidor en el certificado está en mayúsculas, se debe poner también en mayúsculas en la parte "Verify server name".


Mas información.

Presentación de los GT Junio 2007 en formato PPT. http://www.eduroam.es/presentaciones/SecureW2.ppt

Presentación de los GT Junio 2007 en formato PDF. http://www.eduroam.es/presentaciones/SecureW2.pdf

  • No labels