Posted by Star | Posted in | Posted on 22:51
Ataque Inductivo.
El ataque inductivo (también conocido como ataque Arbaught) consiste en la generación parcial de paquetes 802.11 que son enviados al punto de acceso con la esperanza de que uno de ellos sea correcto y a partir del mismo ir generando el keystream del paquete cifrado original y por consiguiente conseguir descifrarlo.
Cuando digo punto de acceso debería decir Sistema de Distribución, pero vamos, es una forma "mas coloquial"
Esta generación “parcial” no debes confundirla con el ataque de fragmentación, pues si bien se envían “fragmentos” de un paquete, no se trata del mismo tipo de ataque.
El ataque inductivo será capaz de descifrar cualquier paquete de datos cifrado original y lo realiza desde “el principio hasta el final”, es decir, avanza progresivamente byte por byte desde el comienzo (o desde la posición que elijamos) hasta el último byte del paquete cifrado original.
Otros ataques (luego los veremos) como chopchop hacen algo similar pero descifran “a la inversa”, esto es, comiernzan de “atrás hacia delante”, desde el último byte del paquete cifrado original hasta el primero.
Además, ya veremos luego también, se puede combinar con otras ténicas como el “bit-flipping” para lograr el objetivo, que a la postre y en todos los casos de este tipo de ataques, son:
El ataque inductivo (también conocido como ataque Arbaught) consiste en la generación parcial de paquetes 802.11 que son enviados al punto de acceso con la esperanza de que uno de ellos sea correcto y a partir del mismo ir generando el keystream del paquete cifrado original y por consiguiente conseguir descifrarlo.
Cuando digo punto de acceso debería decir Sistema de Distribución, pero vamos, es una forma "mas coloquial"
Esta generación “parcial” no debes confundirla con el ataque de fragmentación, pues si bien se envían “fragmentos” de un paquete, no se trata del mismo tipo de ataque.
El ataque inductivo será capaz de descifrar cualquier paquete de datos cifrado original y lo realiza desde “el principio hasta el final”, es decir, avanza progresivamente byte por byte desde el comienzo (o desde la posición que elijamos) hasta el último byte del paquete cifrado original.
Otros ataques (luego los veremos) como chopchop hacen algo similar pero descifran “a la inversa”, esto es, comiernzan de “atrás hacia delante”, desde el último byte del paquete cifrado original hasta el primero.
Además, ya veremos luego también, se puede combinar con otras ténicas como el “bit-flipping” para lograr el objetivo, que a la postre y en todos los casos de este tipo de ataques, son:
- * Descifrar un paquete de datos original WEP
* Obtener un keystream para poder descifrar otros
* Obtener un keystream para poder inyectar nuevos paquetes a la red
El atacante parte del hecho que puede generar un paquete en texto plano conocido, este paquete no estará completo, puesto que el atacante desconoce muchos parámetros necesarios para poder inyectarlo, el atacante desconoce:
- * La clave WEP (obvio porque en otro caso todo esto no es necesario)
* El contenido original del paquete en texto plano (lógico también)
* El keystream original (por lo mismo de los dos anteriores)
* Las direcciones IP’s de la red (como no conoce el texto plano original, el atacante no puede generar paquetes propios en texto plano con las direcciones de red adecuadas)
Cómo???? Estás seguro?????
Sí.. El atacante mas que conocer, puede “reconstruir” parte de un paquete de datos en texto plano equivalente al paquete de datos cifrado.
De hecho, el atacante tiene una ventaja muy, muy interesante… como ya sabemos, un paquete 802.11 comienza siempre en sus 6 primeros bytes por la cabecera SNAP
Y esto sí lo conocemos!!!!
Además, ya dijimos que un atacante puede “asumir” que determinados paquetes son de un determinado tipo u otro atendiendo a su tamaño, por ejemplo, los paquetes del tipo ARP son:
- 68 bytes de longitud si no hay QoS
70 bytes de longitud si hay QoS
Para mayor sencillez en las explicaciones vamos a usar un ARP.
Un paquete ARP en una trama de datos 802.11 tiene esta forma
De estas 4 partes, nos interesa sólo la zona de DATOS.
Asumiendo que se tratase de un paquete ARP, podemos reconstruirlo (aproximadamente) así:
Los datos que están reslatados en verde serán siempre los mismos para cualquier paquete ARP, los conocemos SEGURO por lo que los primeros 15 bytes cifrados podemos obtener su keystream.
Los bytes resaltados en amarillo son desconocidos, pero podemos “intuirlos” o pocas son sus variaciones, por ejemplo:
El byte 16 (la primera XX en amarillo) sería:
- 01 Si es un Request (Solicitud ARP)
02 Si es un Response (Respuesta ARP)
Los bytes correspondientes a MAC ORIGEN Y/o MAC DESTINO también los podemos “intuir” observando la cabecera 802.11 que te recuerdo no está cifrada, aunque existe un problema:
- Si se tratase de un ARP Request MAC DESTINO debería ser 00 00 00 00 00 00
Si se tratase de un ARP Response Target MAC será la mac de quien originó la solicitud.
Los bytes en Rojo, son TOTALMENTE DESCONOCIDOS por el atacante.
Por tanto, si quiesiéramos realizar un ataque inductivo de este paquete, lo mejor será comenzar por el byte 16 (que es el primero que desconocemos, el primero de la zona amarilla).
En total, los datos cifrados son: 36 bytes para datos y 4 para el ICV, de los cuales conocemos 15.
El tamaño completo de la trama “a buscar” sería:
Lo que debemnos hacer es lo siguiente:
1.- Generar una cabecera 802.11 válida, esto no ofrece dificultad alguna puesto que esa información siempre se transmiten en texto plano y podemos manipularlos como si tal cosa.
Esta cabecera incluirá:
Un Frame control de tipo 08 41 (trama de datos normal con el bit toDS activado y bit wep activado)
Una duración: XX XX, la que queramos
Las MAc’s destino-origen y BSSID, las que queramos y/o acordes a la red en la que nos movemos, tampoco es difícil puesto que las obtenemos en claro.
Un número de secuencia: XX XX el que queramos
Total cabecera 802.11 = 2 + 2 + 18 + 2 = 24 bytes de cabecera (sin QoS)
2.- Añadimos el IV original del paquete capturado (4 bytes)
3.- Añadimos los primeros 15 bytes (la zona verde del paquete ARP) que se corrsponden a lo que el atacante conoce SIEMPRE
4.- Hacemos XOR de los 15 primeros bytes del paquete cifrado original con los 15 bytes del paquete en texto plano que ya conocemos, y obtenemos un keystream para esos primeros 15 bytes.
5.- Se calcula un ICV para estos 15 bytes conocidos (4 bytes)
Por el momento tenemos que el total de nuestra trama es:
24 de cabecera 802.11 + 4 IV + 15 Datos + 4 ICV = 47 bytes
6.- Enviamos una trama con 15 bytes – 3 = 12 bytes de datos y le añadimos el ICV -1 byte
Por tanto, enviamos:
24 de cabecera + 4 del IV + 12 bytes de datos + 3 icv = 43 bytes
A esta operación le iremos añadiendo un byte al final (el del icv) por cada una de las combinaciones posibles (desde 0 a 256, desde 0x00 a 0xFF) y observamos si hay respuesta, si “acertamos” la estación o el Punto de acceso lanzará el paquete y deducimos que hemos acertado.
Si no hay respuesta, probamos un nuevo valor, así hasta el 256.
7.- Una vez obtenida la respuesta, sabremos cual es el byte correcto para la última posición (la 16), ese byte “adivinado” será el keystream para el byte cifrado número 16, por lo que si hacemos XOR tendremos su valor en plano (y según el ejemplo, ya sabremos si es un ARP REQ o RESP).
8.- Repetimos todo el proceso desde el paso 3, sólo que ahora en lugar de tomar los primeros 15 bytes, tomamos los primeros 16 (este último lo descubrimos en el paso 6 y 7) y obtendremos el byte 17,
Si repetimos esta operación para todos y cada uno de los bytes de datos cifrados, obtendremos la totalidad del paquete descifrado y una keystream que nos permitirá reinyectar o cifrar/descifrar otros nuevos.
Resumiendo, el ataque inductivo se basa en que al conocer “parte” del texto plano de un paquete cifrado, podemos ir calculado su ICV y probando a enviar “partes” del mismo alterando el último byte.
Te pongo una figura que ayuda MUCHO a entender todo esto:
Por cada una de las “tandas de comprobación de los 256 bytes” deberíamos obtener al menos una respuesta correcta!!! Cuando esto ocurra, hacemos:
De este modo ya tenemos el keystream, el texto plano y el byte cifrado (este último ya era conocido) del byte número 16.
Si te fijas, antes dije:
Por cada una de las “tandas de comprobación de los 256 bytes” deberíamos obtener al menos una respuesta correcta!!!
Presta atención a las palabras “deberíamos” y “al menos una respuesta”
“Deberíamos” porque nadie nos asegura que no haya errores en la transmisión, o que el punto de acceso al recibir muchos paquetes inválidos antes del bueno emita desautenticaciones, etc… por eso “deberíamos”.
“al menos una respuesta” porque puede haber mas, tampoco nadie nos asegura que otras estaciones utilicen este mismo IV y provoquen resultados “similares” o iguales a los esperados.
Y qué pasa si ocurre alguna de estas “cosas”???
Qué ocurresi no obtenemos respuesta o si la respuesta es un falso positivo???
Pues que “el siguiente” byte a descifrar será erróneo y no producirá respuestas y/o resultados, de eso nos daremos cuenta cuando tras probar las 256 combinaciones posibles no obtenemos nada...
Entonces???
Entonces lo que hay que hacer es repetir, pero no hace falta empezar desde el primero, por ejemplo, si esa circunstancia se da en el byte número 27, repetimos todo el proceso desde el 26 (el último que se consiguió)
Y si falla en el primero, para nuestro ejemplo en el 15????
Pues no podemos seguir, el ataque debe finalizar y probar de nuevo, esta vez sí, desde el principio.
El caso es que si todo va bien y no encontramos “inconvenientes” la operación se repite para el byte 16, 17, 18, etc… así hasta el último.
Para nuestro ejemplo sonl 36 de datos + 4 del ICV = 40
Comments (0)
Publicar un comentario