Este proyecto contiene scripts para comprobar si los clientes o puntos de acceso (AP) están afectados por el ataque KRACK contra WPA2. Para más detalles sobre este ataque, consulte nuestro sitio web y el artículo de investigación.

Recuerde que nuestros scripts no son scripts de ataque. Necesitará las credenciales de red adecuadas para comprobar si un punto de acceso o cliente está afectado por el ataque KRACK.

Diciembre de 2024: se ha corregido un error en la séptima prueba ./krack-test-client.py --gtkinit. Antes de esta corrección, se mencionaba que (la salida de) esta prueba no era fiable, pero ahora la salida debería ser fiable si se siguen las nuevas instrucciones. Es decir, cuando esta prueba indica ahora que el dispositivo es vulnerable, es muy probable que realmente lo sea.

Enero de 2021: los scripts se han hecho compatibles con Python3 y se han actualizado para dar mejor soporte a las distribuciones Linux más recientes. Si desea volver a la versión anterior, ejecute git fetch --tags && git checkout v1 después de clonar el repositorio (y vuelva a la última versión con git checkout research).

Requisitos previos

Nuestros scripts se probaron en Kali Linux. Para instalar las dependencias necesarias en Kali, ejecute:

sudo apt update
sudo apt install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python3-venv iw

Ahora compile nuestra instancia modificada de hostapd y cree un entorno virtual de Python. Esto asegura que está utilizando bibliotecas de Python compatibles (las que se enumeran en krackattack/requirements.txt):

git clone https://github.com/vanhoefm/krackattacks-scripts.git
cd krackattacks-scripts/krackattack
./build.sh
./pysetup.sh

A continuación, desactive el cifrado por hardware para obtener resultados óptimos:

cd krackattack
sudo ./disable-hwcrypto.sh

Tenga en cuenta que, si es necesario, puede volver a activar el cifrado por hardware más tarde con el script sudo ./reenable-hwcrypto.sh. Se recomienda reiniciar después de desactivar el cifrado por hardware. Probamos nuestros scripts con una Intel Dual Band Wireless-AC 7260 y una TP-Link TL-WN722N v1 en Kali Linux.

Antes de cada uso

Cada vez que vaya a usar los scripts debe desactivar la Wi-Fi en su administrador de red. Luego ejecute:

sudo rfkill unblock wifi
cd krackattack
sudo su
source venv/bin/activate

Después de hacer esto, puede ejecutar los scripts varias veces siempre que no cierre la terminal.

Si desea revertir los efectos de disable-hwcrypto.sh, elimine el archivo /etc/modprobe.d/nohwcrypt.conf.

Prueba de clientes

Primero modifique hostapd/hostapd.conf y edite la línea interface= para especificar la interfaz Wi-Fi que se usará para ejecutar las pruebas. Tenga en cuenta que, en todas las pruebas, una vez que el script esté en ejecución, debe dejar que el dispositivo bajo prueba se conecte al SSID testnetwork con la contraseña abcdefgh. Puede cambiar la configuración del AP modificando hostapd/hostapd.conf. En todas las pruebas, el cliente debe usar DHCP para obtener una IP después de conectarse a la red Wi-Fi. Esto se debe a que algunas pruebas solo comienzan después de que el cliente haya solicitado una IP mediante DHCP.

Ahora debe ejecutar las siguientes pruebas ubicadas en el directorio krackattacks/:

1. ./krack-test-client.py --replay-broadcast. Esta prueba comprueba si el cliente acepta tramas de difusión repetidas. Si el cliente acepta tramas de difusión repetidas, esto debe ser corregido primero. Si no corrige el cliente, nuestro script no podrá determinar si la clave de grupo se está reinstalando (porque entonces el script siempre dirá que la clave de grupo se está reinstalando).

2. ./krack-test-client.py --group --gtkinit. Esta prueba comprueba si el cliente instala la clave de grupo en el handshake de clave de grupo con el contador de secuencia de recepción (RSC) dado. Consulte la sección 6.4 de nuestro artículo de investigación complementario para conocer los detalles de esta vulnerabilidad.

3. ./krack-test-client.py --group. Esta prueba comprueba si el cliente reinstala la clave de grupo en el handshake de clave de grupo. En otras palabras, comprueba si el cliente es vulnerable a CVE-2017-13080. El script comprueba las reinstalaciones de la clave de grupo enviando solicitudes ARP de difusión al cliente con un número de paquete ya utilizado (repetido) (aquí número de paquete = nonce = IV). Tenga en cuenta que si el cliente siempre acepta tramas de difusión repetidas (ver --replay-broadcast), esta prueba podría concluir incorrectamente que la clave de grupo se está reinstalando.

4. ./krack-test-client.py. Esta prueba comprueba las reinstalaciones de claves en el handshake de 4 vías enviando repetidamente mensajes 3 cifrados al cliente. En otras palabras, comprueba CVE-2017-13077 (la vulnerabilidad de mayor impacto) y CVE-2017-13078. El script supervisa el tráfico enviado por el cliente para ver si la clave pairwise se está reinstalando. Tenga en cuenta que esto efectivamente realiza dos pruebas: si la clave pairwise se reinstala y si la clave de grupo se reinstala. Asegúrese de que el cliente solicite una IP mediante DHCP para que comience la prueba de reinstalación de la clave de grupo. Para asegurarse de que el cliente envíe suficientes tramas unicast, puede hacer ping al AP opcionalmente: .

También recomendamos ejecutar esta prueba en entornos con poco ruido de fondo y ejecutarla varias veces.

Algunas observaciones adicionales:

• La prueba más importante es ./krack-test-client, que comprueba las reinstalaciones de claves ordinarias en el handshake de 4 vías.

• Realice estas pruebas en una sala con poca interferencia. Una gran cantidad de pérdida de paquetes hará que este script sea menos fiable.

• Opcionalmente, puede inspeccionar manualmente el tráfico de red para confirmar la salida del script (algunas tarjetas de red Wi-Fi pueden interferir con nuestros scripts):

  • Use una tarjeta de red Wi-Fi adicional en modo monitor para confirmar que nuestro script (el AP) envía tramas con los números de paquete (IV) adecuados. En particular, compruebe si las tramas de difusión repetidas se envían de hecho con un número de paquete (IV) ya utilizado.

  • Use una tarjeta de red Wi-Fi adicional en modo monitor para comprobar las reinstalaciones de la clave pairwise supervisando los IV de las tramas enviadas por el cliente.

  • Capture tráfico en el cliente para ver si las solicitudes ARP de difusión repetidas se aceptan o no.

• Si el cliente puede usar varias radios/tarjetas de red Wi-Fi, realice la prueba con varias tarjetas de red Wi-Fi.

• Puede añadir el parámetro --debug para obtener más salida de depuración.

• Todos los parámetros no reconocidos se pasan a hostapd, por lo que puede incluir algo como -dd -K para que hostapd muestre toda la información de depuración.

Correspondencia con las pruebas de Wi-Fi Alliance

La Wi-Fi Alliance creó una herramienta personalizada de detección de vulnerabilidades basada en nuestros scripts. Al momento de escribir esto, esta herramienta solo es accesible para los miembros de Wi-Fi Alliance. Su herramienta admite varias pruebas diferentes, y estas pruebas se corresponden con la funcionalidad de nuestro script de la siguiente manera:

• 4.1.1 (Retransmisión en texto plano del mensaje 3 de EAPOL). Actualmente no admitimos esta prueba. Esta prueba no es necesaria de todos modos. Asegúrese de que el dispositivo bajo prueba pase la prueba 4.1.3 y, entonces, también pasará esta prueba.

• 4.1.2 (Retransmisión inmediata de EAPOL M3 en texto plano). Actualmente no admitimos esta prueba. De nuevo, asegúrese de que el dispositivo bajo prueba pase la prueba 4.1.3 y, entonces, también pasará esta prueba.

• 4.1.3 (Retransmisión inmediata de EAPOL M3 cifrado durante el handshake de renovación de clave pairwise). Esto corresponde a ./krack-test-client.py, excepto que los EAPOL M3 cifrados se envían periódicamente en lugar de inmediatamente.

• 4.1.5 (Reinstalación de PTK en el handshake de 4 vías cuando la STA usa una construcción PTK temporal, mismo ANonce). Ejecute esta prueba con ./krack-test-client.py --tptk.

• 4.1.6 (Reinstalación de PTK en el handshake de 4 vías cuando la STA usa una construcción PTK temporal, ANonce aleatorio). Ejecute esta prueba con ./krack-test-client.py --tptk-rand.

• 4.2.1 (Prueba de vulnerabilidad del handshake de clave de grupo en la STA). Ejecute esta prueba con ./krack-test-client.py --group.

• 4.3.1 (Reinstalación de GTK e IGTK en la STA compatible con el modo de suspensión WNM). Actualmente no admitimos esta prueba (¡y tampoco lo hace la Wi-Fi Alliance en realidad!).

Prueba de puntos de acceso: Detección de un handshake FT vulnerable (802.11r)

1. Cree un archivo de configuración de wpa_supplicant que pueda usarse para conectarse a la red. Un ejemplo básico es:

   root@kitploit:~

    ctrl_interface=/var/run/wpa_supplicant
    network={
      ssid="testnet"
      key_mgmt=FT-PSK
      psk="password"
    }
   

   Observe el uso de "FT-PSK". Guárdelo como network.conf o similar. Para más información, consulte wpa_supplicant.conf.

2. Intente conectarse a la red usando el wpa_supplicant de su plataforma. Esto probablemente requiera un comando como:

   root@kitploit:~

    sudo wpa_supplicant -D nl80211 -i wlan0 -c network.conf
   

   Si esto falla, o bien el AP no es compatible con FT, o bien proporcionó opciones de configuración de red incorrectas en el paso 1. Tenga en cuenta que si el AP no es compatible con FT, no está afectado por esta vulnerabilidad.

3. Use este script como envoltorio del comando wpa_supplicant anterior:

   root@kitploit:~

    sudo su
    source venv/bin/activate
    ./krack-ft-test.py wpa_supplicant -D nl80211 -i wlan0 -c network.conf
   

   Esto ejecutará el comando wpa_supplicant con los parámetros proporcionados y añadirá una interfaz de monitor virtual que realizará pruebas de ataque. Es importante primero convertirse en root y luego cargar el entorno virtual de Python (consulte arriba cómo crear este entorno virtual).

4. Use wpa_cli para hacer roaming a otro AP de la misma red. Por ejemplo:

   root@kitploit:~

    wpa_cli -i wlan0
    > status
    bssid=c4:e9:84:db:fb:7b
    ssid=testnet
    ...
    > scan_results 
    bssid / frequency / signal level / flags / ssid
    c4:e9:84:db:fb:7b	2412  -21  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
    c4:e9:84:1d:a5:bc	2412  -31  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
    ...
    > roam c4:e9:84:1d:a5:bc
    ...
   

Extra: Descifrado por hardware

Para confirmar que el descifrado por hardware está desactivado, ejecute systool -vm ath9k_htc o similar después de conectar su tarjeta de red Wi-Fi para confirmar que se ha establecido el parámetro nohwcript/swcrypto/hwcrypto. Tenga en cuenta que debe reemplazar ath9k_htc con el módulo del kernel de su tarjeta de red inalámbrica.

Extra: 5 GHz no compatible

No hay soporte oficial para probar dispositivos en la banda de 5 GHz.

Si no obstante desea usar la herramienta 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 las 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, del país configurado actualmente y del AP al que esté conectado. Para obtener más información, consulte, por ejemplo, la documentación de Arch Linux.

Tenga en cuenta que el kernel de Linux puede no permitir la inyección de tramas aunque sí esté permitido 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 en realidad esté permitido. Hacer que cfg80211_reg_can_beacon devuelva true en las condiciones correctas (o en todas) evita este error. Así que tendrá que parchear los controladores de Linux para que cfg80211_reg_can_beacon devuelva siempre true, por ejemplo, parcheando manualmente el código del controlador packport.

Extra: Pruebas manuales

También es posible realizar manualmente pruebas (más detalladas) clonando el repositorio git de hostap:

git clone git://w1.fi/srv/git/hostap.git

Y siguiendo las instrucciones en tests/cipher-and-key-mgmt-testing.txt.