¿Por qué no necesitamos un apretón de manos WPA en un ataque de MiP que falsifica ARP?

2

En la red inalámbrica que se ejecuta bajo el protocolo WPA2, la comunicación entre un cliente y el AP se cifra mediante una clave de sesión (llamándola de esa manera, pero si hay un término más exacto, me alegraría para editarlo) que se intercambia entre ellos durante el Apretón de manos de 4 vías (que verifica si dicho cliente está en posesión de la PSK).

Esta clave de sesión es única para cada cliente conectado al AP. Supongo que esa afirmación desde que un atacante está olfateando una red, necesita tener el apretón de manos de cada cliente si desea descifrar cada comunicación de los clientes con el AP. Entonces, incluso si está conectado a dicha red, no podrá descifrar la comunicación de otra persona con el AP, ya que su clave de sesión es diferente (a menos que capte el 4-4). Manera apretón de manos del otro cliente).

Durante un ataque de MiTM utilizando falsificación ARP, ya está conectado al AP, pero no tiene las claves de sesión de los otros clientes. Una vez que envenenen su caché ARP, comenzarán a enviar los paquetes destinados a ser enviados al AP a su máquina. La pregunta es, ya que todavía creen que están hablando con el AP, ¿no cifrarán los paquetes utilizando la clave de sesión que intercambiaron con el AP durante la conexión?

Lo pregunto porque al experimentar (en mi propia red) no necesitaba el protocolo de enlace de 4 vías para ver el tráfico descifrado en la máquina atacante, que creía que necesitaría. Me preguntaba si tal vez la clave de sesión esté asociada a la dirección MAC, por lo que una vez que la víctima comience a hablar con su MAC, aunque crea que usted es la puerta de enlace, no cifrará el tráfico con la clave de sesión que estaba usando antes.

    
pregunta murphsghost 22.08.2016 - 01:13
fuente

3 respuestas

0

Esta no es una respuesta definitiva, pero creo que podría estar apuntando en la dirección correcta.

Encontré un archivo PCAP de uno de mis experimentos, que no puedo compartir debido al tamaño del archivo (más de 40.000 paquetes) y la presencia de posibles datos confidenciales. A lo largo de las cosas que noté, lo siguiente parece realmente pertinente a la discusión:

A pesar de que la captura comienza desde antes de que me conecte al punto de acceso hasta el final del ataque de suplantación de ARP, el único 4WHS presente fue el mío. La víctima no repitió el 4WHS durante todo el ataque. Sin embargo, el tráfico estaba completamente sin cifrar.

La siguiente ilustración representa el escenario de ataque (ignorando el hecho de que el AP es un extensor de alcance WiFi). Las líneas negras son el flujo de tráfico normal y las líneas rojas son el resultado del ataque MiTM:

UnavezqueelHostA(atacante)seconectaalAP,recibeunaclavetransitoriaporpares(PKT1).LomismosucedecuandoseconectaHostB(víctima)(PTK2,queesunaclavediferente).EstasclavesseutilizanparacifrareltráficoentreHostAyAPyHostByAP.CreoqueelPTKestáasociadoconladirecciónMAC,porloqueHostAsabequenecesitausarPTK1paracifrarlosdatosconelMACCC:CC:CC:CC:CC:CCcomodestinoyelAPsabequenecesitausarPTK1paracifrarlosdatosconMACAA:AA:AA:AA:AA:AAcomodestino.LomismoseaplicaalacomunicaciónHostB-AP(usandoPTK2).

UnavezquelatablaARPseenvenena,eltráficodeHostBa"AP" no va al MAC CC: CC: CC: CC: CC: CC , por lo que no se usa el PTK2 para cifrarlo. Lo mismo sucede con el tráfico proveniente del AP real a la máquina de los atacantes: como el MAC no es BB: BB: BB: BB: BB: BB , el AP no usa el PTK2 para cifrar los mensajes.

Este hilo del foro de retroceso ( ARP-Poisoning MIT en WPA2 ) también parece No hay necesidad de tener la información WPA2 4WHS para interceptar el tráfico descifrado en tal ataque.

Planeo seguir leyendo todo el RFC WPA2 para ver si encuentro información concreta sobre esto, pero hasta ahora esa es mi teoría sobre lo que está sucediendo.

Estoy eligiendo la respuesta de @dotproi como aceptada, ya que él fue un poco más lejos tratando de averiguar qué estaba pasando.

Si alguien tiene una fuente que puede confirmar mi teoría (o confirmar que es incorrecta), ¡compártala!

    
respondido por el murphsghost 23.08.2016 - 21:17
fuente
4

En primer lugar, para realizar el envenenamiento ARP, debe estar conectado a la red inalámbrica en la que se van a envenenar las respuestas. Puede que ya lo sepas, pero tu pregunta no indica que sabes que eso es un requisito, así que quería asegurarme de que estaba claro. En cuanto a tu respuesta:

En pocas palabras, el envenenamiento ARP funciona porque ARP funciona. Lo único que cambia es que el valor de las respuestas enviadas por la máquina atacante son falsos. Las respuestas de ARP son de confianza implícita y, como caducan, deben actualizarse periódicamente. Los atacantes aprovechan esta confianza implícita para enviar respuestas falsas. Si los detalles del 4WHS fueran necesarios para ARP, nadie (real o atacante) podría comunicar las respuestas de ARP.

    
respondido por el HashHazard 22.08.2016 - 06:19
fuente
3

Por medio del envenenamiento ARP, puede enrutar paquetes a través de su máquina y ubicarse en el medio. Sin embargo, necesita capturar un 4whs para poder descifrar el PSK y descifrar dicho tráfico. Tiene razón al afirmar que el cifrado se produce en una parte inferior de la capa. Como resultado, sin un 4whs solo podrá ver el tráfico cifrado entre el cliente víctima y el AP.

En tu escenario hay dos posibilidades.

Espere , asegurándose de inyectar periódicamente los paquetes ARP falsificados en la red para evitar posibles tiempos de espera de caché ARP con la esperanza de capturar otro apretón de manos cuando la víctima se vuelva a conectar.

Forzar Deautenticación

Enviar desasociar paquetes al cliente víctima para forzar otro saludo WPA que potencialmente puedas capturar.

Echa un vistazo a esta entrada en los documentos de aircrack.

aireplay-ng -0 [# of deauths] -a [AP MAC] -c [Client MAC] [interface]

This publicación anterior es relevante para esta discusión también.

EDIT

Después de volver a escribir la pregunta, tu situación es más clara para mí.

Brute forzar una sesión WPA no es cómodo ni trivial. Sin embargo, hay herramientas que tienen módulos para automatizar el proceso de craqueo (¿posiblemente algunos detrás de escena?). Además del esquema de autenticación mencionado anteriormente, no conozco ningún otro componente vulnerable de WPA2 que pueda haber explotado "de pasada".

Con la información disponible, la explicación más probable es una supervisión de su parte. Es decir, de hecho, realizó el ataque y perdió el recuerdo, o posiblemente confundió la sesión en cuestión con otra.

Si tiene la evidencia para revisar la sesión y / o replicar, por favor contáctenos.

Espero que esto ayude.

    
respondido por el dotproi 22.08.2016 - 08:46
fuente

Lea otras preguntas en las etiquetas