vanhoefm/fragattacksProbador automatizado de vulnerabilidades para clientes Wi-Fi y puntos de acceso, que detecta fallos de fragmentación/agregación de FragAttacks mediante inyección de tramas, pruebas de modo mixto y análisis de captura de paquetes.
Este repositorio contiene la herramienta FragAttacks. Puede probar clientes Wi-Fi y puntos de acceso contra ataques de fragmentación y agregación. Estas vulnerabilidades afectan a todas las redes Wi-Fi protegidas. Para obtener más información sobre estas vulnerabilidades, consulte fragattacks.com.
Los siguientes recursos adicionales están disponibles:
Consulte el registro de cambios para obtener una visión detallada de las actualizaciones de la herramienta realizadas desde el 11 de agosto de 2020. Este registro de cambios también contiene información sobre la versión de hostap en la que se basa la herramienta FragAttacks.
Ten en cuenta que los ataques son idénticos contra WPA2 y WPA3 porque sus cifrados de cifrado CCMP y GCMP son idénticos. Las redes WPA más antiguas usan TKIP por defecto para el cifrado, y la aplicabilidad de los ataques contra TKIP se analiza en el artículo y en el sitio web. Para ilustrar que el Wi-Fi ha sido vulnerable desde su creación, el artículo y el sitio web también analizan brevemente la aplicabilidad de los ataques contra WEP.
Solo se admiten tarjetas de red inalámbricas específicas. Esto se debe a que algunas tarjetas de red pueden sobrescribir el número de secuencia o de fragmento de las tramas inyectadas, o pueden reordenar tramas de diferente prioridad, y esto interfiere con la herramienta de prueba (es decir, la herramienta podría indicar que un dispositivo es seguro cuando no lo es). He confirmado que las siguientes tarjetas de red funcionan correctamente:
Las dos últimas columnas significan:
Modo mixto: si la tarjeta de red puede usarse en el modo mixto recomendado.
Modo de inyección: si la tarjeta de red puede usarse como segunda interfaz para inyectar tramas en el modo de inyección.
Sí indica que la tarjeta funciona directamente en el modo indicado. Controlador/firmware parcheado significa que la tarjeta es compatible cuando se utilizan controladores y/o firmware parcheados. No significa que este modo no es compatible con la tarjeta de red. Recomiendo usar la herramienta de prueba en modo mixto.
Ten en cuenta que los dispositivos USB pueden usarse dentro de una máquina virtual, y los controladores y/o firmware modificados pueden instalarse en esa máquina virtual. Sin embargo, he observado que el uso de máquinas virtuales puede hacer que las tarjetas de red sean menos fiables, y en su lugar recomiendo usar una imagen USB en vivo si no puedes instalar los controladores/firmware modificados de forma nativa.
Mi experiencia con las tarjetas de red anteriores se puede encontrar aquí. En resumen:
La AWUS036ACM en modo mixto parece fiable con nuestros últimos controladores y es la que recomiendo. Un dispositivo más barato pero casi idéntico es uno con un chipset MT7612U. Consulta más información aquí.
Anteriormente recomendaba la Technoethical N150 HGA en modo mixto. Este adaptador es idéntico a la TP-Link TL-WN722N v1.x y requiere el uso de controladores y firmware parcheados. Es uno de los adaptadores mejor probados, pero es difícil de conseguir. Por eso ahora recomiendo la AWUS036ACM en su lugar.
Las Intel 3160 y 8265 son compatibles y han sido probadas exhaustivamente. A veces su firmware fallaba, pero un reinicio hace que la tarjeta de red vuelva a funcionar. La Intel AX200 no es compatible con la herramienta de prueba.
La WN111v2 parece funcionar bien, aunque no la probé exhaustivamente.
El controlador para la AWUS036ACH no forma parte del kernel de Linux y requiere la instalación de un controlador separado. En Kali puedes instalar este controlador a través del gestor de paquetes. Esta tarjeta no fue probada exhaustivamente.
Si no puedes encontrar una de las tarjetas de red anteriores, puedes buscar tarjetas de red alternativas que tengan muchas probabilidades de funcionar también. Cuando uses una tarjeta de red que no sea explícitamente compatible, recomiendo encarecidamente ejecutar primero las pruebas de inyección antes de usarla, y usar la herramienta contra una implementación conocida por ser vulnerable para confirmar que la herramienta funciona correctamente.
La herramienta de prueba se probó en Ubuntu 20.04 con el kernel 5.8. Si usas otra distribución de Linux, ten en cuenta que solo se admiten versiones de kernel menores o iguales a 5.12.
Cuando uses Ubuntu 20.04, primero tendrás que instalar el kernel 5.8 de la siguiente manera. Ten en cuenta que tu kernel actual seguirá instalado y también se seguirá usando por defecto:
sudo apt install linux-image-5.8.0-63-generic linux-headers-5.8.0-63-generic linux-hwe-5.8-headers-5.8.0-63 \
linux-modules-5.8.0-63-generic linux-modules-extra-5.8.0-63-generic
Ahora reinicia Ubuntu, mantén pulsada la tecla Shift durante el arranque, selecciona "Opciones avanzadas para Ubuntu" y luego inicia el kernel 5.8 eligiendo "Ubuntu, con Linux 5.8.0-63-generic". Puedes editar tu configuración de GRUB para que Ubuntu use esta versión del kernel por defecto. Continúa con las siguientes instrucciones con este kernel ya en ejecución.
Instala las dependencias necesarias:
sudo apt-get update
sudo apt-get install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libssl-dev \
libdbus-1-dev git pkg-config build-essential macchanger net-tools python3-venv \
aircrack-ng rfkill firmware-ath9k-htc
# Note: on Kali linux use the package firmware-atheros instead of firmware-ath9k-htc
Ahora clona este repositorio, compila las herramientas y configura un entorno virtual de python3:
git clone https://github.com/vanhoefm/fragattacks.git fragattacks
cd fragattacks/research
./build.sh
./pysetup.sh
Las instrucciones anteriores solo tienen que ejecutarse una vez. Después de obtener código nuevo mediante git,
tendrás que ejecutar ./build.sh y ./pysetup.sh de nuevo.
Instala los controladores parcheados usando:
sudo apt-get install bison flex linux-headers-$(uname -r)
git clone https://github.com/vanhoefm/fragattacks-drivers58.git fragattacks-drivers58
cd fragattacks-drivers58
make defconfig-wifi
make -j 4
sudo make install
Esto compila los controladores para la mayoría de las tarjetas de red compatibles con Linux. Si solo quieres compilar
los controladores para las tarjetas de red que probé explícitamente, usa make defconfig-experiments en su lugar.
Puede que aparezcan las siguientes advertencias:
make defconfig-wifi pueden aparecer advertencias relacionadas con -Wyacc y -Wformat-overflow.
Puedes ignorar estas advertencias siempre que los controladores se compilen correctamente... needs unknown symbol ... Puedes ignorar estas advertencias siempre que
no contengan el directorio /lib/modules/*/updates/ y que los controladores compilados funcionen.SSL error y el comando sign-file. Esto significa que la firma digital
de los módulos del kernel ha fallado. Por lo general, puedes ignorarlo.cat /sys/module/mac80211/parameters/fragattack_version
después de un reinicio. Si este archivo existe, los controladores modificados se instalaron correctamente.Ahora instala el firmware ath9k_htc parcheado:
cd research/ath9k-firmware/
./install.sh
# Now reboot
El script ./install.sh asume que las imágenes del firmware ath9k_htc se encuentran en el
directorio /lib/firmware/ath9k_htc. Si este no es el caso en tu sistema, tienes
que copiar manualmente htc_7010.fw y htc_9271.fw al directorio adecuado.
Después de instalar los controladores y el firmware parcheados, debes desconectar tus adaptadores Wi-Fi y reiniciar tu sistema. Las instrucciones anteriores deben ejecutarse de nuevo si tu kernel de Linux se actualiza o si los controladores parcheados se actualizan.
Ten en cuenta que incluso si tu dispositivo funciona directamente, sigo recomendando instalar los controladores modificados, ya que esto asegura que no haya regresiones inesperadas en el código del kernel y de los controladores.
En caso de que no puedas instalar los controladores/firmware modificados de forma nativa, puedes descargar una imagen USB en vivo que contiene los controladores/firmware modificados junto con nuestra herramienta de prueba. Alternativamente, puedes usar una máquina virtual con tarjetas de red USB, aunque he observado que usar una máquina virtual es menos fiable en la práctica.
Cada vez que quieras usar la herramienta de prueba, primero tienes que cargar el entorno virtual de python como root. Esto se puede hacer usando:
cd research
sudo su
source venv/bin/activate
Ahora deberías desactivar el Wi-Fi en tu gestor de red
para que no interfiera con la herramienta de prueba. Asegúrate también de que ningún otro servicio de red esté generando
tráfico saliente. Puedes asegurarlo usando iptables para bloquear el tráfico ejecutando ./droptraffic.sh
(puedes revertirlo reiniciando). Opcionalmente, ejecuta sudo airmon-ng check para ver qué otros
procesos podrían estar usando la tarjeta de red inalámbrica y podrían interferir con nuestra herramienta.
La herramienta de prueba puede probar tanto clientes como AP:
Probar AP: configura el AP que quieres probar editando research/client.conf. Este es un
archivo de configuración estándar de wpa_supplicant; consulta la documentación de hostap
para obtener una visión general de todas las opciones que admite.
Probar clientes: debes ejecutar la herramienta de prueba con el parámetro --ap (ver más abajo). Esto
le indica a la herramienta que cree un AP con el nombre testnetwork y la contraseña abcdefgh. Conecta
a esta red con el cliente que quieras probar. Por defecto, el cliente debe solicitar una IP
mediante DHCP. Para editar las propiedades del AP creado, como el canal en el que se crea, puedes
editar research/hostapd.conf.
Este modo requiere solo una tarjeta de red inalámbrica, pero generalmente requiere un controlador y/o firmware parcheado. Consulta Controladores parcheados sobre cómo instalar controladores/firmware parcheados, y Tarjetas de red compatibles para ver las tarjetas de red compatibles. Ejecuta la herramienta de prueba en este modo usando:
./fragattack.py wlan0 [--ap] $COMMAND
Los posibles valores de $COMMAND se enumeran en pruebas de vulnerabilidades
y en pruebas ampliadas de vulnerabilidades.
Una ventaja de este modo es que funciona bastante bien al probar clientes que pueden entrar en estado de suspensión. No obstante, si es posible, recomiendo desactivar la funcionalidad de suspensión del cliente que se está probando; consulta Gestión del modo de suspensión.
Este modo requiere dos tarjetas de red inalámbricas: una actuará como AP o como cliente, y la otra se utilizará para inyectar tramas. La ventaja es que este modo puede funcionar sin requerir controladores parcheados. Ejecuta la herramienta de prueba en este modo usando:
./fragattack.py wlan0 --inject wlan1 [--ap] $COMMAND
Aquí la interfaz wlan0 actuará como un cliente o AP legítimo, y wlan1 se utilizará para inyectar tramas. Para wlan0, se puede usar cualquier tarjeta que admita el modo cliente o AP normal en Linux. Para wlan1, se debe usar una tarjeta que admita el modo de inyección según Tarjetas de red compatibles.
Al probar clientes en este modo, las tramas inyectadas pueden enviarse cuando el cliente está en estado de suspensión. Esto hace que los ataques fallen, por lo que debes asegurarte de que el cliente no entre en estado de suspensión.
Este modo es experimental y solo tiene fines de investigación. Consulta detalles del modo hwsim para obtener más información.
Puedes probar dispositivos ejecutando la herramienta de prueba como se explica en modos de interfaz
y reemplazando $COMMAND por uno de los comandos de la tabla siguiente. Asumimos que los clientes
solicitarán una IP mediante DHCP (si no es el caso, consulta configuración de IP estática).
Todos los comandos funcionan tanto contra clientes como contra AP, salvo que se indique lo contrario.
La herramienta muestra TEST COMPLETED SUCCESSFULLY si el dispositivo es vulnerable al ataque correspondiente
al $COMMAND dado, y muestra Test timed out! Retry to be sure, or manually check result si
el dispositivo no es vulnerable. Después de que la prueba haya terminado, puedes cerrar la herramienta con CTRL+C.
La mayoría de los ataques tienen varias variantes ligeras representadas por diferentes valores de $COMMAND.
Verificar el resultado de algunas pruebas requiere ejecutar tcpdump o wireshark en el dispositivo bajo prueba (la tabla siguiente indica si hay que usar tcpdump). Esta captura de paquetes con tcpdump solo debe incluir paquetes que hayan superado el procesamiento de la capa PHY y MAC. Por ejemplo, en Linux esta captura debe realizarse mientras la interfaz inalámbrica está en modo "managed" o "ap", no en modo monitor, lo que significa que la captura solo contendrá paquetes que superaron el procesamiento en la capa Wi-Fi. Consulta evitar tcpdump en AP para una discusión sobre cómo algunas pruebas pueden realizarse sin tener que ejecutar tcpdump en los AP.
Para verificar tu configuración de prueba, el primer comando en la tabla siguiente realiza un ping normal que debe ser exitoso. El segundo comando envía el ping como dos tramas Wi-Fi fragmentadas, y solo debería fallar en el raro caso de que el dispositivo probado no admita la fragmentación. Si alguna de estas pruebas no funciona, sigue las instrucciones en prueba de inyección de tarjeta de red para asegurarte de que tu tarjeta de red esté inyectando tramas correctamente. Si el cliente que se está probando puede entrar en modo de suspensión, consulta Gestión del modo de suspensión.
El tercer, cuarto y quinto comandos no son ataques, sino que verifican el comportamiento básico de desfragmentación de un dispositivo y se analizan más adelante, debajo de la tabla.
Cómo se corresponden los comandos con los CVE se enumera a continuación. Ten en cuenta que para fallos de implementación enumeramos un identificador CVE de referencia; sin embargo, los proveedores pueden usar CVE diferentes porque una vulnerabilidad de implementación normalmente recibe un CVE único para cada código afectado. No obstante, recomendamos referirse siempre a estos CVE de referencia como una forma de referirse fácilmente a cada tipo de fallo de implementación descubierto.
ping: Esta prueba siempre debe tener éxito. Si falla, algo está mal con la configuración de la prueba.- ping I,E,E: Esta prueba debería funcionar con todos los portátiles, teléfonos inteligentes y AP modernos. Si falla,
probablemente algo anda mal con la configuración de la prueba. Intente agregar el parámetro --icmp-size 100 como solución. Si
funciona con este parámetro adicional, debe ejecutar todas las demás pruebas con este parámetro adicional también.
La única vez que encontré que esta prueba fallaba por razones válidas es cuando el dispositivo probado no admite
recibir tramas fragmentadas, lo cual puede ser el caso en dispositivos IoT ligeros y, por ejemplo, OpenBSD.ping I,E,E --delay 5: Esta prueba se utiliza para comprobar el retardo máximo aceptado entre dos fragmentos.
Si esta prueba no funciona, inténtelo de nuevo con --delay 1.5 o menos. Por ejemplo, Linux elimina los fragmentos
de la memoria después de 2 segundos, lo que significa que un retardo de 1.8 funcionará mientras que 2.2 dará como resultado ninguna respuesta. En caso de que el retardo
máximo aceptado sea bajo, todos los fragmentos enviados en otras pruebas deben enviarse dentro de ese retardo máximo aceptado.
De lo contrario, las pruebas fallarán trivialmente y podría concluir que un dispositivo no es vulnerable a un ataque aunque
en realidad sí lo es.
ping-frag-sep: Esta prueba envía una trama Wi-Fi fragmentada que está separada por una trama no relacionada.
Es decir, envía el primer fragmento, luego una trama Wi-Fi (normal) no relacionada y, finalmente, el segundo fragmento.
Si esta prueba falla, el ataque de clave mixta (predeterminado) y el ataque de caché probablemente también fallarán (ya que requieren
enviar otras tramas entre dos fragmentos). Esta prueba también fallará si el receptor comprueba si los fragmentos
tienen números de paquete consecutivos (ver la siguiente prueba ping-frag-sep --pn-per-qos).
ping-frag-sep --pn-per-qos: Igual que la anterior, pero agregar el parámetro --pn-per-qos asegura que ambos fragmentos
de la solicitud de ping tengan un Número de Paquete (PN) consecutivo. Esto es algo que un receptor debería estar
verificando para ser seguro. Desafortunadamente, antes de la divulgación de nuestros resultados, muchas implementaciones
no verifican si los PN son consecutivos. Esta prueba podría fallar si el receptor no realiza un seguimiento del último
contador de paquetes recibido por TID de QoS, en cuyo caso puede ignorar otras pruebas que contengan el parámetro .
La prueba ping I,E --amsdu comprueba si una implementación admite A-MSDU que no sean SPP (no comprueba si el dispositivo
es vulnerable a CVE-2020-24588). Para prevenir ataques, idealmente
la red debe exigir el uso de A-MSDU SPP y descartar todos los A-MSDU que no sean SPP. Sin embargo, la mayoría de los fabricantes están
implementando actualmente mitigaciones ad hoc en su lugar (ver Sección 7.2 del artículo). Debido a esto, debe usar
las siguientes dos pruebas para comprobar si un dispositivo es vulnerable a ataques de agregación (A-MSDU) (CVE-2020-24588):
amsdu-inject: Esta prueba simula el ataque de inyección A-MSDU descrito en la Sección 3.2 del artículo. En particular,
envía una trama A-MSDU cuyo inicio también es un encabezado LLC/SNAP válido (ya que esto es también lo que ocurre en nuestro ataque
de referencia). Si esta prueba tiene éxito, el dispositivo es vulnerable a CVE-2020-24588.
amsdu-inject-bad: Algunos dispositivos analizan incorrectamente las tramas A-MSDU que comienzan con un encabezado LLC/SNAP válido, lo que hace que la
prueba anterior falle. En ese caso, pruebe amsdu-inject-bad en su lugar (ver Sección 3.6 del artículo). Tenga en cuenta que si esta prueba
tiene éxito, el impacto del ataque es efectivamente idéntico al de las implementaciones que analizan correctamente dichas tramas,
lo que significa que el dispositivo es vulnerable a CVE-2020-24588.
Al ejecutar la prueba de clave mixta contra un AP, el AP debe estar configurado para renovar regularmente (p. ej., cada minuto)
la clave de sesión (PTK) ejecutando un nuevo handshake de 4 vías. La herramienta mostrará
Client cannot force rekey. Waiting on AP to start PTK rekey mientras espera este handshake de renovación de PTK.
Con un número reducido de AP, la herramienta de prueba también puede solicitar la renovación del PTK agregando el parámetro --rekey-req,
lo que significa que no es necesario configurar el AP para renovar la clave periódicamente.
Algunos AP no se pueden configurar para renovar regularmente la clave de sesión (PTK). Contra estos AP puede en su lugar probar un ataque de caché. Si el AP es vulnerable a ataques de caché, entonces es probable que también sea vulnerable a ataques de clave mixta (a menos que exista evidencia sólida que contradiga esto, p. ej., una auditoría de código indique que los ataques de clave mixta están prevenidos). Si el AP no es vulnerable a ataques de caché, entonces no podemos decir nada sobre su susceptibilidad a los ataques de clave mixta, y en ese caso recomiendo hacer una auditoría de código en su lugar.
ping I,F,BE,AE --pn-per-qos: El parámetro adicional --pn-per-qos asegura que ambos fragmentos inyectados tengan
números de paquete consecutivos, lo cual es necesario para que el ataque de clave mixta tenga éxito contra ciertos dispositivos
(p. ej., contra Linux).
Varios dispositivos implementan el handshake de 4 vías de manera diferente y esto afectará si estas pruebas tienen éxito o no. Si las pruebas fallan, se recomienda también realizar las pruebas de ataque de clave mixta enumeradas en Pruebas de vulnerabilidad extendidas.
Al probar un AP, la herramienta envía un primer fragmento, luego intenta reasociarse con el AP y, finalmente,
envía el segundo fragmento. Sin embargo, no todos los AP admiten correctamente el proceso de reasociación. En ese caso,
agregue la opción --full-reconnect como se muestra en la tabla, lo que hace que la herramienta de prueba desautentique
después de enviar el primer fragmento.
Al probar un cliente, la herramienta envía un primer fragmento, desasocia al cliente y, una vez que el cliente
se ha reconectado, envía el segundo fragmento. Idealmente, el cliente se reconectará inmediatamente después de enviar
la trama de desasociación. Esto puede requerir deshabilitar todas las demás redes en el cliente que se está probando. También
descubrí que algunos clientes no parecen manejar correctamente la desasociación, y en ese caso puede agregar la
opción --full-reconnect como se muestra en la tabla para enviar una trama de desautenticación en su lugar.
He descubierto que es mejor ejecutar cada prueba de ataque de caché varias veces. A veces una prueba de ataque de caché puede fallar aunque la implementación sí sea vulnerable. Esto puede deberse a ruido de fondo, otros dispositivos enviando tramas al dispositivo probado, etc.
ping I,E,R,AE [--full-recon]: Aquí el segundo fragmento se envía inmediatamente después de reconectarse con el
dispositivo bajo prueba, lo cual es importante en caso de que el dispositivo borre los fragmentos de la memoria después de un corto tiempo.
Tenga en cuenta que full-recon es una abreviatura de full-reconnect.
ping I,E,R,E [--full-recon]: Aquí el segundo fragmento se envía 1 segundo después de reconectarse con el
dispositivo bajo prueba, lo cual puede ser útil si hay un pequeño retardo entre la finalización del handshake
y la instalación de la clave negociada.
En nuestros experimentos, esta prueba solo falló contra Linux y contra dispositivos que no admiten fragmentación.
ping I,E,P y linux-plain: si esta prueba tiene éxito, los ataques resultantes se describen en la Sección 6.3
del artículo. En resumen, en combinación con la vulnerabilidad A-MSDU o de caché, puede explotarse para
inyectar paquetes. Cuando no se combina con otras vulnerabilidades, el impacto es específico de la implementación
(CVE-2020-26147).
ping I,P,E: si esta prueba tiene éxito, es trivial inyectar tramas de texto plano hacia el dispositivo si
la red está utilizando fragmentación (CVE-2020-26147).
ping I,P: si esta prueba tiene éxito, la implementación acepta tramas de texto plano en una red Wi-Fi
protegida, lo que permite la inyección trivial de paquetes (CVE-2020-26140).
ping I,P,P: si esta prueba tiene éxito, la implementación acepta tramas de texto plano fragmentadas en una red
Wi-Fi protegida, lo que permite la inyección trivial de paquetes (CVE-2020-26143).
Las siguientes dos pruebas envían tramas de difusión, que no se retransmiten automáticamente, y por lo tanto se recomienda ejecutarlas varias veces. Esto se debe a que el ruido de fondo puede impedir que los dispositivos probados reciban la trama de difusión inyectada. En mis experimentos, principalmente los clientes se vieron afectados (de los AP probados, solo los de Free/NetBSD se vieron afectados).
ping I,D,P --bcast-ra: Envía un ping unicast en un segundo fragmento de difusión en texto plano una vez conectado. El resultado
de esta variante del ataque se comprueba automáticamente con la herramienta de prueba.
ping D,BP --bcast-ra: Aquí la trama anterior se envía mientras se conecta a la red (es decir, durante el handshake de 4 vías).
Esto es importante porque varios clientes y AP solo son vulnerables antes de completar el handshake de 4 vías. Para
confirmar el resultado de esta prueba, debe ejecutar wireshark o tcpdump en la víctima y monitorear si la
solicitud de ping inyectada es recibida por la víctima. En tcpdump puede usar el filtro icmp y en wireshark también
puede usar el filtro frame contains "test_ping_icmp" para detectar más fácilmente esta solicitud de ping. En mis experimentos,
principalmente los clientes se vieron afectados.
eapol-amsdu I,P: Esta es la prueba estándar para la vulnerabilidad específica de la implementación discutida en
la Sección 6.5 del artículo. Tanto clientes como AP pueden ser vulnerables. Su resultado se comprueba automáticamente con
la herramienta de prueba.
Pruebas que terminan en BP (eapol-amsdu BP y eapol-amsdu-bad BP): Estas pruebas inyectan la trama maliciosa
durante la ejecución del handshake de 4 vías. Para confirmar el resultado de esta prueba, debe ejecutar wireshark
o tcpdump en la víctima y monitorear si la solicitud de ping inyectada es recibida por la víctima. En tcpdump
puede usar el filtro icmp y en wireshark también puede usar el filtro frame contains "test_ping_icmp"
para detectar más fácilmente esta solicitud de ping.
Pruebas que comienzan con eapol-amsdu-bad (eapol-amsdu-bad BP y eapol-amsdu-bad I,P): Varias implementaciones
procesan incorrectamente las tramas A-MSDU cuyos primeros 6 bytes también equivalen a un encabezado RFC1042 válido para EAPOL. Para probar estas
implementaciones, debe usar la variante de prueba eapol-amsdu-bad. Tenga en cuenta que si esta prueba tiene éxito, el impacto
del ataque es idéntico al de las implementaciones que analizan correctamente dichas tramas (para más detalles ver las Secciones 3.6 y
6.6 del artículo).
Si la herramienta de prueba parece no funcionar, verifique lo siguiente:
Verifique que ningún otro proceso esté usando la tarjeta de red (p. ej., termine su administrador de red).
Si todo funcionaba anteriormente, intente desconectar su adaptador Wi-Fi, reiniciar su computadora o máquina
virtual, y luego intente de nuevo. También intente deshabilitar el cifrado por hardware usando el script disable-hwcrypto.sh
(reinicie su computadora después de ejecutar este script).
Asegúrese de que el dispositivo que está probando no entre en estado de suspensión (lo que haría que pierda las tramas inyectadas). Recomiendo ejecutar la herramienta de prueba en modo mixto ya que maneja mejor a los clientes que pueden entrar en estado de suspensión.
Ejecute las pruebas de inyección para asegurarse de que la inyección funcione correctamente. También asegúrese de que se use un canal de 20 MHz; la inyección en otros canales no está probada.
Verifique que su máquina no esté generando tráfico de fondo que interfiera con las pruebas. En particular, deshabilite la red en su sistema operativo, termine manualmente su cliente/servidor DHCP, etc. Consulte también Antes de cada uso.
Confirme que se está conectando a la red correcta. Vuelva a verificar client.conf.
Asegúrese de que el AP que se está probando use (AES-)CCMP como algoritmo de cifrado. No se admiten otros algoritmos de cifrado como TKIP o GCMP.
Si actualizó el código usando git, ejecute ./build.sh y ./pysetup.sh nuevamente (ver Requisitos previos).
En caso de que los controladores parcheados se hayan actualizado, recuerde recompilarlos también.
Si está usando una máquina virtual, intente ejecutar la herramienta de prueba desde una imagen USB en vivo en su lugar.
Verifique que el dispositivo probado no bloquee las solicitudes de ping ICMP. En caso de que no responda a los pings, puede ejecutar tcpdump o wireshark en el dispositivo, o puede probar cualquiera de los otros métodos enumerados en .
Debido a variaciones en la implementación, puede ser difícil confirmar/explotar ciertas vulnerabilidades, en particular el ataque de clave mixta y el ataque de caché pueden ser no triviales de confirmar en la práctica. Por lo tanto, recomiendo considerar un dispositivo como seguro solo si hay comprobaciones explícitas en el código para prevenir estos ataques. Además, si el tiempo lo permite, también recomiendo las siguientes pruebas más avanzadas. Estas tienen una menor probabilidad de descubrir nuevas vulnerabilidades, pero podrían revelar variantes de ataque o comportamiento particular del dispositivo que las pruebas normales no pueden detectar.
Si las pruebas normales en Pruebas de vulnerabilidades ya han confirmado la presencia de cierta clase de vulnerabilidad, hay poca necesidad de probar las otras variantes de ataque de esa vulnerabilidad. Todos los comandos funcionan tanto contra clientes como contra AP, salvo que se indique lo contrario.
Solo es útil ejecutar estas dos pruebas si la prueba principal ping I,E --amsdu falla y desea comprender mejor
cómo maneja el dispositivo probado las tramas A-MSDU:
ping I,E --amsdu-fake: Si esta prueba tiene éxito, el receptor trata todas las tramas como tramas normales (lo que significa que no
admite tramas A-MSDU). Este comportamiento no es ideal, aunque es poco probable que un atacante pueda abusar de esto en
la práctica (ver Sección 3.5 del artículo).
ping I,E --amsdu-fake --amsdu-spp: Si esta prueba tiene éxito, el receptor autentica la marca QoS A-MSDU de cada
trama recibida (es decir, no la enmascara a cero en la recepción), pero luego trata todas las tramas recibidas como tramas normales
(lo que significa que no admite la recepción de tramas A-MSDU reales). Este comportamiento no es ideal, aunque es poco probable
que un atacante pueda abusar de esto en la práctica (ver Sección 3.5 del artículo).
La mayoría de los dispositivos que probé son vulnerables a ataques de clave mixta. Si las pruebas normales de ataque de clave mixta indican
que un dispositivo no es vulnerable, pero la prueba ping-frag-sep sí tiene éxito, se recomienda encarecidamente probar
estas pruebas alternativas de ataque de clave mixta.Como observación general, al probar un AP, puede añadir el parámetro --rekey-req a cualquiera de las pruebas de ataque de clave mixta para solicitar activamente un handshake de rekey. Un número reducido de APs realizará entonces el handshake de rekey. Sin embargo, la mayoría de los APs ignorarán esta solicitud, y deberán configurarse explícitamente para renovar periódicamente la clave de sesión (PTK).
Algunas notas sobre las pruebas:
ping I,F,BE,E y ping I,E,F,AE: Estas son pruebas de ataque de clave mixta bastante sencillas en las que ambos fragmentos se inyectan en momentos diferentes.
ping I,E,F,AE --rekey-plain: Algunos controladores (p. ej., MediaTek) realizarán el handshake de rekey en texto plano. Para probar dispositivos que usan dicho controlador, debe añadir el parámetro --rekey-plain.
ping I,E,F,AE --rekey-plain --rekey-req: Esta combinación en particular es útil para probar routers que usan un controlador MediaTek. Estos routers realizan el handshake de rekey en texto plano, y el cliente puede solicitar activamente un handshake de rekey.
ping I,E,F,AE --rekey-early-install: Un número reducido de clientes instalan (incorrectamente) la clave demasiado pronto durante una rekey de sesión pairwise. Para probar estos clientes de forma fiable, añada el parámetro --rekey-early-install. Esta prueba no es significativa contra APs.
ping I,E,F,E [--rekey-pl] [--rekey-req]: Esta variante de prueba es la misma que las pruebas anteriores ping I,E,F,AE *, excepto que el segundo fragmento se envía 1 segundo después del handshake de 4 vías. Esto puede ser importante porque en un número reducido de dispositivos hay un pequeño retraso antes de que se instale la nueva clave. Tenga en cuenta que es una abreviatura de .
Finalmente, en caso de que la prueba ping-frag-sep no tenga éxito, debe intentar la siguiente prueba de ataque de clave mixta:
ping I,F,BE,AE --freebsd: Esto esencialmente realiza el handshake de rekey contra una implementación de FreeBSD, o un controlador que toma prestado código de FreeBSD, sin afectar el proceso de desfragmentación de tramas de datos. Consulte el Apéndice E en el artículo para más detalles.ping I,E,R,AE --freebsd --full-reconnect: Esta prueba se puede utilizar para comprobar si un AP FreeBSD, o un controlador que toma prestado código de FreeBSD, es vulnerable a un ataque de caché. Consulte el Apéndice E en el artículo para obtener detalles sobre cómo funciona esta prueba. También debería probar esta prueba sin el parámetro --full-reconnect. La prueba también funciona contra clientes, pero es poco probable que estos se vean afectados.
ping I,E,R,AP --freebsd --full-reconnect: Esta prueba es una variante contra APs FreeBSD, o contra un controlador que toma prestado código de FreeBSD, en la que el segundo fragmento se envía en texto plano después de reconectarse con el AP. Contra algunos dongles en FreeBSD esta prueba fue más fiable y sigue demostrando que los fragmentos antiguos permanecen en la memoria del AP después de reconectarse. También debería probar esta prueba sin el parámetro --full-reconnect. La prueba también funciona contra clientes, pero es poco probable que estos se vean afectados.
ping I,E,R,AP [--full-reconnect]: En esta prueba el segundo fragmento se envía en texto plano. Esto puede ser útil si el dispositivo bajo prueba no instala la clave inmediatamente después del handshake de 4 vías. Si esta prueba tiene éxito, muestra que el dispositivo mantiene fragmentos en memoria después de (re)conectarse a una red, lo que significa que es vulnerable a ataques de caché. A diferencia de los dos comandos anteriores, este también es útil para realizar contra clientes (además de APs).
ping I,E,E --amsdu: Esta prueba envía una trama A-MSDU fragmentada, que no todos los dispositivos pueden recibir correctamente. No prueba una vulnerabilidad. En cambio, esta prueba es útil para determinar la explotabilidad práctica del "ataque mixto de texto plano/cifrado". Es decir, si esta prueba tiene éxito, es más fácil atacar el dispositivo si el segundo fragmento se puede enviar en texto plano (prueba ping I,E,P). Consulte la Sección 6.3 del artículo para más detalles.
ping I,E,P,E y linux-plain 3: Si todas las demás pruebas de ataque mixto de texto plano/cifrado no tuvieron éxito, también puede probar estas dos pruebas adicionales. Creo que es bastante improbable que esto descubra una nueva vulnerabilidad.
La mayoría de las siguientes pruebas envían tramas broadcast, que no se retransmiten automáticamente, y por lo tanto se recomienda ejecutarlas varias veces. Esto se debe a que el ruido de fondo puede impedir que los dispositivos probados reciban la trama broadcast inyectada. En mis experimentos, principalmente los clientes se vieron afectados. La mayoría de los clientes solo son vulnerables mientras se conectan a la red (es decir, durante la ejecución del handshake de 4 vías).
ping I,P --bcast-ra: envía una solicitud de ping ICMP unicast dentro de una trama Wi-Fi broadcast en texto plano (CVE-2020-26145). Esta prueba se puede realizar tanto contra clientes como contra APs.
ping BP --bcast-ra: similar a la prueba anterior ping I,P --bcast-ra, pero el ping se envía antes de que el cliente se haya autenticado con la red, es decir, durante la ejecución del handshake de 4 vías (CVE-2020-26145). Debe ejecutar tcpdump o wireshark para comprobar si el cliente acepta la trama. En tcpdump puede usar el filtro icmp y en wireshark también puede usar el filtro frame contains "test_ping_icmp" para detectar más fácilmente esta solicitud de ping.
ping BP --bcast-ra --bcast-dst: esta prueba es igual a la anterior, pero es útil si no puede ejecutar tcpdump en el AP objetivo. Tenga en cuenta que esta prueba solo es significativa contra APs. El parámetro adicional --bcast-dst en esta prueba hace que un AP vulnerable difunda la solicitud de ping inyectada a todos los clientes conectados. En otras palabras, para comprobar si un AP es vulnerable, ejecute este comando y escuche tramas Wi-Fi broadcast en un segundo dispositivo que esté conectado al AP usando el filtro icmp o frame contains "test_ping_icmp".
ping BP [--bcast-dst]: esta es una variante de las dos pruebas anteriores ping BP --bcast-ra [--bcast-dst], excepto que la solicitud de ping ahora se envía en una trama unicast en texto plano en lugar de una broadcast (todavía no se ha asignado ningún CVE; está relacionado con CVE-2020-26145). Esta prueba debe realizarse tanto contra clientes como contra APs. El ping se envía antes de que el cliente se haya autenticado con la red (es decir, durante la ejecución del handshake de 4 vías), lo que significa que debe ejecutar tcpdump o wireshark para comprobar si el dispositivo acepta esta trama. Alternativamente, al probar APs, puede añadir el parámetro --bcast-dst similar a la prueba anterior, y luego usar tcpdump o wireshark en un segundo dispositivo que esté conectado al AP usando el filtro icmp o frame contains "test_ping_icmp".
eapfrag BP,BP: esta es una especialización de las pruebas de fragmentos broadcast anteriores que se realiza antes de que el cliente se haya autenticado. Es un ataque muy experimental basado en el análisis de código filtrado. Primero envía un fragmento en texto plano que comienza con una cabecera EAPOL, que es aceptado porque el handshake de 4 vías todavía se está ejecutando. Luego envía un segundo fragmento broadcast con el mismo número de secuencia. Según el análisis de código filtrado, algunos dispositivos pueden aceptar este fragmento (porque el fragmento anterior fue permitido), pero el código subsiguiente lo procesará como una trama normal (porque el fragmento se difunde). Debe usar tcpdump o wireshark en la víctima para determinar si la trama se recibe correctamente, por ejemplo usando el filtro icmp o . Una variante alternativa es en caso de que la variante normal no funcione.
Esta prueba se puede utilizar en caso de que quiera ejecutar las pruebas eapol-amsdu[-bad] BP pero no pueda ejecutar tcpdump o wireshark en el AP. Esta prueba solo es significativa contra APs: el comando eapol-amsdu[-bad] BP --bcast-dst hace que un AP vulnerable difunda la solicitud de ping inyectada a todos los clientes conectados. En otras palabras, para comprobar si un AP es vulnerable, ejecute este comando y escuche tramas Wi-Fi broadcast en un segundo dispositivo que esté conectado al AP usando el filtro icmp o frame contains "test_ping_icmp".
eapol-inject 00:11:22:33:44:55: Esta prueba solo es significativa contra APs. Para realizar esta prueba tiene que conectarse a la red usando un segundo dispositivo y reemplazar la dirección MAC 00:11:22:33:44:55 con la dirección MAC de este segundo dispositivo. Antes de ser autenticado, la herramienta de prueba enviará una trama EAPOL al AP con como destino final este segundo dispositivo. Si el AP reenvía la trama EAPOL al segundo dispositivo, se considera que el AP es vulnerable. Para confirmar si el AP reenvía la trama EAPOL, debe ejecutar tcpdump o wireshark en el segundo dispositivo. Puede usar el filtro de wireshark frame contains "forwarded_data" al monitorear el tráfico descifrado en la interfaz inalámbrica del segundo dispositivo (o el filtro de tcpdump ether proto 0x888e para monitorear todas las tramas EAPOL). Consulte la Sección 6.6 del artículo para conocer los detalles y el impacto de esto.
eapol-inject-lage 00:11:22:33:44:55: En caso de que la prueba eapol-inject anterior tenga éxito, también puede probar eapol-inject-large para ver si esta vulnerabilidad puede ser abusada para forzar la transmisión de fragmentos cifrados. De nuevo tiene que usar tcpdump o wireshark para comprobarlo. Use el filtro de wireshark o tshark (wlan.fc.frag == 1) || (wlan.frag > 0) para detectar tramas fragmentadas. Me pareció muy raro que este ataque funcione.
ping I,D,E: Si esta prueba tiene éxito, el cliente o AP no soporta (des)fragmentación, pero sigue siendo vulnerable a ataques. El problema es que el receptor trata el último fragmento como una trama completa. Consulte la Sección 6.8 del artículo para más detalles y cómo esto puede ser explotado.
ping I,E,D: Si esta prueba tiene éxito, entonces el cliente o AP trata el primer fragmento como una trama completa. Aunque este comportamiento no es ideal, actualmente se desconoce si esto, por sí solo, puede ser explotado en la práctica.
El script test-injection.py se puede utilizar para probar si las tramas se inyectan correctamente cuando se usa el modo de inyección:
./test-injection.py wlan0 wlan1
Aquí probamos si la tarjeta de red wlan0 inyecta correctamente las tramas y usamos la tarjeta de red wlan1 para monitorear si las tramas se inyectan correctamente. Tenga en cuenta que ambas interfaces deben soportar el modo monitor para que este script de prueba funcione.
En caso de que no tenga una segunda tarjeta de red, puede ejecutar una prueba de inyección parcial usando:
./test-injection.py wlan0
Desafortunadamente, la prueba anterior solo puede comprobar si el kernel sobrescribe campos de las tramas inyectadas; no puede comprobar si el firmware o el chip inalámbrico en sí sobrescriben campos.
Para probar si una tarjeta de red inyecta correctamente tramas en modo mixto, que es el modo que recomiendo usar, puede ejecutar los siguientes dos comandos:
./fragattack.py wlan0 ping --inject-test wlan1
./fragattack.py wlan0 ping --inject-test wlan1 --ap
Aquí probamos si wlan0 inyecta correctamente las tramas monitoreando las tramas inyectadas usando la segunda tarjeta de red wlan1. El primer comando prueba si las tramas se inyectan correctamente cuando se usa el modo mixto actuando como cliente, y el segundo comando cuando se usa el modo mixto actuando como AP. Para iniciar la prueba, el cliente debe poder conectarse a una red, y el AP espera hasta que un cliente se conecte antes de iniciar las pruebas de inyección (consulte Antes de cada uso para configurar el establecimiento de conexión del cliente y del AP).
Si también desea probar el comportamiento de retransmisión de wlan0 en modo mixto, puede ejecutar:
./fragattack.py wlan0 ping --inject-test-postauth wlan1
./fragattack.py wlan0 ping --inject-test-postauth wlan1 --ap
En caso de que no tenga una segunda tarjeta de red, puede ejecutar una prueba parcial de inyección en modo mixto usando:
./fragattack.py wlan0 ping --inject-test[-postauth] self
./fragattack.py wlan0 ping --inject-test[-postauth] self --ap
Desafortunadamente, las pruebas anteriores solo pueden comprobar si el kernel sobrescribe campos de las tramas inyectadas; no pueden comprobar si el firmware o el chip inalámbrico en sí sobrescriben campos.
El script de prueba dará una salida detallada sobre qué pruebas tuvieron éxito o fallaron, y concluirá mostrando ==> The most important tests have been passed successfully o un mensaje que indica que pruebas importantes fallaron o que no pudo capturar ciertas tramas inyectadas.
Tenga en cuenta que los scripts de inyección solo prueban el comportamiento más importante. La mejor manera de confirmar que la inyección funciona correctamente es realizar las pruebas de vulnerabilidad contra dispositivos que se sabe que son vulnerables y confirmar que la herramienta identifica correctamente el dispositivo o los dispositivos como vulnerables.
Cuando no se pueden capturar ciertas tramas inyectadas, esto puede deberse a ruido de fondo, o porque la tarjeta de red que se está probando no puede inyectar correctamente ciertas tramas (por ejemplo, el firmware del Intel AX200 falla al inyectar tramas fragmentadas). También podría ser que las tramas se inyecten correctamente, pero que la tarjeta de red utilizada para monitorear si las tramas se inyectan correctamente (wlan1 en los ejemplos anteriores) no sea fiable y, por ejemplo, pierda la mayoría de las tramas debido al ruido de fondo. Intente ejecutar las pruebas en un canal diferente también.
Cuando las pruebas de inyección funcionan, pero tiene problemas para realizar las pruebas de ataque de forma fiable, esto puede deberse a que los dispositivos que está probando entran en modo de suspensión. Consulte Manejo del modo de suspensión para obtener notas adicionales sobre este problema.
Cuando use wireshark para inspeccionar el comportamiento de inyección de un dispositivo, se recomienda usar un segundo dispositivo en modo monitor para ver cómo se inyectan las tramas.
En caso de que abra la interfaz utilizada para inyectar tramas, debería ver las tramas inyectadas dos veces: (1) primero ve la trama tal como la inyecta cualquier herramienta que la envíe, y luego (2) una segunda vez por cómo fue inyectada por el controlador. Estas dos tramas pueden diferir ligeramente si el kernel sobrescribió ciertos campos. Si solo ve una trama inyectada una vez, es posible que el kernel la haya descartado.
En caso de que el dispositivo que está probando no soporte DHCP, puede especificar manualmente las direcciones IP que la herramienta de prueba debe usar. Por ejemplo:
./fragattack.py wlan0 [--ap] ping --inject wlan1 --ip 192.168.100.10 --peerip 192.168.100.1
Aquí la herramienta de prueba usará la dirección IP 192.168.100.10 e inyectará una solicitud de ping a la dirección IP del peer 192.168.100.1.
Cuando una prueba envía paquetes IP antes de obtener direcciones IP mediante DHCP, usará la dirección IP predeterminada 127.0.0.1. Para usar diferentes direcciones IP (predeterminadas), también puede usar los parámetros --ip y -peerip.
La mayoría de las pruebas de ataque funcionan enviando solicitudes de ping ICMP de maneras especiales y viendo si recibimos una respuesta de ping ICMP. En caso de que el dispositivo bajo prueba no soporte pings ICMP, puede usar solicitudes ARP añadiendo el parámetro --arp a todas las pruebas. En caso de que una prueba no soporte el envío de solicitudes ARP, la herramienta mostrará el error Cannot override request type of the selected test, en cuyo caso la prueba específica solo se puede ejecutar usando solicitudes de ping ICMP.
TODO: Cuando actuamos como cliente, también podemos inyectar solicitudes DHCP en su lugar.
En caso de que no pueda acceder a una de las tarjetas de red inalámbricas recomendadas, una segunda opción es conseguir una tarjeta de red que use los mismos controladores en Linux. En particular, puede probar:
Recomiendo tarjetas basadas en ath9k_htc. No todas las tarjetas que usan iwlmvm serán compatibles. Cuando use una tarjeta de red alternativa, recomiendo encarecidamente ejecutar primero las pruebas de inyección para confirmar que la tarjeta de red es compatible.
Para usar la herramienta de prueba en canales de 5 GHz, la tarjeta de red utilizada debe permitir la inyección de tramas en el canal de 5 GHz. Desafortunadamente, esto no siempre es posible debido a restricciones regulatorias. Para ver en qué canales puede inyectar tramas, puede ejecutar iw list y buscar en Frequencies los canales que no estén marcados como disabled, no IR, o radar detection. Tenga en cuenta que estas condiciones pueden depender de su tarjeta de red, el país configurado actualmente y el AP al que está conectado. Para obtener más información, consulte, por ejemplo, la documentación de Arch Linux.
Tenga en cuenta que un dispositivo puede usar diferentes controladores para manejar las bandas de 2.4 y 5 GHz. Como resultado, es importante probar los dispositivos en ambas bandas, ya que un dispositivo puede comportarse de manera diferente dependiendo de la banda de frecuencia que se esté utilizando.
Tenga en cuenta que en modo mixto, el kernel de Linux puede no permitir la inyección de tramas aunque se permita enviar tramas normales. Esto se debe a que en la función ieee80211_monitor_start_xmit el kernel se niega a inyectar tramas cuando cfg80211_reg_can_beacon devuelve false. Como resultado, Linux puede negarse a inyectar tramas aunque esto realmente esté permitido. Hacer que cfg80211_reg_can_beacon devuelva true bajo las condiciones correctas evita este error.
En la práctica, algunas personas han encontrado que primero debe configurar manualmente la tarjeta de red inalámbrica al canal de 5GHz en el que opera el AP. Consulte este problema de GitHub para más detalles.
Dispositivos como teléfonos móviles o gadgets IoT pueden poner su radio Wi-Fi en modo de suspensión para reducir el consumo de energía. Cuando están en modo de suspensión, estos dispositivos no pueden recibir tramas Wi-Fi, lo que puede interferir con nuestras pruebas. Hay algunas opciones para intentar mitigar este problema:
Intente desactivar el modo de suspensión en el dispositivo bajo prueba. Esta es la solución más fiable, pero desafortunadamente no siempre es posible.
Ejecute la herramienta de prueba en modo mixto. La mayoría de las tarjetas de red pondrán en cola las tramas inyectadas hasta que el dispositivo bajo prueba esté despierto nuevamente.
Pruebe con una tarjeta de red diferente para realizar las pruebas. Encontré que diferentes tarjetas de red inyectan tramas en momentos (ligeramente) diferentes, y esto puede ser la diferencia entre que la trama inyectada llegue correctamente o se pierda. Por ejemplo, contra un Pixel 4 XL la herramienta de prueba fue poco fiable al usar una TL-WN722N, pero funcionó de forma fiable con un Intel 8265.
Asigne IPs estáticas al dispositivo bajo prueba y haga que la herramienta de prueba use IPs estáticas (consulte Configuración de IP estática). Con muchas pruebas esto puede ser más fiable porque la herramienta de prueba puede enviar inmediatamente la trama de prueba en lugar de tener que usar/esperar a DHCP primero.
es decir, cuando está ejecutando el handshake de 4 vías. Esto hace que sean más difíciles de probar automáticamente y normalmente implica que hay que usar tcpdump o similar en el dispositivo bajo prueba. Sin embargo, los AP pueden probarse sin ejecutar tcpdump en ellos. En particular, las pruebas del ataque de fragmento broadcast (CVE-2020-26145) y del ataque A-MSDU EAPOL (CVE-2020-26144) pueden realizarse sin ejecutar tcpdump en el dispositivo bajo prueba. En su lugar, tcpdump debe ejecutarse en otro cliente conectado al AP. Concretamente, se pueden usar los siguientes comandos:
ping I,P --bcast-ra --bcast-dst y ping BP --bcast-ra --bcast-dst
eapol-amsdu BP --bcast-dst y eapol-amsdu-bad BP --bcast-dst
Con estos comandos, puedes monitorizar la solicitud de ping en otro cliente conectado al AP. En caso de que la solicitud de ping se reciba en este cliente independiente, el AP bajo prueba es vulnerable. Desafortunadamente, actualmente, parece difícil probar clientes contra estas variantes de ataque sin ejecutar tcpdump en el cliente.
Si por alguna razón Linux no reconoce automáticamente este dongle, ejecuta sudo modprobe mt76x2u
para cargar manualmente el controlador. Este dongle parece fiable con nuestros últimos controladores. Si el dongle no es fiable,
crea el archivo /etc/modprobe.d/mt76.conf con el siguiente contenido:```
options mt76_usb disable_usb_sg=1
Luego reinicia tu máquina. Asegúrate también de usar un buen cable USB con este dongle. Anteriormente encontré un comportamiento poco fiable con este dongle, causado por un cable USB 3.0 defectuoso. Así que, si experimentas problemas, puede ayudar conectar el dongle directamente sin usar un cable.
Cuando uses VirtualBox, asegúrate de habilitar USB3.0 para que el dongle sea reconocido. Consulta
[este problema](https://github.com/vanhoefm/fragattacks/issues/22) para más detalles.
El AWUS036ACM usa internamente un chipset MT7612U. Ahora también hay dongles con un chipset MT7612UN que
también son fiables con nuestra herramienta de pruebas. Un ejemplo es el [CSL Wireless Network Adaptor](https://www.amazon.de/dp/B0873BNBD8?tag=modwiffir-20).
### ath9k_htc
La Technoethical N150 HGA, la TP-Link TL-WN722N v1.x y la Alfa AWUS036NHA utilizan el controlador `ath9k_htc`.
Para mí estos dispositivos funcionaron bastante bien en una máquina virtual, aunque, como con todos los dispositivos, son más fiables cuando se usan de forma nativa. Al usar una VM, recomiendo configurar la VM para que use un controlador USB2.0, ya que pareció más estable (al menos con VirtualBox).
En kernels recientes hubo una regresión ([ya corregida](https://www.spinics.net/lists/linux-wireless/msg200825.html)) con el controlador `ath9k_htc` que hacía que no funcionara. Simplemente usa un kernel actualizado o nuestros controladores parcheados para evitar este problema.
#### AWUS036ACH
Por lo general, este dispositivo no es compatible de forma predeterminada en la mayoría de las distribuciones de Linux y requiere la instalación manual de los controladores. En Kali Linux puedes instalar el controlador con `sudo apt install realtek-rtl88xxau-dkms`. Para instalar el controlador en otras distribuciones, consulta tu gestor de paquetes o sigue las instrucciones de instalación en [GitHub](https://github.com/aircrack-ng/rtl8812au). Antes de conectar el dispositivo, se recomienda ejecutar `modprobe 88XXau rtw_monitor_retransmit=1`.
Desafortunadamente, este dispositivo no funciona en modo mixto, que es el modo recomendado, y es difícil de usar en combinación con nuestros controladores modificados. En la práctica, tendrás que desinstalar los controladores modificados y luego ejecutar la herramienta de pruebas usando los parámetros `--no-drivercheck` y usando `--inject wlan0`, donde wlan0 se refiere a la tarjeta AWUS036ACH. Debido a estas limitaciones, este dispositivo no se recomienda.
### Intel AX200
Probé el Intel AX200 y descubrí que _no_ es compatible con la herramienta de pruebas: su firmware falla después de inyectar una trama con el indicador More Fragments activado. Si un desarrollador de Intel está leyendo esto, por favor actualiza el firmware y haz posible inyectar tramas fragmentadas.
### Chips basados en RT5572
Probé este chipset usando el adaptador general [CSL USB 2.0 WLAN Adapter 300Mbit](http://www.amazon.de/dp/B00LLIOT34?tag=modwiffir-20). Después de deshabilitar el descifrado por hardware ejecutando el script `disable-hwcrypto.sh`, pude realizar una prueba de ping básica (`ping`). Una prueba de ping fragmentada (`ping I,E,E`) fue muy poco fiable, pero a veces funcionó.
La conclusión actual es que los chips RT5572 _podrían_ funcionar con la herramienta de pruebas después de deshabilitar el cifrado por hardware. Pero se necesitan experimentos adicionales para confirmarlo (se agradece cualquier comentario).
<a id="id-hwsim-details"></a>
## 9.9. Detalles del modo Hwsim
**Advertencia**: *este es actualmente un modo experimental, úsalo solo con fines de investigación.*
Este modo requiere solo una tarjeta de red que admita el modo monitor y, a diferencia del modo mixto, la tarjeta de red no tiene que admitir interfaces virtuales. La desventaja es que en este modo las tramas se manejan un poco más lento y no es fiable cuando la tarjeta de red no confirma las tramas:
- Debido al commit 1672c0e31917 ("mac80211: start auth/assoc timeout on frame status"), la autenticación como cliente agotará el tiempo de espera al instante, lo que significa que actualmente no podemos usar el modo hwsim como cliente.
_TODO: Necesitamos parchear el kernel para evitar este timeout._
- Si probamos un cliente que usa el commit 1672c0e31917 ("mac80211: start auth/assoc timeout on frame status"), nosotros (como AP) debemos confirmar las tramas enviadas hacia nosotros. De lo contrario, el cliente bajo prueba no podrá conectarse.
_TODO: Probar qué dispositivos confirman tramas en modo monitor y probar `iw set wlanX monitor active`._
- Ciertos APs también requerirán que el cliente confirme las tramas de autenticación y asociación. Esto significa que nosotros (como cliente) debemos volver a confirmar las tramas enviadas hacia nosotros.
_TODO: Probar qué dispositivos confirman tramas en modo monitor y probar `iw set wlanX monitor active`._
- Por alguna extraña razón, ¿Intel/mvm no puede recibir tramas de datos de Android/iPhone/iPad después del 4-way HS? Es un bug muy extraño. _TODO: Investigar esto más a fondo._
Antes de usar este modo, crea dos tarjetas de red virtuales:
./hwsim.sh
Esto mostrará las dos interfaces "hwsim" virtuales creadas, por ejemplo wlan1 y wlan2. Al probar un AP en este modo, primero debes buscar el canal del AP y poner la tarjeta de red real en ese canal:
./scan.sh wlan0
ifconfig wlan0 down
iw wlan0 set type monitor
ifconfig wlan0 up
# Pick the channel that the AP is on (in this example 11)
iw wlan0 set channel 11
Aquí wlan0 se refiere a la tarjeta de red _real_ (no a una interfaz creada por `hwsim.sh`). Al probar un cliente, no es necesario configurar primero el canal (se toma de `hostapd.conf`). Ahora puedes iniciar la herramienta de pruebas de la siguiente manera:
./fragattack.py wlan0 --hwsim wlan1,wlan2 [--ap] $COMMAND
Después de que la herramienta se ejecute, puedes volver a ejecutarla directamente con un nuevo `$COMMAND`.
<a id="id-wpa3-sae"></a>
## 9.10. Pruebas de dispositivos WPA3 y SAE
Puedes probar un AP WPA3/SAE incluyendo las siguientes dos líneas en `client.conf`:
key_mgmt=SAE
ieee80211w=1
Para probar clientes WPA3/SAE puedes modificar `hostapd.conf` y establecer los parámetros:
wpa_key_mgmt=SAE
ieee80211w=2
Probamos lo anterior con un Intel 8265, un Intel 3160, un Netgear WN111v2 (`carl9170`), un TP-Link TL-WN722N (`ath9k_htc`) y un WNDA3200 (`ath9k_htc`). Con esos dispositivos pude conectarme al AP y ejecutar algunas pruebas. Así que parece que esto debería funcionar con todos los dongles ya soportados. Ten en cuenta que no lo he probado en detalle: mi suposición ha sido que el hecho de que un dispositivo funcione en modo WPA2 o WPA3 no afectará los resultados de las pruebas.
El `client.conf` proporcionado habilita por defecto tanto el método hunting-and-pecking como el método hash-to-element. Para configurar un AP que admita hash-to-element (y así probar los clientes WPA3/SAE más recientes) puedes modificar `hostapd.conf` y establecer el parámetro:
sae_pwe=2
Al establecer este valor, el AP aceptará tanto el método hunting-and-pecking como el método hash-to-element.
<a id="id-live-image"></a>
## 9.11. Imagen USB en vivo
Descarga la [imagen USB en vivo](https://people.cs.kuleuven.be/~mathy.vanhoef/fragattacks/ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso) y escríbela en un USB usando:
# Unmount in case there's an old partition on the USB
sudo umount /dev/sdb*
# Copy the image
sudo dd bs=4M if=ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso of=/dev/sdb conv=fdatasync status=progress
El sha256sum de la imagen es `4b973452a08b981778285a33accfd4ce58625a91e8e0eab20941facf54904bba`. Reemplaza `/dev/sdb` con tu memoria USB. Si no estás usando Linux, busca en internet cómo escribir una imagen ISO en tu memoria USB.
Al iniciar la imagen en vivo, haz clic en "Try Ubuntu" durante el arranque. Abre una terminal haciendo clic derecho en el escritorio y seleccionando "Open in Terminal", y ejecuta:
cd ~/fragattacks/research
sudo su
nmcli radio wifi off
source venv/bin/activate
Ahora puedes ejecutar `./fragattacks.py` y seguir las instrucciones normales de este README. Recuerda deshabilitar el Wi-Fi usando `nmcli radio wifi off` como se muestra arriba, de lo contrario el administrador de red de Ubuntu interferirá con la herramienta de pruebas. Este README también está presente en la imagen en vivo en `~/fragattacks/README.md`.
Ten en cuenta que airmon-ng puede ser poco fiable en la imagen en vivo y es mejor usar [iw](https://github.com/vanhoefm/fragattacks/issues/36).
<a id="id-design-notes"></a>
# 10. Notas de diseño
Los argumentos dados al comando ping definen qué acciones realizará la herramienta de pruebas y cuándo se realizarán. Cada acción está separada por una coma (`,`). Por defecto, una acción se realiza después de que el cliente se conecta, y en ese caso una sola letra representa qué acción se realiza. Ten en cuenta que esto está implementado en la función [`stract2action`](https://github.com/vanhoefm/fragattacks/blob/master/research/fragattack.py#L23). Las acciones posibles son:
- `I`: obtener una dirección IP. Por defecto se hace mediante DHCP, a menos que se proporcione explícitamente una dirección IP usando los argumentos `--ip` y `--peerip`, en cuyo caso no se hace nada.
- `E`: inyectar un paquete/fragmento cifrado de la solicitud de ping.
- `P`: inyectar un paquete/fragmento en texto plano de la solicitud de ping.
- `F`: renovar la clave de sesión iniciando el handshake de 4 vías (como AP) o esperando el handshake de 4 vías (como cliente).
- `R`: permitir que el cliente se reconecte a la red.
- `D`: esta es una "meta-acción" especial. Trátala como un fragmento vacío de la solicitud de ping que no se envía realmente.
Si solo hay una única acción `E` o `P`, la solicitud de ping se inyecta como una sola trama. Si hay múltiples acciones `E` o `P`, la solicitud de ping se fragmenta, siendo el número de fragmentos igual al número de acciones `E` o `P`. Si está la acción especial `D`, la solicitud de ping se fragmenta sobre las acciones `E` o `P` restantes (ver los ejemplos en la tabla). Este comportamiento de fragmentación está implementado en la clase [PingTest](https://github.com/vanhoefm/fragattacks/blob/master/research/tests_common.py#L47).
Se puede poner una letra delante de las acciones anteriores para cambiar cuándo debe realizarse la acción:
- `S`: la acción se realiza en el 1.er o 2.º mensaje del handshake de 4 vías.
- `B`: la acción se realiza en el 3.er o 4.º mensaje del handshake de 4 vías.
- `A`: la acción se realiza inmediatamente después de completarse el handshake de 4 vías.
- `C`: la acción se realiza 1 segundo después de completarse el handshake de 4 vías. La cantidad de segundos a esperar se puede cambiar usando el parámetro `--connected-delay`.
Por ejemplo, consulta las dos tablas anteriores con comandos.
<a id="id-change-log"></a>
# 11. Registro de cambios
**Versión 1.3.4 (en progreso):**
- Cifrar siempre las tramas EAPOL (Rekey) Request, incluso cuando se usa `--rekey-plaintext`.
- El cliente ahora acepta tramas EAPOL reenviadas (replays). Esto asegura que los rekeys funcionen incluso cuando el AP bajo prueba implementa los rekeys incorrectamente.
- Se actualizó wpa_supplicant para volver a habilitar la conexión a redes Enterprise que usan MS-CHAPv2. Anteriormente, cuando el SO usa OpenSSL 3.0 o superior, MD4 estaba deshabilitado por defecto, lo que impedía usar MS-CHAPv2.
- Se añadió el parámetro `--pre-test-delay`. Este añade un retraso entre la obtención de una dirección IP y la transmisión de los primeros fragmentos/tramas. Consulta el [pull request](https://github.com/vanhoefm/fragattacks/pull/44) de Michael Trimarchi y Angelo Compagnucci.
- Se actualizaron los controladores modificados para que también compilen en el kernel de Linux 5.13. Esto es experimental.
- Se hizo más fiable la prueba de inyección esperando más tiempo las tramas en la prueba de reordenamiento.
- Se hicieron varios cambios menores para facilitar la compilación del código en plataformas más antiguas (que tienen versiones antiguas de Python y de las librerías OpenSSL).
- Se actualizó el README con un ejemplo de cómo instalar un kernel antiguo compatible en Ubuntu 20.04. Se añadieron notas de diseño. Ahora se recomienda el AWUS036ACM.
**Versión 1.3.3 (11 de mayo de 2021):**
- Se actualizaron los controladores modificados para que compilen en los kernels de Linux 5.10, 5.11 y 5.12.
- Se actualizó el firmware para dispositivos `ath9k_htc` (no debería tener impacto en las pruebas).
- Se reestructuró el repositorio para su lanzamiento público. Se eliminaron documentos y diapositivas internos para hacer referencia a las versiones públicas de estos documentos.
- Soporte básico para canales de 40 MHz al usar el parámetro `--inject-test[-postauth]` para probar la inyección. En pruebas reales de vulnerabilidad, el uso de canales de 40 MHz no está probado (usa `disable_ht40` en `client.conf` si es necesario).
**Versión 1.3.2 (8 de marzo de 2021):**
- Se añadieron los [documentos](https://papers.mathyvanhoef.com/fragattacks-slides-2021-03-8.pdf) de la presentación y un [resumen](https://papers.mathyvanhoef.com/fragattacks-overview.pdf) de la causa raíz e impacto de cada vulnerabilidad.
- Se actualizó este README para [explicar](#id-test-sanity) que el parámetro `--icmp-size 100` o similar se puede añadir a todas las pruebas que envían tramas fragmentadas si el dispositivo bajo prueba solo acepta fragmentos de un cierto tamaño mínimo.
- Se corrigieron errores tipográficos menores en este README.
**Versión 1.3.1 (1 de marzo de 2021):**
- Se añadió la prueba [`ping BP [--bcast-dst]`](#id-extended-bcast-check-ping-bp) a este README. Inyecta un ping en texto plano mientras se conecta (es decir, durante el handshake de 4 vías). Tanto los clientes como los APs pueden ser vulnerables a este ataque.
- Se actualizó la [descripción general de ataques](#id-paper-clarifications) con nuevos ejemplos de cómo se pueden abusar en la práctica las vulnerabilidades de inyección de paquetes. Esto incluye técnicas para engañar a clientes que solo usan IPv4 para que utilicen un servidor DNS malicioso y técnicas para comunicarse directamente con dispositivos detrás de un NAT/cortafuegos (para, por ejemplo, explotar servicios locales).
- Se aclaró que las [pruebas de fragmentos de broadcast](#id-extended-bcast-check) se pueden realizar tanto contra clientes como contra APs.
- La herramienta de pruebas ahora comprobará si se ha cargado la versión esperada de la librería Python Scapy.
- Se corrigieron algunas referencias al artículo en este README (ahora se referencian correctamente las secciones 6.4, 6.6 y 6.8).
- Se actualizó al borrador versión 3 del artículo. No hay cambios importantes en comparación con el borrador versión 2, solo pequeños ajustes textuales y estructurales. En cuanto al contenido, esta es ahora la versión final del artículo.
**Versión 1.3 (20 de enero de 2021):**
- Esta versión se basa en el commit `a337c1d7c` de hostap ("New TWT operations and attributes to TWT Setup and Nudge").
- Se añadió una [descripción general](https://github.com/vanhoefm/fragattacks/blob/HEAD/attacks.pdf) de los ataques y sus condiciones previas, y se crearon [estas diapositivas](https://github.com/vanhoefm/fragattacks/blob/HEAD/amsduattack.pdf) para ilustrar mejor cómo funciona en la práctica el ataque de agregación (CVE-2020-24588).
- Se añadieron <a href="#id-wpa3-sae">instrucciones</a> sobre cómo probar dispositivos WPA3/SAE usando el método hunting-and-pecking o hash-to-element. Esto también implica que la herramienta de pruebas soporta Management Frame Protection (MFP).
- Se añadió una aclaración a este README sobre cómo usar tcpdump para verificar el resultado de ciertas pruebas.
- Se añadió la prueba extra `ping BP --bcast-ra --bcast-dst` a este README para poder probar CVE-2020-26145 contra APs que no pueden ejecutar tcpdump (con esta prueba, tcpdump debe ejecutarse en un cliente conectado independiente).
- Se añadieron las pruebas extra `ping I,E,F,E [--rekey-pl] [--rekey-req]` a este README para detectar mejor los ataques de clave mixta (CVE-2020-24587) en ciertos dispositivos.
- Se corrigió la inyección de tramas fragmentadas al usar dongles ath9k_htc en combinación con 802.11n.
- Se añadió el script `pysetup.sh` para crear el entorno virtual de Python. Este script también corrige [un bug](https://github.com/secdev/scapy/commit/46fa40fde4049ad7770481f8806c59640df24059) en la librería scapy cuando se usa con Python 3.9.
- Los controladores parcheados se han actualizado para compilar correctamente en Linux 5.9.0.
- Se corrigió la prueba `ping-frag-sep`. Anteriormente se comportaba como `ping-frag-sep --pn-per-qos`. Ten en cuenta que esta prueba no se usa para detectar vulnerabilidades, sino solo para comprender mejor las implementaciones.
**Versión 1.2 (15 de noviembre de 2020):**
- Esta versión (y las anteriores) se basa en el commit `1c67a0760` de hostap ("tests: Add basic power saving tests for ap_open").
- La herramienta se cerrará automáticamente después de que una prueba se complete o expire.
- La herramienta detecta si el handshake de 4 vías está en bucle o si no hay respuesta a una solicitud de rekey (`--rekey-req`).
- Cuando se usa un servidor DHCP externo, la herramienta ahora siempre enviará tramas EAPOL con la dirección del AP como destino (en lugar del servidor DHCP). Esto es importante en las pruebas de clave mixta y de ataque de caché cuando se usa un servidor DHCP externo.
- Al probar un AP usando `--rekey-req`, la herramienta ahora enviará una solicitud de rekey EAPOL con un Replay Counter de uno en lugar de cero.
- La salida de depuración ahora muestra la clave (grupal) correcta al cifrar tramas de broadcast/multicast. Esto no influye en ningún resultado de la prueba, solo cambia la salida de la herramienta de pruebas.
- Se aclaró que todos los comandos de este README pueden probar tanto clientes como APs, salvo que se indique lo contrario.
- Se aclaró la descripción de los ataques de caché, el fragmento de broadcast y las pruebas de ataque EAPOL A-MSDU en este README.
- Se aclaró que es importante probar tanto la banda de 2.4 como la de 5 GHz en este README.
**Versión 1.1 (20 de octubre de 2020):**
- Se corrigió un bug por el cual el comando `ping I,E,D` enviaba una solicitud de ping cifrada normal. Ahora envía una solicitud de ping cifrada con el indicador More Fragments establecido en la cabecera.
- Se movieron los comandos `amsdu-inject-[bad]` a la Sección 7 de este README. Estos simulan ataques reales y pueden usarse para verificar si las mitigaciones temporales están funcionando (ver Sección 7.2 del artículo).
- Se corrigió la ortografía de A-MSDU SPPs en este README y en la herramienta de pruebas. El nuevo argumento `--amsdu-spp` ahora es un sinónimo del antiguo argumento `--amsdu-ssp`.
**Versión 1.0 (11 de agosto de 2020):**
- Se preparó el lanzamiento inicial para su uso durante el embargo.
| Network Card | USB | 5GHz | mixed mode | injection mode |
|---|
| Technoethical N150 HGA | Sí | No | controlador/firmware parcheado | controlador/firmware parcheado |
| TP-Link TL-WN722N v1.x | Sí | No | controlador/firmware parcheado | controlador/firmware parcheado |
| Alfa AWUS036NHA | Sí | No | controlador/firmware parcheado | controlador/firmware parcheado |
| Intel Wireless-AC 8265 | No | Sí | controlador parcheado | sí |
| Intel Wireless-AC 3160 | No | Sí | controlador parcheado | sí |
| Alfa AWUS036ACM | Sí | Sí | controlador parcheado | sí |
| Netgear WN111v2 | Sí | No | controlador parcheado | sí |
| Alfa AWUS036ACH | Sí | Sí | no | sí |
| Command | Short description |
|---|
ping | Envía un ping normal. |
ping I,E,E | Envía un ping fragmentado normal. |
ping I,E,E --delay 5 | Envía un ping fragmentado normal con un retraso de 5 segundos entre fragmentos. |
ping-frag-sep | Envía un ping fragmentado normal con los fragmentos separados por otra trama. |
ping-frag-sep --pn-per-qos | Igual que el anterior, pero también funciona si el objetivo solo acepta PN consecutivos. |
ping I,E --amsdu | Envía un ping encapsulado en una trama A-MSDU normal (sin protección SPP). |
amsdu-inject | Simula el ataque: envía una trama A-MSDU cuyo inicio también es una cabecera rfc1042 válida. |
amsdu-inject-bad | Igual que el anterior, pero contra objetivos que analizan la trama incorrectamente. |
ping I,F,BE,AE | Inyecta dos fragmentos cifrados con una clave diferente. |
ping I,F,BE,AE --pn-per-qos | Igual que el anterior, pero también funciona si el objetivo solo acepta PN consecutivos. |
ping I,E,R,AE | Inyecta un fragmento, intenta desencadenar una reasociación e inyecta el segundo fragmento. |
ping I,E,R,E | Igual que el anterior, pero con un retraso mayor antes de enviar el segundo fragmento. |
ping I,E,R,AE --full-recon | Inyecta un fragmento, desautentica y vuelve a conectar, y luego inyecta el segundo fragmento. |
ping I,E,R,E --full-recon | Igual que el anterior, pero con un retraso mayor antes de enviar el segundo fragmento. |
ping I,E,E --inc-pn 2 | Envía un ping fragmentado con números de paquete no consecutivos. |
ping I,E,P | Envía un ping fragmentado: primer fragmento cifrado, segundo fragmento en texto plano. |
ping I,P,E | Envía un ping fragmentado: primer fragmento en texto plano, segundo fragmento cifrado. |
ping I,P | Envía un ping en texto plano. |
ping I,P,P | Envía un ping fragmentado: ambos fragmentos se envían en texto plano. |
linux-plain | Ataque de fragmentación mixto texto plano/cifrado específico de Linux. |
ping I,D,P --bcast-ra | Envía un ping unicast en un segundo fragmento difundido en texto plano una vez conectado. |
ping D,BP --bcast-ra | Igual que el anterior, pero la trama se envía durante el handshake de 4 vías (compruébalo con tcpdump). |
eapol-amsdu I,P | Envía un A-MSDU en texto plano que contiene una solicitud de ping oculta como trama EAPOL. |
eapol-amsdu BP | Igual que el anterior, pero la trama se envía durante el handshake (compruébalo con tcpdump). |
eapol-amsdu-bad I,P | Envía un A-MSDU en texto plano malformado que contiene una solicitud de ping oculta como trama EAPOL. |
eapol-amsdu-bad BP | Igual que el anterior, pero la trama se envía durante la conexión (compruébalo con tcpdump). |
--pn-per-qosEn general, puede ser tedioso probar si un dispositivo es vulnerable a ataques de caché. Por lo tanto, también recomiendo realizar una auditoría de código para comprobar si los fragmentos permanecen en la memoria después de desasociarse o desautenticarse de una red o después de reasociarse (esto también se puede comprobar dinámicamente mediante impresiones de depuración). Si los fragmentos permanecen en la memoria, debe considerar esto como un riesgo, incluso si se desconoce si puede ser explotado. Esto es similar a saber que una implementación tiene un desbordamiento de búfer pero no (aún) saber cómo explotarlo.
Ejecute la herramienta con el parámetro adicional --debug 2 para obtener salida de depuración adicional de wpa_supplicant o
hostapd y de la propia herramienta de prueba.
Confirme usando una segunda interfaz de monitor que no se envíen otras tramas entre fragmentos. Por ejemplo, descubrí que mi dispositivo Intel a veces envía tramas Block Ack Response Action entre fragmentos, y esto interfería con el proceso de desfragmentación del dispositivo bajo prueba.
Vuelva a verificar que está usando firmware modificado si es necesario para su tarjeta de red inalámbrica. La herramienta
de prueba ya verifica esto automáticamente para dispositivos ath9k_htc. La herramienta de prueba también verifica
automáticamente si está usando controladores modificados, aunque podría ser bueno verificar esto manualmente en su
distribución de Linux específica.
Puede ayudar agregar un retardo entre obtener la dirección IP y la transmisión del primer fragmento/trama.
Haga esto usando el parámetro --pre-test-delay.
| Command | Short description |
|---|
ping I,E --amsdu-fake | Si esta prueba tiene éxito, se ignora la marca A-MSDU (§3.5). |
ping I,E --amsdu-fake --amsdu-spp | Comprueba si la marca A-MSDU es autenticada pero luego ignorada (§3.5). |
ping I,E,F,BE,E | En caso de que la nueva clave se instale relativamente tarde. |
ping I,E,F,AE | Variante si no se aceptan tramas de datos durante el handshake de renovación de clave. |
ping I,E,F,AE --rekey-plain | Si el dispositivo realiza el handshake de renovación de clave en texto plano. |
ping I,E,F,AE --rekey-plain --rekey-req | Igual que la anterior, y solicitar activamente una renovación de clave como cliente. |
ping I,E,F,AE --rekey-early-install | Instalar la nueva clave después de enviar el mensaje 3 del handshake de 4 vías. |
ping I,E,F,E [--rekey-pl] [--rekey-req] | Igual que las 4 pruebas anteriores, pero con mayor retardo antes del segundo fragmento. |
ping I,F,BE,AE --freebsd | Ataque de clave mixta contra FreeBSD o implementaciones similares. |
ping I,E,R,AE --freebsd [--full-reconnect] | Ataque de caché específico para implementaciones FreeBSD. |
ping I,E,R,AP --freebsd [--full-reconnect] | Ataque de caché específico para implementaciones FreeBSD. |
ping I,E,R,AP [--full-reconnect] | Prueba de ataque de caché donde el segundo fragmento se envía en texto plano. |
ping I,E,E --amsdu | Envía un ping normal como una trama A-MSDU fragmentada. |
ping I,E,P,E | Ping con el primer fragmento cifrado, el segundo en texto plano, el tercero cifrado. |
linux-plain 3 | Igual que linux-plain pero el fragmento señuelo se envía usando prioridad QoS 3. |
ping I,P --bcast-ra | Ping en una trama de difusión en texto plano después del HS de 4 vías. |
ping BP --bcast-ra [--bcast-dst] | Ping en trama de difusión en texto plano durante el HS de 4 vías (use tcpdump). |
ping BP [--bcast-dst] | Ping en una trama de texto plano durante el handshake de 4 vías (use tcpdump). |
eapfrag BP,BP | Ataque experimental de fragmentos de difusión (use tcpdump). |
eapol-amsdu[-bad] BP --bcast-dst | Igual que eapol-amsdu BP pero más fácil de verificar contra AP (use tcpdump). |
eapol-inject 00:11:22:33:44:55 | Prueba si el AP reenvía tramas EAPOL antes de la autenticación (use tcpdump). |
eapol-inject-large 00:11:22:33:44:55 | Hacer que el AP envíe tramas fragmentadas mediante inyección EAPOL (use tcpdump). |
ping I,D,E | Enviar ping dentro de un segundo fragmento cifrado (sin primer fragmento). |
ping I,E,D | Enviar ping dentro de un primer fragmento cifrado (sin segundo fragmento). |
--rekey-pl--rekey-plainframe contains "test_ping_icmp"eapfrag BP,AE