vanhoefm/macstealerMacStealer: Wi-Fi Client Isolation Bypass
Este repositorio contiene MacStealer. Puede probar redes Wi-Fi para detectar bypasses de aislamiento de clientes (CVE-2022-47522). Nuestro ataque puede interceptar (robar) tráfico hacia otros clientes en la capa MAC, incluso si los clientes no pueden comunicarse entre sí. Esta vulnerabilidad afecta a redes Wi-Fi con usuarios internos malintencionados, donde nuestro ataque puede evadir el aislamiento de clientes, que a veces también se conoce como aislamiento de AP. El ataque también puede usarse para evadir la inspección dinámica de ARP (DAI), y probablemente también pueda usarse para evadir otros métodos que impiden que los clientes se ataquen entre sí. El ataque también se conoce como ataque de anulación de contexto de seguridad (security context override attack); consulte la Sección 5 de nuestro artículo de USENIX Security '23 (repositorio).
Ejemplos concretos de posibles redes afectadas son:
Redes empresariales donde los usuarios pueden desconfiar unos de otros, y donde se utilizan técnicas como el aislamiento de clientes o la inspección de ARP para evitar que los usuarios se ataquen entre sí. Por ejemplo, redes empresariales con cuentas tanto para invitados como para personal, redes como eduroam y govroam, etc.
Puntos de acceso públicos protegidos por Passpoint (anteriormente Hotspot 2.0). Estos son puntos de acceso a los que puede conectarse de forma automática y segura. Por ejemplo, pueden autenticarlo sin problemas usando la tarjeta SIM de su teléfono.
Redes domésticas WPA2 o WPA3 que tienen habilitado el aislamiento de clientes. Esto incluye redes con un SSID separado para invitados o para dispositivos inseguros (IoT). También incluye redes donde se utilizan múltiples contraseñas para aislar aún más los dispositivos, lo que también se conoce como Multi-PSK, Identity PSK, PSK por estación, o EasyPSK. Consulte la discusión sobre el modelo de amenaza para obtener información adicional.
Puntos de acceso públicos basados en WPA3 SAE-PK. Estos son puntos de acceso protegidos por una contraseña pública compartida, pero donde un adversario no puede abusar de esta contraseña de conocimiento público.
Señalamos que nuestro ataque no puede evadir VLANs. En otras palabras, según los experimentos actuales, nuestro ataque no se puede utilizar para explotar un dispositivo en otra VLAN.
El repositorio de otros resultados de nuestro USENIX Security '23 también está disponible.
La idea central detrás del ataque es que la forma en que se autentican los clientes no está relacionada con cómo se enrutan los paquetes al cliente Wi-Fi correcto. Es decir, la autenticación se realiza con base en contraseñas, nombres de usuario, identidades 802.1X y/o certificados, pero una vez que el cliente se ha conectado, el enrutamiento de paquetes se realiza con base en direcciones MAC. Un usuario interno malintencionado puede abusar de esto para interceptar datos dirigidos a un cliente Wi-Fi al desconectar a una víctima y luego conectarse bajo la dirección MAC de la víctima (usando las credenciales del adversario). Cualquier paquete que todavía estuviera en camino hacia la víctima, como datos de un sitio web que la víctima aún estaba cargando, ahora será recibido por el adversario en su lugar.
Más precisamente, el ataque consta de tres pasos:
Hacer que la víctima solicite datos: El adversario primero espera hasta que la víctima (cliente)
establezca una conexión Wi-Fi con el Punto de Acceso (AP) vulnerable. Suponemos que la víctima
enviará entonces una solicitud a un servidor en Internet. Por ejemplo, la víctima puede enviar una
solicitud HTTP al sitio web (en texto plano) example.com. El objetivo del adversario es
interceptar la respuesta que enviará el sitio web.
Conectarse bajo la dirección MAC de la víctima: Después de que la víctima solicite datos, por ejemplo
al enviar un paquete de solicitud HTTP, el adversario desconectará forzosamente a la víctima de la
red antes de que la respuesta llegue al
AP vulnerable. En nuestro ejemplo, esto significa que la víctima se desconecta antes de que la respuesta de
example.com llegue al AP. Una vez que la víctima está desconectada, el adversario suplanta
la dirección MAC de la víctima y el adversario se conectará a la red usando sus propias
credenciales. Esto significa que el adversario es un usuario interno malintencionado que puede conectarse usando sus propias
credenciales a la red, por ejemplo, usando su propio nombre de usuario y contraseña en una
red Wi-Fi empresarial.
Interceptar la respuesta: Una vez que el adversario se conectó bajo la dirección MAC de la víctima,
el AP asociará las claves de cifrado recién generadas del adversario con la dirección MAC de la víctima.
Como resultado, cuando la respuesta del servidor llegue a la red Wi-Fi, o cualquier tráfico entrante
hacia la víctima en general, el enrutador reenviará estos paquetes entrantes a la dirección MAC de la
víctima. En nuestro ejemplo, esto significa que la respuesta de example.com es reenviada por el enrutador
a la dirección MAC de la víctima. Sin embargo, el adversario ahora está usando esta dirección MAC. Esto significa que el
AP cifrará la respuesta usando las claves del adversario. En otras palabras, el adversario
ahora recibirá cualquier tráfico pendiente que todavía esté en camino hacia la víctima.
Señalamos que el tráfico interceptado puede estar protegido por cifrado de capas superiores, como TLS y HTTPS. No obstante, incluso si se utiliza cifrado de capas superiores, nuestro ataque aún revela la dirección IP con la que una víctima se está comunicando. Esto a su vez revela los sitios web que una víctima está visitando, lo que puede ser información sensible por sí misma.
Por defecto, el ataque no intercepta el tráfico enviado por la víctima, sino que solo puede interceptar el tráfico enviado hacia la víctima. Sin embargo, un adversario puede intentar ataques posteriores para también interceptar el tráfico enviado por la víctima. En particular, al interceptar una respuesta DNS dirigida a la víctima, el adversario puede suplantar una respuesta DNS e interceptar todo el tráfico IP tanto enviado hacia como enviado por la víctima.
Realizar el ataque anterior solo tiene sentido cuando el aislamiento de clientes está habilitado en la red objetivo. De lo contrario, si el aislamiento de clientes está deshabilitado, un usuario interno malintencionado puede simplemente atacar directamente a otros clientes usando técnicas como suplantación de ARP (consulte las pruebas de aislamiento de clientes).
El ataque es idéntico contra redes empresariales WPA1, WPA2 y WPA3. Esto se debe a que el ataque no explota ninguna propiedad criptográfica de Wi-Fi, sino que abusa de cómo una red determina a qué cliente deben enviarse, es decir, enrutarse, los paquetes.
Para obtener detalles adicionales sobre el ataque, consulte el ataque de anulación de contexto de seguridad (Sección 5) en nuestro artículo Framing Frames: Bypassing Wi-Fi Encryption by Manipulating Transmit Queues.
Para mitigar nuestro ataque, un AP puede impedir temporalmente que los clientes se conecten si están usando una dirección MAC que se conectó recientemente al AP. Esto impide que un adversario suplante una dirección MAC e intercepte tramas pendientes o en cola hacia una víctima. Cuando se pueda garantizar que el usuario detrás de una dirección MAC no ha cambiado, se puede permitir que el cliente se reconecte de inmediato. Tenga en cuenta que esta verificación debe realizarse en todos los AP que forman parte del mismo sistema de distribución, y más específicamente, en todos los AP entre los que los clientes pueden deambular (roaming) mientras mantienen su dirección IP actual.
Para reconocer de forma segura a los usuarios conectados recientemente, un AP puede almacenar una asignación entre la dirección MAC de un cliente y sus asociaciones de seguridad almacenadas en caché (por ejemplo, su PMK almacenado en caché). A un cliente se le puede permitir conectarse (o reconectarse) inmediatamente bajo una dirección MAC usada recientemente demostrando que posee la asociación de seguridad almacenada en caché vinculada a esta dirección MAC, por ejemplo, conectándose usando el PMK almacenado en caché correcto.
Cuando se usa multi-PSK, que también se conoce como PSK por estación o Identity PSK, el AP puede mantener una asignación de direcciones MAC conectadas recientemente y la contraseña (única) que usaron. Cuando un cliente se conecta, el AP verifica si su dirección MAC se usó recientemente. Si no es así, o si lo está y el cliente está usando la misma contraseña que antes, el cliente puede conectarse con normalidad. Sin embargo, si se usa la misma dirección MAC con una contraseña diferente, el cliente se ve obligado a esperar una cantidad de tiempo predefinida antes de poder conectarse exitosamente.
Cuando se usa SAE-PK para asegurar puntos de acceso públicos, el único método que conocemos para reconocer de forma segura que una dirección MAC está siendo reutilizada por el mismo usuario de antes, es confiar en las asociaciones de seguridad almacenadas en caché (por ejemplo, el PMK almacenado en caché vinculado a la dirección MAC).
Las defensas anteriores asumen que, después de un cierto retraso, no llegarán más paquetes pendientes para la víctima. Para prevenir fugas más allá de este retraso, los clientes pueden usar cifrado de extremo a extremo (como TLS) con los servicios con los que se comunican.
Cuando se utiliza autenticación basada en EAP 802.1X, un método alternativo mejor para reconocer de forma segura a los usuarios conectados recientemente se basa en la identidad EAP que usaron durante la autenticación 802.1X. Un AP puede aprender de forma segura la identidad EAP del servidor RADIUS que autenticó al cliente, y puede mantener una asignación de direcciones MAC conectadas recientemente y su identidad EAP correspondiente. Cuando un cliente se conecta, el AP verifica si su dirección MAC se usó recientemente. Si no es así, o si lo está y el cliente está usando la misma identidad EAP que antes, el cliente puede conectarse con normalidad. Sin embargo, si se usa la misma dirección MAC bajo una identidad EAP diferente, el cliente se ve obligado a esperar una cantidad de tiempo predefinida antes de poder conectarse exitosamente.
Un desafío es que el AP puede no saber siempre la identidad 802.1X de un cliente debido a preocupaciones de privacidad. Por ejemplo, esta información solo puede estar disponible en el servidor AAA local (home AAA server), y el AP solo recibirá una Identidad de Usuario Facturable (Chargeable User Identity) del servidor RADIUS. Esta identidad no permite al AP reconocer dos asociaciones del mismo dispositivo/credenciales porque su valor puede cambiar constantemente. El AP sí recibe la identidad anónima en el EAP-Response/Identity, como anonymous@realm, y puede confiar en ella para al menos reconocer usuarios de diferentes realms (dominios).
Para evitar que usuarios del mismo realm se ataquen entre sí, sin revelar la identidad de un cliente al AP, se necesitan cooperación y cambios en el servidor RADIUS. En particular, el servidor RADIUS puede actualizarse para ayudar a detectar si la dirección MAC estaba siendo usada recientemente por otro usuario en el mismo realm (en la red local dada). El servidor RADIUS tendría entonces que ser informado cuando un cliente se desconecta, para saber cuándo una dirección MAC fue usada por última vez por uno de sus usuarios, y necesita ser informado de la dirección MAC de cualquier cliente que intente conectarse.
Una última nota es que, aunque este enfoque de confiar en la identidad EAP evitaría que diferentes usuarios se ataquen entre sí, no evitaría que un dispositivo comprometido ataque a otro dispositivo de ese mismo usuario. Es decir, los ataques solo se evitarían entre diferentes usuarios, pero no entre diferentes dispositivos del mismo usuario.
Es importante tener en cuenta que nuestro ataque no se limita a interceptar paquetes dirigidos a clientes Wi-Fi. Un adversario también podría intentar asociarse con una dirección MAC de una puerta de enlace predeterminada u otro servidor en la red local. Para prevenir tales ataques, el AP o el controlador puede prohibir que los clientes usen una dirección MAC igual a la de la puerta de enlace predeterminada. Más generalmente, se puede usar la detección de direcciones MAC duplicadas cuando un cliente Wi-Fi se conecta a la red, para evitar que los clientes Wi-Fi usen una dirección MAC que también esté en uso por otros dispositivos en la red.
El uso de la Protección de tramas de gestión (MFP) haría que el ataque fuera más difícil pero no imposible. En trabajos anteriores, encontramos algunas formas en que los clientes pueden ser desconectados/desautenticados incluso cuando se usa MFP. Según esa experiencia, siempre parece haber algún método para desconectar forzosamente a un cliente de la red, incluso cuando se usa MFP. Dicho de otro modo, es difícil prevenir por completo los ataques de desconexión y desautenticación. Dicho esto, MFP sería un obstáculo adicional a superar al realizar el ataque en la práctica, por lo que puede ser una mitigación útil para hacer que el ataque sea más difícil (pero no imposible) en la práctica.
Según experimentos preliminares, el ataque no funciona a través de diferentes VLANs. En otras palabras, el usuario interno malintencionado que realiza el ataque debe estar en la misma VLAN que la víctima. Una mitigación es, por lo tanto, poner diferentes grupos de usuarios en diferentes VLANs. Sin embargo, un usuario interno malintencionado aún podría realizar el ataque (es decir, evadir el aislamiento de clientes) contra otros usuarios en la misma VLAN.
Tenga en cuenta que al usar multi-PSK (también conocido como PSK por estación o identity PSK), puede poner a los clientes en diferentes VLANs dependiendo de la contraseña que usen. En otras palabras, puede usar una VLAN para cada contraseña. Esto evita que los clientes con diferentes contraseñas se ataquen entre sí.
La herramienta MacStealer funciona con cualquier tarjeta de red compatible con Linux. Probamos MacStealer en Ubuntu 22.04. Para instalar las dependencias requeridas en Ubuntu 22.04, ejecute:
sudo apt update
sudo apt install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libssl-dev \
libdbus-1-dev git pkg-config build-essential net-tools python3-venv \
aircrack-ng rfkill
Ahora clone este repositorio, compile las herramientas y configure un entorno virtual de python3:
git clone https://github.com/vanhoefm/macstealer.git macstealer
cd macstealer/research
./build.sh
./pysetup.sh
Las instrucciones anteriores solo tienen que ejecutarse una vez.
Después de obtener nuevo código usando git, debe ejecutar ./build.sh y ./pysetup.sh nuevamente.
Consulte el registro de cambios para obtener una descripción detallada de las actualizaciones de MacStealer
desde que comenzó la divulgación coordinada.
Cada vez que quiera usar MacStealer, primero debe cargar el entorno virtual de python3 como root. Esto se puede hacer usando:
cd research
sudo su
source venv/bin/activate
Ahora debe deshabilitar Wi-Fi en su administrador de red
para que no interfiera con MacStealer. Opcionalmente, verifique con sudo airmon-ng check para ver
qué otros procesos podrían estar usando la tarjeta de red inalámbrica y podrían interferir con MacStealer.
El siguiente paso es editar client.conf con la información de la red que desea probar.
Esta es una configuración para wpa_supplicant
que debe contener dos bloques de red: uno que representa a la víctima y otro que representa al
atacante. Un archivo de configuración de ejemplo para probar la red ficticia kuleuven es:
# No cambie esta línea, de lo contrario MacStealer no funcionará
ctrl_interface=wpaspy_ctrl
network={
# No cambie este campo, el script depende de él
id_str="victim"
# Red a probar: complete las propiedades de la red a probar
ssid="kuleuven"
key_mgmt=WPA-EAP
eap=PEAP
phase2="auth=MSCHAPV2"
# Credenciales de la víctima: complete las credenciales de inicio de sesión que representan a la víctima
identity="[email protected]"
password="SuperSecret"
}
network={
# No cambie este campo, el script depende de él
id_str="attacker"
# Red a probar: puede copiarlo del bloque anterior
ssid="kuleuven"
key_mgmt=WPA-EAP
eap=PEAP
phase2="auth=MSCHAPV2"
# Credenciales del atacante: complete las credenciales de inicio de sesión que representan al atacante
identity="[email protected]"
password="SomePassword"
}
En la parte "red a probar" debe proporcionar el nombre de la red que se está probando y su configuración de seguridad. Consulte wpa_supplicant.conf para obtener documentación sobre cómo escribir/editar archivos de configuración y para ver ejemplos de bloques de red para varios tipos de redes Wi-Fi. En el primer bloque de red, bajo "credenciales de la víctima", debe especificar credenciales de inicio de sesión válidas que representen a la víctima simulada. En el segundo bloque de red, puede proporcionar exactamente la misma información en "red a probar", pero debe proporcionar credenciales de inicio de sesión que representen al atacante simulado.
En el ejemplo anterior, MacStealer probará un ataque donde el adversario es [email protected]
y este adversario intentará interceptar el tráfico enviado hacia la víctima [email protected].
Por defecto, el script usa el archivo de configuración client.conf. Puede usar un archivo
de configuración diferente proporcionando el parámetro --config network.conf, donde puede reemplazar
network.conf con el archivo de configuración que desee usar.
Este repositorio también contiene los siguientes archivos de configuración de ejemplo:
multipsk.conf: Un archivo de configuración para probar una red que
usa multi-PSK donde una contraseña es utilizada por dispositivos confiables y una segunda contraseña se
entrega a los invitados.
saepk.conf: Un archivo de configuración para probar un punto de acceso público que
usa SAE-PK.
Tenga en cuenta que también es posible editar el/los bloque(s) de red para probar un AP/BSS específico.
Por defecto, MacStealer enviará un paquete TCP SYN a 8.8.8.8 en el puerto 443 en todas las pruebas, que es un
servidor DNS de Google. Si desea usar un servidor o puerto diferente, puede proporcionarlo usando
el parámetro --server. Por ejemplo:
./macstealer.py wlan0 --server 208.67.222.222
También puede agregar el puerto que se debe usar en los paquetes TCP SYN:
./macstealer.py wlan0 --server 208.67.222.222:80
Reemplace wlan0 con el nombre de su interfaz Wi-Fi y la dirección IP con el servidor
que desee usar.
Este servidor debe retransmitir las respuestas TCP SYN/ACK y, idealmente, debe seguir enviando un SYN/ACK
retransmitido más de 10 segundos después de que MacStealer transmitió el TCP SYN inicial. Puede
probar este comportamiento de retransmisión usando el parámetro --ping de la siguiente manera:
./macstealer.py wlan0 --server 208.67.222.222 --ping
MacStealer mostrará lo siguiente en caso de que el servidor tenga el comportamiento de retransmisión requerido:
[22:53:15] Received SYN/ACK 15.265095233917236 seconds after sending SYN.
[22:53:20] >>> Ping test done, everything looks good so far. You can continue with other tests.
En caso de que el servidor proporcionado no envíe respuestas TCP SYN/ACK, o no las retransmita lo suficientemente tarde, MacStealer mostrará lo siguiente:[22:52:05] Received SYN/ACK 1.0727121829986572 seconds after sending SYN. [22:52:24] >>> Ping test done. Consider using a server that retransmits SYN/ACK for a longer time.
La razón por la que el servidor debe seguir retransmitiendo un SYN/ACK después de más de 10 segundos es porque a veces puede llevar varios segundos reconectarse como atacante simulado. Este proceso de reconexión debe completarse antes de que el servidor envíe el último paquete TCP SYN/ACK retransmitido.
La siguiente tabla contiene comandos comunes que ejecutarás al probar una red, junto con una breve descripción de lo que hace cada comando. Debajo de la tabla se explican los detalles de cada comando.
Si la red que se está probando usa Protección de tramas de gestión (802.11w), la herramienta asume que el adversario todavía puede desconectar por la fuerza a la víctima de la red. Esta suposición se basa en investigaciones recientes que mostraron que los ataques de desconexión suelen seguir siendo posibles, aunque menos directos o generales, cuando se usa MFP.
Antes de probar vulnerabilidades, puedes usar los siguientes comandos para confirmar que MacStealer puede conectarse a la red tanto como víctima como atacante:
./macstealer.py wlan0 --ping: se conecta a la red usando las credenciales de la víctima. Una vez conectado, se envía un SYN TCP al servidor (que por defecto es 8.8.8.8 y se puede cambiar). MacStealer comprobará si el SYN/ACK se (re)transmite y cuántas veces. Puedes usar esto para confirmar que las credenciales de la víctima son correctas y para verificar que el servidor configurado está retransmitiendo correctamente las respuestas SYN/ACK.
./macstealer.py wlan0 --ping --flip: Igual que la prueba anterior, pero ahora el script se conectará usando las credenciales del adversario. Puedes usar esto para confirmar que las credenciales del adversario son correctas.
./macstealer.py wlan0: Probar la variante predeterminada del ataque de robo de dirección MAC. El atacante se reconectará al mismo AP/BSS que la víctima.
./macstealer.py wlan0 --other-bss: El atacante se conectará a un AP/BSS diferente de la misma red. Una red que también sea vulnerable a esta prueba es más fácil de explotar en la práctica. Si solo hay un único AP/BSS dentro del alcance de radio, el script agotará el tiempo de espera al conectarse como atacante.
Explotar la vulnerabilidad de robo de dirección MAC solo tiene sentido si el aislamiento de clientes está habilitado o cuando se usan técnicas como la inspección ARP para evitar que los clientes se ataquen entre sí. De lo contrario, un adversario puede usar ataques más fáciles como el envenenamiento ARP para interceptar el tráfico. Para probar si el aislamiento de clientes está habilitado o si la red usa inspección ARP, puedes usar los siguientes comandos:
./macstealer.py wlan0 --c2c wlan1: Con estos argumentos, MacStealer prueba si la red permite el tráfico de envenenamiento ARP de cliente a cliente desde el atacante (wlan1) hacia la víctima (wlan0). Aquí wlan1 es una segunda interfaz de red inalámbrica. El script probará entonces si se pueden enviar paquetes ARP maliciosos desde el atacante a la víctima.
./macstealer.py wlan0 --c2c-eth wlan1: Esto es similar a la prueba anterior, pero en lugar de enviar paquetes ARP maliciosos, el atacante enviará paquetes DNS a la víctima.
La vulnerabilidad de robo de dirección MAC debe considerarse un riesgo en la práctica si el tráfico de cliente a cliente se bloquea en cualquiera de las dos pruebas anteriores (es decir, cuando el aislamiento de clientes está habilitado o cuando se usan otras técnicas como la inspección ARP para evitar que los usuarios se ataquen entre sí).
Por defecto, MacStealer intentará conectarse al mismo AP/BSS usando ambas interfaces, por lo que es importante que ambas tarjetas de red puedan ver las mismas redes (es decir, asegúrate de que ambas interfaces de red admitan las mismas bandas de frecuencia y canales). Si quieres que ambos clientes se conecten a un AP/BSS diferente, puedes usar el parámetro --other-bss.
Puedes usar el parámetro --flip-id para probar si se permite el tráfico desde la víctima (wlan0) hacia el atacante (wlan1).
Si MacStealer no parece funcionar, comprueba lo siguiente:
Comprueba que ningún otro proceso esté usando la tarjeta de red (por ejemplo, cierra tu administrador de red). Puede que veas la salida kernel reports: match already configured si otro proceso también está usando la tarjeta de red.
Si todo funcionaba anteriormente, intenta desconectar tu adaptador Wi-Fi, reiniciar tu computadora o máquina virtual, y luego inténtalo de nuevo.
Confirma que te estás conectando a la red correcta. Verifica dos veces client.conf.
Si actualizaste el código usando git, ejecuta ./build.sh y ./pysetup.sh nuevamente (consulta Prerrequisitos).
Si estás usando una máquina virtual, intenta ejecutar MacStealer desde una instalación nativa de Linux.
Ejecuta MacStealer con el parámetro extra -dd para obtener salida de depuración adicional de wpa_supplicant y del propio MacStealer.
Las pruebas de aislamiento de clientes predeterminadas comprobarán si se permite el tráfico en la capa Ethernet entre clientes. También es posible probar si se permite el tráfico en la capa IP entre clientes usando el siguiente comando:
./macstealer.py wlan0 --c2c-ip wlan1 [--flip-id]
Cuando se permite el tráfico de capa IP entre clientes, todavía es posible que los clientes se ataquen entre sí. Por ejemplo, los ataques de redirección ICMP pueden seguir siendo posibles. Estos ataques son más engorrosos que el envenenamiento ARP, pero idealmente deberían prevenirse bloqueando también el tráfico de capa IP entre clientes.
Las siguientes pruebas se pueden ejecutar para probar propiedades generales de una red. Estas pruebas no están directamente relacionadas con vulnerabilidades, pero pueden usarse para comprender mejor el comportamiento de una red.
./macstealer.py wlan0 --same-id [--other-bss] [--flip]: Prueba si las conexiones TCP permanecen activas después de desconectarse y reconectarse a un punto de acceso. Si las conexiones no permanecen activas después de reconectarse, es probable que la red no sea vulnerable a los ataques de robo de dirección MAC. Sin embargo, una gran desventaja de este comportamiento es que los clientes legítimos tienen que abrir nuevas conexiones TCP cada vez que se reconectan a esta red, lo que hace que la red parezca lenta y poco fiable (por lo que debería usarse una mejor defensa).
Puedes usar el parámetro --other-bss para reconectarte a un AP/BSS diferente de la misma red.
Puedes usar el argumento --flip para realizar esta prueba con la identidad del atacante en lugar de la de la víctima.
./macstealer.py wlan0 --flip: Prueba el ataque normal de robo de dirección MAC, pero intercambia el rol del atacante y la víctima. En otras palabras, el atacante usará las "credenciales de víctima" proporcionadas en el archivo de configuración, y la víctima usará las "credenciales de adversario".
./macstealer.py wlan0 --c2c wlan1 --same-id [--flid-id]: Prueba si se permite el tráfico de cliente a cliente entre dos dispositivos del mismo usuario. Consulta las pruebas de aislamiento de clientes para obtener documentación sobre el parámetro wlan1.
Puedes usar el argumento --flip para realizar esta prueba con la identidad del atacante en lugar de la de la víctima.
--delay seconds: Puedes usar el parámetro --delay para especificar un retraso, en segundos, antes de reconectarte como atacante.
-d o -dd: Agregar uno de estos parámetros aumenta la verbosidad de depuración del script y de la instancia subyacente de wpa_supplicant.
Por defecto, MacStealer seleccionará automáticamente un AP/BSS de la red para conectarse y probar. Si tienes una red con múltiples AP/BSS, puedes probar uno específico especificando este AP/BSS en el bloque de red de la víctima usando la palabra clave bssid. Por ejemplo, puedes usar:
...
network={
# Don't change this field, the script relies on it
id_str="victim"
# Network to test: fill in properties of the network to test
ssid="kuleuven"
key_mgmt=WPA-EAP
eap=PEAP
phase2="auth=MSCHAPV2"
# Victim login: fill in login credentials representing the victim
identity="[email protected]"
password="SuperSecret"
# This a specific AP/BSS
bssid=00:11:22:33:44:55
}
...
Con la configuración anterior, MacStealer probará 00:11:22:33:44:55. Esto significa que se conectará tanto como víctima y como atacante a este AP.
También puedes combinar esto con el parámetro --other-bss. En ese caso, la víctima se conectará a 00:11:22:33:44:55, y el atacante se conectará a un AP/BSS diferente de la misma red.
Otra opción es especificar un BSS/AP explícito en el bloque de red de la víctima y del atacante.
Ten en cuenta que MacStealer buscará el AP/BSS indicado durante un máximo de 30 segundos. Si no puede encontrar el AP/BSS especificado, la herramienta se cerrará.
Puedes probar una red SAE-PK usando el siguiente archivo de configuración. Ten en cuenta que, en las redes SAE-PK, no hay diferencia en cómo se autentican la víctima y el atacante, es decir, ambos usan la misma contraseña.
# Don't change this line, other MacStealer won't work
ctrl_interface=wpaspy_ctrl
# WPA3/SAE: support both hunting-and-pecking loop and hash-to-element
sae_pwe=2
network={
# Don't change this field, the script relies on it
id_str="attacker"
# Network to test - attacker login
ssid="test-saepk"
psk="7iip-ytnz-qa25"
key_mgmt=SAE
ieee80211w=2
}
network={
# Don't change this field, the script relies on it
id_str="victim"
# Network to test - victim login
ssid="test-saepk"
psk="7iip-ytnz-qa25"
key_mgmt=SAE
ieee80211w=2
}
En la práctica, el aislamiento de clientes también se usa en redes protegidas con una contraseña precompartida. Por ejemplo, varios routers tienen una opción para crear una red para invitados o dispositivos (IoT) inseguros, donde los clientes de esta red están aislados para que no puedan atacarse entre sí. Sin embargo, la ventaja de seguridad de usar el aislamiento de clientes en este escenario puede cuestionarse. Se supone que el aislamiento de clientes evita que un interno malicioso ataque a otros. Pero si el interno malicioso conoce la contraseña precompartida, puede crear un clon falso (gemelo malvado), engañar a las víctimas para que se conecten a esta copia maliciosa de la red y, ¡entonces, atacar a otros clientes! En otras palabras, usar el aislamiento de clientes en una red protegida con contraseña no proporciona una seguridad sólida, un cliente malicioso puede crear un AP falso para seguir atacando a otros clientes.
Dicho esto, se puede argumentar que la creación de un AP falso puede ser detectada por el administrador de la red, lo que significa que el aislamiento de clientes sí dificulta los ataques. Además, cuando un dispositivo ligero se ve comprometido (de forma remota), es posible que no tenga los recursos para actuar (fácilmente) como un AP falso. Esto hace que sea más difícil, pero no imposible, realizar ataques cuando se usa el aislamiento de clientes. En general, aunque el aislamiento de clientes no proporciona garantías de seguridad sólidas en una red protegida con contraseña, se puede argumentar que aumenta la dificultad práctica de realizar ataques.
Nuestro ataque MacStealing es más fácil de realizar que crear un AP falso. Todo lo que el interno malicioso, por ejemplo, un dispositivo IoT ligero comprometido, necesita hacer es falsificar una dirección MAC y (re)conectarse a la red. Este ataque también es más difícil de detectar. Con base en esta observación, nuestro nuevo ataque empeora la situación y, por lo tanto, se puede argumentar que nuestro ataque también debe considerarse relevante en redes protegidas con una contraseña precompartida.
Conclusión: al usar el aislamiento de clientes en una red protegida con contraseña, estás asumiendo que un interno malicioso no creará un AP falso. De lo contrario, el uso del aislamiento de clientes es sin sentido desde una perspectiva de seguridad. El ataque MacStealing puede realizarse sin crear un AP falso y, por lo tanto, facilita los ataques.
El objetivo de nuestro ataque no es evadir las listas de denegación/permitidos de direcciones MAC en los puntos de acceso. Falsificar direcciones MAC para evadir el filtrado de direcciones MAC es un ataque diferente y conocido.
El objetivo de nuestro ataque no es secuestrar la conexión de pago de alguien en los puntos de acceso Wi-Fi. Por ejemplo, algunos puntos de acceso abiertos (o protegidos) requieren que el usuario pague antes de permitirle acceder a Internet. A menudo, un suscriptor que paga es reconocido por su dirección MAC, y un adversario puede falsificar la dirección MAC de una víctima para obtener acceso a Internet. Este no es el propósito de nuestro ataque; el objetivo de MacStealer es evadir el aislamiento de clientes.
Nuestro ataque también afecta a las redes que se defienden contra la vulnerabilidad Hole 196. Por ejemplo, las redes Passpoint (anteriormente Hotspot 2.0) deben prevenir la vulnerabilidad Hole 196, pero siguen siendo vulnerables a nuestro ataque.
Nuestro ataque funciona en redes que se defienden contra el envenenamiento ARP. En redes Wi-Fi mal aseguradas, un adversario puede realizar trivialmente un envenenamiento ARP para interceptar el tráfico de una víctima, y nuestro ataque no es realmente práctico. Sin embargo, las redes modernas, que pueden tener internos maliciosos, dependen del aislamiento de clientes u otros métodos para prevenir ataques de máquina en el medio. Nuestro atacante evita todas estas defensas modernas y aún permite que un adversario intercepte el tráfico hacia una víctima.
En resumen, nuestro ataque afecta a las redes Wi-Fi donde se impide que los clientes se ataquen entre sí, lo que permite a un adversario interceptar el tráfico hacia otro cliente.
La mayoría de los proveedores usan CVE-2022-47522 para referirse a la vulnerabilidad de evasión del aislamiento de clientes Wi-Fi que se analiza en este repositorio de git. Esta vulnerabilidad corresponde al ataque de la Sección 5 de nuestro artículo.
Desafortunadamente, otros proveedores también usan este CVE para referirse a la vulnerabilidad (estrictamente hablando, no relacionada) que se analiza en la Sección 3 de nuestro artículo. De hecho, la descripción real del CVE, como se puede encontrar en MITRE, en nuestra opinión, solo describe el ataque de la Sección 3 de nuestro artículo. En la práctica, parece que CVE-2022-47522 se usa para referirse a todos los ataques de nuestro artículo, aunque técnicamente son diferentes.
Versión 1.2 (en progreso)
README mejorado: se aclaró el uso del identificador CVE.
README mejorado: se centró la introducción en la evasión del aislamiento de clientes, se actualizaron las defensas con observaciones sobre 802.1X y sobre cómo evitar el robo de la dirección MAC de la puerta de enlace predeterminada.
Se añadió el parámetro --delay para especificar un retraso en segundos antes de reconectarse como atacante.
Versión 1.1 (18 de enero de 2023)
Por defecto, usar 8.8.8.8 como servidor en lugar de 216.58.208.100 (ambos son servidores de Google).
Pruebas de aislamiento de clientes actualizadas: por defecto, se prueba usando envenenamiento ARP en la capa Ethernet. También se ofrece la opción de enviar datos UDP con reenvío en la capa Ethernet, y una prueba con reenvío en la capa IP.
README mejorado: se actualizaron los tipos de red que pueden verse afectados. Se incluyó un análisis sobre si las redes WPA2 o WPA3 protegidas con contraseña se ven afectadas. Explicación de los diferentes comandos para probar el tráfico de capa Ethernet o IP de cliente a cliente.
README mejorado: análisis de MFP, análisis de las VLAN como mitigación, aclaración sobre qué APs debe realizarse la comprobación de identidad, especificación del puerto del servidor,
Salida mejorada de MacStealer.
Versión 1.0 (3 de enero de 2023):
| Comando | Descripción breve |
|---|
./macstealer.py wlan0 --ping | Conectar como víctima y probar el comportamiento de retransmisión del servidor. |
./macstealer.py wlan0 --ping --flip | Conectar como atacante y probar el comportamiento de retransmisión del servidor. |
./macstealer.py wlan0 | Probar la variante predeterminada del ataque de robo de dirección MAC. |
./macstealer.py wlan0 --other-bss | Permitir que el atacante se conecte con un AP diferente al de la víctima. |
./macstealer.py wlan0 --c2c wlan1 | Probar el tráfico de capa Ethernet de cliente a cliente (envenenamiento ARP). |
./macstealer.py wlan0 --c2c-eth wlan1 | Probar el tráfico de capa Ethernet de cliente a cliente (DNS). |