spanish_i_am_injecting_but_the_ivs_don_t_increase
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
spanish_i_am_injecting_but_the_ivs_don_t_increase [2007/07/17 08:45] – spanish | spanish_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: | ||
- | |||
- | ===== 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:// | ||
- | 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:// | ||
- | * Has colocado la interface en modo monitor y en el mismo canal que el punto de acceso. Ejecuta " | ||
- | |||
- | ath0 IEEE 802.11b | ||
- | Mode: | ||
- | Bit Rate=2 Mb/s | ||
- | Retry: | ||
- | Encryption key:off | ||
- | Power Management: | ||
- | Link Quality=0/ | ||
- | Rx invalid nwid: | ||
- | Tx excessive retries: | ||
- | |||
- | * 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. | ||
- | * 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. | ||
- | |||
- | Para que un punto de acceso acepte un paquete, la dirección MAC del cliente debe estar asociada. | ||
- | |||
- | La falta de asociación con el punto de acceso es la razón más habitual por la que falla la inyección. | ||
- | |||
- | Aquí está la pista típica. | ||
- | |||
- | Comando de inyección ejecutado (o similar): | ||
- | aireplay-ng -3 -b < | ||
- | aireplay-ng -3 -b 00: | ||
- | |||
- | 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/ | ||
- | Notice: got a deauth/ | ||
- | Read 17915 packets (got 3 ARP requests), sent 5854 packets... | ||
- | |||
- | Presta atención a los mensajes " | ||
- | |||
- | Otra forma de confirmar que la falta de asociación está causando problemas es ejecutar tcpdump y mirar los paquetes. | ||
- | |||
- | tcpdump -n -e -s0 -vvv -i ath0 | ||
- | |||
- | Aquí está el típico mensaje de error de tcpdump que estás buscando: | ||
- | |||
- | 11: | ||
- | |||
- | Presta atención que el punto de acceso (00: | ||
- | |||
- | Si solo quieres seleccionar los paquetes " | ||
- | |||
- | 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 < | ||
- | aireplay-ng -1 0 -e teddy -a 00: | ||
- | |||
- | Si ha ido bien verás algo como esto: | ||
- | 18: | ||
- | 18: | ||
- | 18: | ||
- | 18: | ||
- | |||
- | U otra variación para algunos puntos de acceso rebeldes: | ||
- | |||
- | aireplay-ng -1 6000 -o 1 -q 10 -e teddy -a 00: | ||
- | |||
- | Donde: | ||
- | * 6000 - Reautenticación cada 6000 segundos. | ||
- | * -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: | ||
- | 18: | ||
- | 18: | ||
- | 18: | ||
- | 18: | ||
- | 18: | ||
- | # etc... | ||
- | |||
- | En este punto, puedes abrir otra shell y probar la inyección. | ||
- | |||
- | ===== 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", | ||
- | |||
- | * 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. | ||
- | |||
- | * 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: | ||
- | |||
- | Aquí puedes ver un ejemplo de un fallo de autenticación: | ||
- | 8: | ||
- | 18: | ||
- | 18: | ||
- | 18: | ||
- | 18: | ||
- | 18: | ||
- | 18: | ||
- | 18: | ||
- | 18: | ||
- | 18: | ||
- | 18: | ||
- | |||
- | Presta atención a "Got a deauthentication packet" | ||
- | |||
- | 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 < | ||
- | |||
- | Donde: | ||
- | -d FF: | ||
- | - 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: | ||
- | | ||
- | Read 202 packets... | ||
- | | ||
- | Size: 68, FromDS: 0, ToDS: 1 (WEP) | ||
- | | ||
- | | ||
- | Dest. MAC = FF: | ||
- | Source MAC = 00: | ||
- | | ||
- | 0x0000: | ||
- | 0x0010: | ||
- | 0x0020: | ||
- | 0x0030: | ||
- | 0x0040: | ||
- | | ||
- | 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" | ||
- | |||
- | |||
- | ===== 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 | ||