manipulación de tráfico SSL a través de ettercap MitM e iptables

2

Estoy tratando de entender la relación entre algunas herramientas y conceptos utilizados para MitM en una red wifi y cómo se puede interceptar y modificar la transacción https (a través de esta red wifi) entre una aplicación de Android y el servidor correspondiente. Soy nuevo en este dominio, así que por favor tengan paciencia conmigo.

Así que quiero CAPTURAR y MANIPULAR todo el tráfico HTTPS entre una aplicación de Android y el servidor con el que se está comunicando. El usuario que utiliza la aplicación está en una red WPA / WPA2 PSK. Ya he capturado el protocolo de enlace inicial de WPA y he podido forzar con éxito la fuerza bruta del PSK a través del protocolo de enlace y ahora formo parte de la misma red que el usuario que utiliza la aplicación de destino.

Ahora, para poder capturar el tráfico, necesito obtener una posición MitM. Hay muchas maneras de hacer esto. Hay una pareja que conozco, incluyendo Cain APR y ettercap.

Elijo usar ettercap para ARP envenenar a la víctima. Ahora, como el dispositivo móvil se comunica a través de SSL y quiero interceptar esta comunicación SSL, realizo los cambios necesarios en etter.conf y enciendo el reenvío de IP en mi sistema para hacer la suplantación del certificado de ettercap, donde ettercap realmente genera el servidor impostor y los certificados de CA en la mosca.

La técnica anterior aún presentaría a la víctima una advertencia de error de certificado y si el usuario acepta que el certificado falso se agrega como una CA raíz de confianza en el dispositivo de la víctima. Podría haber usado SSL Strip aquí, pero nuevamente, si el usuario se conecta al servidor directamente a través de https (sin una redirección), SSL Strip puede no ser la mejor solución.

Ahora, aunque puedo rastrear el tráfico SSL ahora, pero sería relativamente más difícil manipular este tráfico SSL utilizando ettercap. Entonces, en lugar de eso, trato de usar iptables para redirigir el tráfico a un número de puerto alternativo en un segundo puerto en el sistema local donde tengo otro software en ejecución que me permitiría manipular los datos en el tráfico redirigido.

Ahora digamos que el software que estoy ejecutando en este puerto es BURP Suite, que es algo que me gustaría usar para jugar con los datos.

Ahora, con lo que me estoy confundiendo es:

  

BURP tiene su propio certificado Portswigger. Sin embargo, utilizando ettercap ya he hecho una suplantación de certificado anteriormente. Así que ahora, cuando reenvío todo este tráfico (usando tablas IP y configurando BURP para usar Proxy transparente) a BURP, ¿necesitaré obtener el certificado de Portswigger en el dispositivo del cliente? Por favor explique si o no

  1. Como un atacante del mundo real, lo anterior sería probablemente uno de los métodos que podría usar para lanzar un ataque. ¿Es correcto el entendimiento anterior?

  2. Como probador de lápiz, otra forma de lograr esto que se me ocurre es si instalo un servidor SSH en el dispositivo de prueba y también instalo Shark (en el caso de Android) / alguna otra herramienta similar a volcado de TCP, y ¿Luego monitorear / analizar (usando Wireshark tal vez) todo el tráfico de forma remota a través de un cliente SSH en mi sistema local? ¿Esto me permitirá hacer el trabajo previsto?

  3. ¿Cuáles podrían ser otras formas de hacer esto?

pregunta qre0ct 16.04.2015 - 12:53
fuente

1 respuesta

1

La mejor solución es cuando ettercap no MiTM la conexión SSL, simplemente la reenvía a Burp, y Burp se puede configurar como un proxy MiTM transparente. En este caso, el cliente verá el certificado del servidor de Burp, que debe ser de confianza para el cliente. Como puede ver en lo siguiente, solo se configura 2 conexiones SSL.

           SSL1            SSL2 
Client <--Ettercap--> Burp <--> SSL Website

Aunque ettercap y Burp se pueden configurar como SSL MiTM, solo complica las cosas. En este caso, el cliente solo verá el certificado del servidor ettercap, por lo que no tiene que agregar el certificado de Burp a la tienda. En este caso, tendremos 3 conexiones SSL diferentes, pero no tiene ninguna ventaja en comparación con la anterior.

       SSL1          SSL2      SSL3
Client <--> Ettercap <--> Burp <--> SSL Website

Para responder a sus preguntas: Sí, como un atacante del mundo real, lo anterior sería probablemente uno de los métodos que podrías usar para lanzar un ataque.

SSH-ing en el dispositivo Android y usar Shark no será suficiente. No podrás manipular el tráfico. Solo podrá descifrar el tráfico si tiene las claves de servidor TLS / SSL (lo que usualmente no es el caso) y no se usa el secreto de envío perfecto.

    
respondido por el user2716262 17.08.2015 - 22:17
fuente

Lea otras preguntas en las etiquetas