bypass de interceptación de conjunto de Burp

3

Estoy intentando interceptar el tráfico de la capa de aplicación utilizando ataques de nivel de red. En particular, me he topado con este interesante artículo aquí.

Link

Brevemente, usa el envenenamiento ARP para hacer el control de la máquina del atacante y usa iptables para reenviar el tráfico http y SSL para hacer eructos en la máquina del atacante.

Mi configuración:

  1. OnePlus X con punto de acceso como enrutador
  2. Windows 10 32 bit PC como víctima (varios navegadores ejecutándose)
  3. Kali Linux 2018 para PC de 64 bits como atacante (Wireshark, burp suite y Ejecución de la parodia ARP)

Todo funciona bien, el envenenamiento ARP hace su trabajo y puedo ver los paquetes en Wireshark. Todas las solicitudes de DNS realizadas y todos los datos HTTP sin cifrar son visibles en Wireshark. Además, eructar está bien configurado e intercepta el tráfico, incluso el tráfico HTTPS. Por ejemplo, probé enlace y pude verlo en burp.

Luego probé bing.com y también pude verlo en eructo. Pero cuando intenté conectarme a Facebook o Google desde la máquina víctima, no veo ningún tráfico en eructos. No hay una sola señal de tráfico a Facebook o Google en burp. Ni siquiera mensajes de error. Sin embargo, puedo ver las solicitudes de DNS hechas a Facebook y Google en Wireshark. Y luego sigue un intercambio de flujo de TCP, que obviamente debe ser la respuesta de solicitud de esos dos sitios. Esto significa que el tráfico pasa a través de mi máquina Kali Linux. Entonces, ¿por qué no puedo interceptar el tráfico en eructos?

Probé este problema en Chrome 66 y en el navegador Opera (ambos actualizados) en mi máquina víctima. Ambos tienen el mismo comportamiento.

Podía ver errores específicos de hsts antes de importar la CA de eructo en la raíz de confianza de mis víctimas. Después de la importación, cuando puedo interceptar el tráfico a bing.com, ¿por qué no puedo interceptar el tráfico a Facebook o Google? ¿Qué magia está en el trabajo que me impide verla en eructos?

Cualquier ventaja sería apreciada. Gracias.

    
pregunta user148898 11.05.2018 - 14:21
fuente

1 respuesta

1

No importa. Esos sitios web utilizaban IPv6 sobre IPv4 y, por lo tanto, debido al cifrado de IPv6 no podía ver el tráfico. Resulta que Windows tiene una preferencia de IPv6 sobre IPv4 cuando los adaptadores de red tienen algunos tipos de direcciones, típicas de las asignadas por puntos de acceso móviles. (¿Quizás por seguridad?)

Pude ver en Wireshark que las solicitudes de DNS para Facebook y Google recibían direcciones IPv4 y IPv6. Pero los de Bing y Barracuda no lo eran. Y debido a la preferencia de IPv6 sobre IPv4, se usó IPv6. Forzo el soporte de IPv6 deshabilitado en Windows sobre el adaptador en cuestión y como era de esperar, las cosas volvieron a la normalidad.

Y resulta que los intercambios de TCP que mencioné son probablemente algo más y no las respuestas de solicitud de Google o Facebook. Me di cuenta de esto simplemente ejecutando Wireshark en mi máquina con Windows, y luego, sorprendida por esto, investigué un poco y pude saber en algún lugar del soporte de Microsoft sobre la preferencia de IPv6 sobre IPv4.

Espero que esto ayude a algún pentester en alguna parte.

    
respondido por el user148898 11.05.2018 - 19:34
fuente

Lea otras preguntas en las etiquetas