En la trama de comunicación que vemos en esta imagen cuando el Authenticator detecta una nueva conexión envía una solicitud de autenticación basada en el protocolo 802.1X [trama 63]. Este paquete se encapsula con el protocolo EAP (Extended Authentication Protocol) para que exista interoperabilidad entre distintos fabricantes. La respuesta del Supplicant [trama 64] incluye el nombre de la Identidad que puede ser un nombre de máquina o bien un nombre de usuario. El Authenticator envía esa identidad al servidor de autenticación para que pueda generar un Accaess-Challenge que únicamente el usuario legítimo sabría resolver. Ese Access-Challenge es enviado por el Authenticator al Supplicant que lo resuelve y contesta para finalmente recibir el OK [trama 70] o el KO de acceso a la red. El Access-Challenge se puede producir por distintos protocolos, en el caso que vamos a ver a continuación se utiliza EAP-TLS [tramas 65, 66, 67 y 68] y está basado en certificados.
En caso de que la máquina no disponga de un certificado válido, o simplemente no disponga de un perfil 802.1X configurado, no se le daría acceso a ninguna red (opaco) o bien se le podría enviar a una red de invitado.
Si imaginamos un entorno empresarial con dispositivos muy heterogéneos que deben acceder a la red pero algunos de ellos (VoIP phones, impresoras, etc.) no tienen capacidad de implementar este protocolo, nos encontraríamos frente a una casuística en la que la compañía deba realizar una autenticación basada en whitelisting de MAC. Se conoce como MAB (MAC Authentication Bypass). Si se da este caso y no existen configuraciones de seguridad adicionales se podría acceder a la red de forma sencilla haciendo MAC spoofing con la dirección física de un dispositivo en whitelist.
Después de esta introducción hablaremos el resto del post en la posibilidad de saltarnos este mecanismo de autenticación 802.1X. El contexto y necesidad del que partimos es poder ganar acceso a la red de forma transparente. Para ello necesitaremos introducir un dispositivo HW en la organización y conectarlo a una toma ethernet con acceso a red. Este dispositivo debe tener dos interfaces de red, en el ejemplo que vamos a ver se ha utilizado una RaspberryPi con la distribución Kali y un tarjeta ethernet tipo USB dongle. Se recomienda la distribución Kali dado que tiene herramientas tanto para atacar en capa 2 (ARP spoofing, VLAN Hopping, etc) como para realizar los escaneos de red que nos permitirán encontrar un vector de ataque.
La idea es implementar con la RaspberryPi un bridge que permita el flujo de información entre el Supplicant y el Authenticator mientras se monitoriza el tráfico de forma transparente. Conectaríamos la interfaz de red el equipo Supplicant a una interfaz de la RaspberryPi y el cable que está enganchado al puerto ethernet de la compañía a la otra interfaz de la RaspberryPi. Quedaría de la siguiente forma:
Una vez tenemos todo configurado hay que montar el bridge para poder esnifar el tráfico. Tenemos varias opciones:
• Levantar de forma manual el bridge y gestionar reglas de forwarding, IP y ARP.
• O bien hacer uso de alguna herramienta ya diseñada para ello. Dos de las herramientas más funcionales para esto son Fenrir-OCD de Valérian LEGRAND y Silentbridge de s0lst1c3.
En este caso haremos uso de SilentBridge. Una vez conectadas las interfaces de red, hay que ejecutar el siguiente comando de SilentBridge para levantar el bridge de forma transparente:
./silentbridge --create-bridge --upstream eth0 --phy eth1 --sidechannel wlan0
El nombre de la interfaz upstream, debe ser la que se conecta a la toma de red de la compañía, en nuestro caso la interfaz integrada "eth0". El nombre de la interfaz phy, debe ser la que se conecta al Supplicant (laptop), en nuestro caso la interfaz usb "eth1". La interfaz "--sidechannel" puede ser una interfaz WiFi o LTE para acceder por ssh y ejecutar los comandos en la Raspi de forma remota (quizá otro día hablemos de ello).
En este punto si levantamos Wireshark o tcpdump podemos ver las tramas de autenticación 802.1X, la respuesta "Success" y como al marcar el puerto como autenticado se comienza solicitando una IP de red por DHCP.
Tan solo podemos monitorizar el tráfico no cifrado punto a punto, es decir HTTP y otros protocolos que envíen información en claro. Con esta configuración no vamos a poder interactuar más allá a no ser que se implementen nuevas reglas para generar tráfico suplantando al Supplicant.
Una vez que somos capaces de monitorizar el tráfico podemos ir un paso más allá y hacer a lo que realmente hemos venido, que es bypasear el NAC para poder estar en la red autenticada y realizar escaneos de red. Para ello vamos a hacer uso de otro módulo de SilentBridge, se trata de la opción "--add-interaction" y va a hacer que todo el tráfico que generemos desde la Raspi se haga pasar por tráfico legítimo del Supplicant, es decir, vamos a spoofear su IP y MAC. Antes de nada, tenemos que conocer la siguiente información que podemos obtener del snifing previo que hemos realizado con el bridge:
- IP de Supplicant para spoofear: "-client-ip"
- MAC de Supplicant para spoofear "--client-mac"
- MAC de switch Authenticator "--switch-mac"
- MAC del gateway a quien enviar la información: "--gw-mac"
Un ejemplo de este comando sería:
./silentbridge --add-interaction --gw-mac a1:b2:c3:a1:b2:c3 --client-ip 10.180.X.22 --upstream eth0 --client-mac a1:b2:c3:a1:b2:c3 --phy eth1 --switch-mac a1:b2:c3:a1:b2:c3 --sidechannel wlan0
Todo el tráfico que se genera desde la Kali se hará suplantando al Supplicant (IP que finaliza en .22), por lo que parecerá que el tráfico es legítimo. Este comando crea automáticamente las reglas necesarias de nateo para capturar el tráfico generado por la kali y no interferir con el tráfico legítimo del Supplicant que sigue siendo transparente.
En los siguientes pantallazos vemos como el tráfico generado desde Kali se hace pasar por el cliente. Para ello abrimos una conexión contra un equipo de la red al puerto 135.
Y comprobamos como el origen parece venir del Supplicant, es decir de la IP que acaba en 22.
Y en este punto, ancha es Castilla. Se puede realizar cualquier técnica de hacking para enumerar e identificar vulnerabilidades en los sistemas de la red.
Desde un punto de vista defensivo, ¿cómo se puede evitar esto? Pues se debe realizar una configuración en el protocolo 802.1X-2010 para que se cifre el tráfico a nivel de enlace configurando MACSEC en el switch Authenticator.
0 comentarios:
Publicar un comentario