WEP (Wired Equivalent Privacy) no fue retirado por capricho: fue sistemáticamente desmontado por múltiples ataques que explotaban defectos de diseño fundamentales. En este artículo analizamos cada uno de estos ataques, desde los estadísticos sobre RC4 hasta la manipulación del ICV y la explotación de Open System Authentication.
Ataque FMS — Fluhrer, Mantin y Shamir
El ataque FMS es un ataque de deducción estadística diseñado para recuperar la clave WEP analizando miles de paquetes cifrados capturados. Fue publicado en 2001 por Scott Fluhrer, Itsik Mantin y Adi Shamir, y demostró por primera vez que WEP era criptográficamente inseguro.
Relación entre ciphertext, plaintext y keystream
El ciphertext WEP es el resultado de aplicar XOR entre el texto plano y el keystream generado por RC4:
ciphertext = plaintext ⊕ keystream
keystream = ciphertext ⊕ plaintext
La clave está en que los primeros bytes del plaintext en WEP son predecibles, porque el tipo de trama determina el formato. Por ejemplo:
- Tramas LLC/SNAP: comienzan siempre por
0xAA 0xAA 0x03 - Imágenes JPG: comienzan por
0xFF 0xD8 0xFF - Imágenes PNG: comienzan por
0x89 0x50 0x4E 0x47
Conociendo el primer byte del plaintext y el del ciphertext capturado, podemos deducir el primer byte del keystream:
Primer byte del ciphertext = 0x2A
Primer byte del plaintext = 0xAA (LLC/SNAP conocido)
──────────────────────────────────────
Primer byte del keystream = 0x2A ⊕ 0xAA
La fórmula estadística real del ataque FMS
La deducción simple del keystream no revela la clave. El ataque FMS va más allá: estudia los sesgos estadísticos en el KSA (Key Scheduling Algorithm) de RC4. Los investigadores descubrieron que, con ciertos IVs llamados "IVs débiles", el primer byte del keystream generado por RC4 está correlacionado con un byte concreto de la clave WEP con una probabilidad mayor que 1/256 (lo esperable en una distribución uniforme).
Cómo llegaron a esta conclusión
Analizaron el KSA paso a paso. Estudiaron los primeros pasos (i = 0, 1, 2, 3...) y cómo dependen de los bytes del IV y de la clave real.
Hicieron suposiciones razonables. En los primeros pasos, el array S está casi en su estado inicial. Esto permite aproximar S[i] como si no hubiera sido alterado.
Derivaron condiciones sobre j. Para IVs débiles, el valor de j queda muy restringido y puede expresarse como: j ≈ f(IV, ki)
Conectaron KSA con PRGA. Bajo ciertas condiciones, el primer byte del keystream (producido por el PRGA) está correlacionado con un byte de la clave.
Midieron el sesgo estadísticamente. No es determinista. Para IVs débiles, la probabilidad de que el primer byte del keystream revele ki es mayor que 1/256. Con suficientes muestras, el byte con más "votos" es el real.
Ataque KoreK
KoreK es una mejora posterior al ataque FMS publicada de forma anónima en 2004. Introduce 16 correlaciones estadísticas distintas sobre el KSA de RC4, en lugar de la única correlación original de FMS. Esto permite recuperar la clave WEP con muchos menos paquetes capturados, reduciendo considerablemente el tiempo necesario.
FMS (2001)
1 correlación. Requería del orden de millones de paquetes con IVs débiles.
KoreK (2004)
16 correlaciones. Reduce dramáticamente el número de paquetes necesarios.
PTW (2007)
No filtra IVs débiles. Usa todos los paquetes. Rompe WEP-128 con ~40.000 paquetes.
Ataque PTW — Pyshkin, Tews y Weinmann
El ataque PTW (2007) es la versión más eficiente y la que implementa aircrack-ng por defecto. Su principal ventaja respecto a FMS y KoreK es que no necesita filtrar IVs débiles: aprovecha estadísticamente todos los paquetes capturados, incluyendo el byte completo del payload ARP (no solo el primer byte del keystream).
Ataques de reinyección de tráfico
Los ataques estadísticos (FMS, KoreK, PTW) necesitan acumular grandes cantidades de paquetes. La reinyección de tráfico acelera artificialmente este proceso: el atacante captura un paquete válido (típicamente un ARP) y lo reenvía repetidamente al AP, que lo procesa y responde generando un nuevo paquete con un IV distinto cada vez.
El atacante captura un paquete ARP cifrado de un cliente legítimo.
Reenvía ese mismo paquete al AP repetidamente (sin necesidad de descifrarlo).
El AP responde a cada reinyección generando un paquete nuevo con un IV diferente.
En minutos se acumulan decenas de miles de paquetes con IVs distintos, suficientes para el ataque PTW.
Ataque de autenticación falsa (Open System)
Para poder reinyectar tráfico, el atacante necesita estar asociado al AP. La autenticación falsa usa el mecanismo de Open System Authentication (OSA), que se incluyó en el estándar IEEE 802.11-1997 para garantizar compatibilidad universal: cualquier dispositivo puede autenticarse y asociarse sin proporcionar clave alguna.
Paso 1 — El atacante se asocia al AP
El atacante envía una trama de autenticación con tipo "Open System" usando cualquier dirección MAC (real o inventada). El AP no verifica criptográficamente la MAC y responde con Status Code 0 (éxito). A continuación, el atacante envía un "Association Request" y queda oficialmente asociado al AP como cliente legítimo.
Paso 2 — Qué puede hacer el atacante una vez asociado
- Reinyectar tramas ARP: acelera la captura de IVs para criptoanálisis.
- Forzar tráfico predecible: genera paquetes con estructura conocida que facilitan los ataques FMS/PTW.
- Simular un cliente activo: útil cuando no hay clientes legítimos en la red.
Ataque al ICV — Manipulación del CRC-32
WEP usa un CRC-32 como ICV (Integrity Check Value) para verificar que los datos no se han corrompido durante la transmisión. El problema fundamental: CRC-32 no es un mecanismo criptográfico. Fue diseñado para detectar errores accidentales, no para resistir modificaciones intencionales.
¿Por qué CRC-32 es vulnerable?
CRC-32 es lineal respecto a XOR. Esto significa que si modificas los datos de una forma concreta, puedes predecir exactamente cómo cambiará el CRC y ajustarlo para que siga siendo válido, sin necesidad de conocer la clave WEP.
CRC-32(A ⊕ B) = CRC-32(A) ⊕ CRC-32(B)
Cómo funciona el ataque — Secuencia
Captura un paquete cifrado. El atacante observa un paquete WEP en el aire con su ciphertext e ICV. No necesita la clave WEP.
Decide qué bits modificar. WEP usa RC4 (cifrado de flujo), por lo que un cambio de bits en el ciphertext produce exactamente los mismos cambios en el plaintext descifrado.
Recalcula el ICV. Gracias a la linealidad de CRC-32, puede calcular el delta del ICV que corresponde a sus cambios y aplicarlo al ICV cifrado sin descifrar nada.
Reenvía el paquete modificado. El AP recibe el paquete alterado, calcula el ICV sobre los datos descifrados, lo compara con el ICV recibido y — como coinciden — acepta el paquete.
¿Para qué se usa este ataque?
- Reducir el TTL para provocar que el paquete expire inmediatamente.
- Cambiar un puerto de destino o tipo de mensaje ARP.
- Modificar flags para provocar retransmisiones predecibles.
- Inyectar paquetes nuevos con contenido controlado por el atacante.
Ataque a SKA — Shared Key Authentication
WEP incluía dos métodos de autenticación: Open System (sin clave) y Shared Key Authentication (SKA). Irónicamente, SKA, diseñada para ser el método "seguro", introduce una vulnerabilidad adicional que Open System no tiene.
Cómo funciona SKA
- El AP envía un desafío en claro (texto aleatorio visible en la trama).
- El cliente lo cifra con WEP y devuelve el desafío cifrado.
- El AP descifra la respuesta y verifica que coincide con el desafío original. Si coincide, el cliente queda autenticado.
Por qué es vulnerable
Un atacante que escucha pasivamente obtiene simultáneamente:
- El desafío en claro (enviado por el AP sin cifrar).
- El desafío cifrado (la respuesta del cliente).
Con ambos, puede calcular el keystream exacto usado en esa sesión de autenticación:
keystream = desafío_cifrado ⊕ desafío_en_claro
Con ese keystream, el atacante puede responder a futuros desafíos del AP y autenticarse sin conocer la clave WEP, haciéndose pasar por un cliente legítimo. El atacante no aprende la clave, pero puede impersonar a un cliente autenticado.
Resumen — Por qué WEP es irrecuperable
Todos estos ataques tienen una raíz común: el diseño fundamental de WEP es defectuoso.
IV de 24 bits
Solo ~16,7 millones de IVs posibles. En redes activas, se repiten en horas. Dos paquetes con el mismo IV usan idéntico keystream.
Clave estática
La misma clave WEP se usa para siempre. No hay renovación automática. Una vez obtenida, todo el tráfico queda comprometido.
RC4 con IVs débiles
La construcción IV‖clave genera IVs débiles que filtran información sobre la clave a través de sesgos estadísticos del KSA.
CRC-32 lineal
El ICV no es criptográfico. Cualquier atacante puede modificar paquetes y ajustar el ICV sin conocer la clave WEP.