Wireless Hacking – WPA/WPA2 Enterprise, Usando FreeRadius como Servidor de Autenticación – Parte XIX

El objetivo principal de cualquier servidor Radius es proveer mecanismos de autenticación fuertes para mejorar los tiempos de respuesta y la latencia de la red en entornos empresariales donde se pueden encontrar una cantidad considerable de clientes. En el caso de las redes inalámbricas utilizando WPA/WPA2 estas tareas se suelen llevar a cabo utilizando claves compartidas (PSK) sin embargo este mecanismo puede ser “pesado” y puede consumir mas recursos de lo que es deseable en un entorno con múltiples clientes, por este motivo es común encontrar una separación de WPA para uso domestico con pocos usuarios y para uso empresarial con un número alto de usuarios. El modelo de conexión entre un cliente y un AP con un servidor RADIUS para establecer la autenticación es bastante sencillo y puede resumirse en la siguiente imagen

Como puede verse, la autenticación se lleva a cabo por medio de un mecanismo de “reto-respuesta” siguiendo un modelo similar al mecanismo de autenticación en WEP (sin embargo, sin asumir las vulnerabilidades intrínsecas en WEP).

El siguiente paso una vez que se han seguido los pasos de la publicación anterior sobre la instalación de FreeRADIUS, es comenzar a editar los ficheros de configuración que permiten establecer cuales son los usuarios que podrán autenticarse con el AP. Dichos ficheros son los siguientes:

/usr/local/etc/raddb/users

/usr/local/etc/raddb/eap.conf

En el primero de estos dos ficheros, se declaran los usuarios que podrán autenticarse con el servidor RADIUS y en el segundo se especifican elementos de configuración relacionados con el mecanismo de autenticación. Para crear un usuario pueden incluirse la siguiente linea en el fichero users

adastra Cleartext-Password := «adastra»

Con esto, se ha adicionado el usuario “adastra” con password “adastra”, para este mismo usuario pueden incluirse otras opciones de configuración tales como la dirección IP del cliente, la dirección de mascara de red, Protocolo, MTU, etc. se pueden ver todas estas características en los comentarios que se incluyen en el fichero de configuración por defecto.

Ahora el fichero de configuración eap.config permite establecer el tipo de autenticación que soportará el servidor, entre los cuales se incluyen PEAP, MD5, TLS, TTLS, LEAP, GTC, entre otros. El contenido de este fichero puede ser el siguiente:

eap { default_eap_type = md5 timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = 4096 md5 { } leap { } gtc { auth_type = PAP } tls { certdir = ${confdir}/certs cadir = ${confdir}/certs private_key_password = whatever private_key_file = ${certdir}/server.pem certificate_file = ${certdir}/server.pem CA_file = ${cadir}/ca.pem dh_file = ${certdir}/dh random_file = ${certdir}/random cipher_list = «DEFAULT» make_cert_command = «${certdir}/bootstrap» ecdh_curve = «prime256v1» cache { enable = no lifetime = 24 # hours max_entries = 255 } verify { } ocsp { enable = no override_cert_url = yes url = «http://127.0.0.1/ocsp/» } } ttls { default_eap_type = md5 copy_request_to_tunnel = no use_tunneled_reply = no virtual_server = «inner-tunnel» } peap { default_eap_type = mschapv2 copy_request_to_tunnel = no use_tunneled_reply = no virtual_server = «inner-tunnel» } mschapv2 { } }

Con la configuración anterior, se utiliza por defecto MD5 debido a la linea default_eap_type = md5 en donde se indica el mecanismo de autenticación.

NOTA: El mecanismo de autenticación con MD5 NO ES ACONSEJABLE, debido a que es considerado inseguro por varias razones, la principal de ellas es que los hashes en MD5 viajan en texto plano, lo que quiere decir que es mucho más fácil realizar un ataque por diccionario, (entre otras cosas), de hecho, en versiones Windows 7 ya no se encuentra la posibilidad de utilizar un servidor Radius con MD5 y en versiones anteriores (Vista, Windows 2003 y XP) ese necesario realizar algunas modificaciones en el registro de windows.

Ahora bien, para comprender mejor como es el intercambio de paquetes entre un cliente, AP y un servidor Radius, la mejor forma es capturando los paquetes que se intercambian entre el cliente y el AP y también capturando los paquetes que se intercambian entre AP y Servidor Radius.

Para hacer esto, en primer lugar, se debe configurar el AP (router) para utilizar WPA2 y establecer el servidor Radius como mecanismo de autenticación, tal y como se ha explicado en la publicación anterior. Una vez hecho esto, para hacer las pruebas se debe contar, o bien con una máquina virtual que tenga habilitada la interfaz inalámbrica o directamente con una máquina independiente que pueda conectarse a la red y actuar como cliente y por otro lado, es necesario tener instalado, configurado y en ejecución el servidor radius, con esto, se procede a filtrar el trafico en ambos extremos:

1. Filtrar el trafico en la máquina donde se encuentre en ejecución el servidor radius utilizando Wireshark (o cualquier sniffer que permita ver los paquetes del tipo eap)

2. Filtrar el trafico en la máquina cliente (una máquina independiente que se conecte a la red o bien, una máquina virtual con acceso a la interfaz de red inalámbrica)

El resultado de las capturas anteriores podrá verse claro cuando el cliente intente conectarse con el router, esto generará paquetes del tipo eap en el cliente y el servidor Radius, donde se intentará llevar a cabo el proceso de autenticación. Las siguientes imágenes enseñan el intercambio de paquetes que se lleva a cabo cuando un cliente intenta conectarse con el AP usando una identidad y como esta petición es remitida al servidor Radius y en el caso de que la autenticación sea exitosa, también se enseña los mensajes de respuesta del servidor radius.

PAQUETES ENTRE CLIENTE Y AP

Como puede verse de las imágenes anteriores, se intercambian una serie de paquetes inicialmente entre el cliente y el AP, para establecer la identidad del cliente, dichos mensajes se identifican en los paquetes iniciales (Request Identity/Request Response) posteriormente, se envía un “reto” por parte del servidor Radius al AP y este al cliente, este reto es simplemente un hash con MD5 que el cliente debe resolver utilizando la clave de su identidad, en el caso de que dicho hash sea valido, el servidor Radius retornará un paquete con un mensaje “Success” indicando que el proceso de autenticación ha finalizado correctamente.

Ahora bien, el mecanismo utilizado anteriormente ha sido MD5, que como ya se ha comentado no es recomendable por ser inseguro, desde la siguiente imagen, puede verse claramente como el “reto” enviado en formato MD5, el cual puede ser capturado y descifrado posteriormente, además los paquetes de identidad intercambiados en el inicio de las comunicaciones, contienen el nombre de usuario en texto plano.

Una vez comprendidos estos conceptos, en próximas publicaciones se hablará un poco más en profundidad de los mecanismos de autenticación frecuentemente utilizados en servidores Radius.