Buenas!!
En esta entrada, vamos a ver una pequeña introducción a los mecanismos de seguridad que desde hace algún tiempo se están implementando en las redes corporativas y que, hasta cierto punto, dificultan las tareas de auditoría interna o Red Team. Se trata del NAC o Network Access Control. Es un mecanismo de seguridad que proporciona protección de acceso a una red corporativa o LAN, es decir, previene que un equipo físico (portátil o sobremesa) no autorizado se conecte a la red.
Aunque no es interés particular de este post, tan solo comentar que a nivel comercial existen distintos tipos de soluciones que han ido ampliando funcionalidades hasta convertirse en herramientas de gestión muy potentes. Inicialmente se desarrollaron sistemas NAC que únicamente verifican contra un directorio la identidad de quien se conecta y en base a la política del usuario se le proporcionaba acceso a una determinada red. Posteriormente las funcionalidades se han ido ampliando hasta poder discernir con gran detalle las características del equipo que se conecta (por ejemplo a través de un agente) para hacer chequeos de seguridad, desplegar portales cautivos para invitados o enviar a redes de cuarentena.
Al lío, ¿cómo funciona por lo general un NAC? En el esquema de autenticación intervienen los siguientes actores:
- Supplicant. Equipo portátil o sobremesa que se conecta a la red.
- Authenticator. Switch o Access Point que en base a la configuración del NAC va a requerir la autenticación del Supplicant.
- Authentication server. Sistema que verifica la identidad del Supplicant contra un LDAP.
 |
| Imagen de wikipedia.org |
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.
Salud!!