ATAQUE CHOPCHOP DE KoreK. Ataque mediante predicción de CRC. Por o2T7f6j2





Esto es sólo una extensión de la documentación del aircrack , sólo un ejemplo para demostrar que el ataque de KoreK es ciertamente muy efectivo con algunos Puntos de Acceso o redes inalámbricas en las que se cumplen algunas condiciones especiales.

Muchas veces podemos ver cómo capturando el tráfico de un punto de acceso con nuestra tarjeta en modo Monitor vemos que éste suelta un paquete encriptado de vez en cuando.

Normalmente se trata de lo que llamamos paquetes ARP, que siendo reinyectados mediante el ataque -3 de aireplay generarán una cantidad de respuestas suficiente y a una velocidad considerable. Pero ¿Por qué aireplay no reconoce estos paquetes como peticiones ARP que se pueden reinyectar? Pues sencillamente porque no lo son. Hay veces que en otros protocolos se difunden periódicamente paquetes y no tienen por qué ser necesariamente ARP.

Aquí es donde entra el ataque mediante predicción de CRC. Y donde toma sentido la línea de la documentación del aircrack "Redifusión de cualesquiera datos" (no sólo paquetes ARP).

En la documentación viene explicado muy claro, por eso digo que esto no es más que un ejemplo de uso.



Bueno, comencemos

Todas las MAC son inventadas, además de IMPOSIBLES. Incluídas las de las capturas, que están retocadas con GIMP.

Iniciamos la captura con airodump (por ejemplo)

Ya tenemos la captura realizada con airodump. Donde nos aparecen 3 paquetes capturados catalogados como #data



Nos asociamos

E intentamos reinyectar "nuestros ARP"
Pero efectivamente vemos que al tratar de reinyectar nuestras supuestas peticiones ARP con el ataque -3 aireplay nos dice que no, que no hay nada que reinyectar. Nunca suben los ARP requests a pesar de que sabemos que tenemos 3 preciados IVs en nuestra captura, la que hemos indicado a aireplay mediante la opción -r (captura_chophop.cap)


Entonces probamos el ataque -4, como dice la documentación desencriptando primero un paquete (vemos que aquí ponemos com cliente la dirección MAC del AP, y es que es así como nos aparece en nuestras capturas, luego veremos por qué ocurre esto)

Y comienza a hacer su trabajo.



Una vez tenemos el resultado



Usamos tcpdump para ver la IP que nos interesa


Que nos devuelve algo como esto


Aquí ya vemos por primera vez de qué tipo de paquetes se trababa Exactamente lo vemos en "RIPv2, Response" (que no "ARP, Request" )

Con esta información ahora sí que es posible forjar nuestra petición ARP


Como veis me invento la 192.168.1.100 (dejo la misma que en el ejemplo del doc en realidad), pero la dirección de destino debe corresponder a la obtenida con tcpdump (en este caso 192.168.1.520)

Y listo! Ya podemos ponernos a reinyectar nuestra nueva y reluciente petición ARP


NOTA IMPORTANTE : Puede haber algún fallo . No dudéis a la hora de avisar

No hace falta tener un servicio como el enrrutamiento dinámico con RIPv2, esto se puede probar con "cualesquiera datos" 

El resultado:


y espero que os sirva.



.

Gracias canido. No es nada.



¿A la opción -b te refieres? Está puesta. Joder qué cortito soy, no sé qué me quieres decir 


No, lo toma directamente desde la tarjeta en modo Monitor. Se supone que una tarjeta no puede estar comunicando en modo infraestructura con dos redes inalámbricas a la vez. Pero si alguien falsea la MAC y ésta se repite para dos redes supongo que sí puede confundirse aireplay.


NOTA IMPORTANTE : Puede haber algún fallo. No dudéis a la hora de avisar.

¿Así?

Salu2

Ay, cuoño! creía que me decías la b. Hay que dormir más  Además es bueno para las arrugas.
Gracias.

Hola a todos y un saludo,este es mi primer mensaje en el foro,he hecho el ataque de chophop y todo fue segun el manual hasta que hize este paso:

./arpforge replay_dec-0220-142036.xor 1 00:03:09:GG:GG:GG 00:03:09:GG:GG:GG 192.168.1.100 192.168.1.1.520 nuestra_nueva_peticion_ARP.cap

aqui hay dos cosas que no entiendo cuando pones el BSSID se debe repetir dos veces o no,y otra donde pones nuestra_nueva_peticion_ARP.cap que es lo que debo de poner,es algun fichero que tenga yo ya guardado o es un que crea el,cuando le envio este comando me dice fichero no encontrado,os digo que llevo una semana intentando sacar la wep de un colega pero como casi nunca esta conectado no le puedo injectar puesto que no tengo station,cuando se conecta si me sale station y le injecto pero no me pilla arp,otra duda es que mi conesion no hay manera de me pille ni un data ni se asocie,tengo desactivado el dhc,y filtradas las mac,no se si sera por eso,espero vuestra ayuda,gracias y un saludo.

Buenas-

En vez de volver a capturar IVs con el:


¿No podrías utilizar los 3 IVs que ya tienes en captura_chophop.cap para hacer directemente:


A lo mejor me estoy confundiendo, pero a mí me parece que si ya tienes IVs no hace falta olfatear otra vez, ya que a veces estos paquetes no son nada fáciles de encontrar (si no hay nadie conectado por ejemplo).

Saludos

Gracias Uxio.  Me alegra verte por aquí de nuevo.



No tengo posibilidad de comprobarlo. Sé que así funciona, tened en cuenta que yo no sabía qué tipo de paquetes eran y decidí probar así. No había clientes conectados (es el router con dirección 192.168.1.1 quien envía estos paquetes a 192.168.1.255).

Salu2

Pero a mi me parece que los arp que genera tiene la clave que te acabas de inventar. Eso me pasó a mi una vez que me asocié con una clave falsa y reinyecté sobre ese  cliente y después el pass que descubrí pues era el que yo habia puesto.

Nos vemos.

Pero los arp tienen datos d la clave??donde va la clave es en los Ivs no??los arp simplemente son peticiones de conexion o stoy ekivocado...no se...
Un saludo