Autor
Todos los ataques que estamos estudiando, tienen un punto común: La reutilización de un IV
Como ya dije hace tiempo, esto es precisamente el mayor problema de WEP, no hay control sobre el uso de un mismo IV, peor aún, tal y como está diseñado el protocolo, no tiene solución.
Por tanto lo único que un administrador puede hacer contra ataques de tipo replay (sa sea una reinyección, ataque inductivo, reactivo, chopchop, flipping, etc...) es disponer de sensores en la red que le adviertan de tal circunstancia.
Los IDS inalámbricos incorporan este tipo de alertas, nosotros vamos a diseñar una muy sencilla.
El programa lo he bautizado detectorIV.c lo puedes descargar desde:
http://www.megaupload.com/?d=M7YP4VZ2
Lo guardamos junto los códigos fuente de aircrack y lo compilamos:
Código:
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 -Iinclude -c -o detectorIV.o detectorIV.c
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0 -Iinclude detectorIV.o common.o crypto.o -o detectorIV -Losdep -losdep -lssl -lcrypto
El funcionamiento del mismo es muy simple:
El programa llama a una función: detectar_reenvio
En esta función, se introduce la red a controlar (en esta ocasión y para variar un poco de los otros ejercicios), en lugar de pasar un Bssid como parámetro, debemos escribir el ESSID.
Quizás de lo mas significativo de este programa de cara a este Taller WiFi es el modo en el que se conoce el essid de un paquete capturado.
Los essid pueden viajar en diferentes tramas, en beacons, probes y alguna otra también como los EAP.
En este caso analizamos una trama de tipo beacon, es una trama de administración por lo que lo primero que tiene que hacer nuestro programa es analizar ese tipo de trama.
Para saber si es una trama de administración tipo beacon basta con comprobar si el byte cero (el primer byte del Frame Control) es igual o no a 0x80.
Si se trata de un beacon (byte 0 es 0x80) debemos analizar los bytes 36,37 y sucesivos, de forma que:
Código:
256 x el contenido del byte 36 + contenido del byte 37 = longitud del essid
En nuestro ejemplo, el essid que buscamos es TallerWIFI, esto son 10 bytes de longitud, por lo que byte 36 = 0x00 y byte 37 = 0x0A (10 en decimal)
Los bytes 38 y siguientes contienen cada una de las “letras” del essid.
Código:
Byte 38 = T
Byte 39 = a
Byte 40 = l
Byte 41 = l
Byte 42 = e
Byte 43 = r
Byte 44 = W
Byte 45 = I
Byte 46 = F
Byte 47 = I
De ese modo poremos comparar si lo escrito por teclado se corresponde con lo capturado en el aire.
Una vez leído el beacon correcto extraemos el bssid de la red, esto está en la posición +10 del paquete capturado y tendrá (claro está) una longitud de 6 bytes.
Con el bssid apropiado, la función continua con el análisis de paquetes de datos y entra en un ciclo infinito el cual almacena en diferentes arrays los últimos 200 paquetes leídos.
Cada vez que se completen esos 200 paquetes se analizan todos con todos en busca de IV’s duplicados, si en esa “ráfaga” de 200 paquetes capturados encontramos mas de un 5% de IV’s duplicados (10 IV’s) se asume que hay ataque contra la red.
El programa mostrará el IV repetido, la mac origen, la mac destino en el caso de que existan duplicidades (mas de 20)
Sería posible “bajar” ese umbral de IV’s, por ejemplo, cuando se detecte mas de uno duplicado, pero puede arrojar falsos positivos, sobretodo en redes muy grandes.
También has de tener en cuenta que son 200 paquetes de datos, es decir, el programa discrimina los beacon, probes, tramas de control y administración. Si en esos 200 paquetes se encuentran mas de 10 duplicados, es que hay ataque a la vista.
Lo mismo que de costumbre, en el código hay comentarios acerca de cada línea (las interesantes) es conveniente que lo revises para que comprendas el funcionamiento del mismo.
No es que esté muy depurado, pero puede servir, si lo ejecutas….
Código:
Taller_WiFi src # ./detectorIV eth1
Escribe el ESSID de la red a monitorizar --> TallerWIFI
Esperando un beacon de: TallerWIFI -->
Recibido un beacon de: TallerWIFI
BSSID --> 28:F4:D1:B7:FC:EF
Esperando paquetes de datos.....
Capturado IV num: 199 [B1 74 00 00]
Ataque de reinyección detectado!!!
IV duplicado MAC Origen MAC Destino Num. Duplicados
============ ========== =========== ===============
B1 74 00 00 00 17 9A C3 D6 B9 00 A0 CC D0 EB 5A 13 repetidos de 200 IV's procesados
Capturado IV num: 399 [B1 74 00 00]
Ataque de reinyección detectado!!!
IV duplicado MAC Origen MAC Destino Num. Duplicados
============ ========== =========== ===============
B1 74 00 00 00 A0 CC D0 EB 5A 00 A0 CC D0 EB 5A 195 repetidos de 200 IV's procesados
Capturado IV num: 599 [B1 74 00 00]
Ataque de reinyección detectado!!!
IV duplicado MAC Origen MAC Destino Num. Duplicados
============ ========== =========== ===============
B1 74 00 00 00 A0 CC D0 EB 5A 00 A0 CC D0 EB 5A 197 repetidos de 200 IV's procesados
......
......
Hasta aquí esta tercera parte de vulnerabilidades WEP, por el momento, todos los ataques de “adivinación” para descifrar el mensaje protegido con WEP se basan en el conocimiento completo del texto plano (caso de ataquePLANO.c) o parcial (caso del arpdecode4.c) de un paquete cifrado.
En estas pruebas, el atacante era conocedor de la totalidad del contenido del mensaje en texto plano o podía suponer una parte del mismo y reconstruir el resto mediante el ataque inductivo.
Las siguientes pruebas que haremos (en la cuarta parte y siguientes) ya no partirán de estas premisas, en las prácticas venideras, el atacante desconocerá por completo el mensaje que se está transmitiendo, no se harán “suposiciones” acerca si es un ARP, TCP, UDP, etc.. sencillamente será “un misterio”, y sin embargo como veremos, seremos capaces de descifrar el mensaje completo y obtener el keystream necesario para poder enviar cualquier paquete de datos a la red.
Hasta entonces
En línea
