Interceptar el tráfico de aplicaciones de Android con Burp

5

Estoy tratando de entender qué hacen las aplicaciones Burp y Android cuando el tráfico es https. Yo no instalé la CA de Burp en el teléfono.

  1. Algunas aplicaciones se niegan completamente a trabajar. Muestran un mensaje de error o piensan que el teléfono no está en línea. ¿Esto se debe a la asignación de SSL?

  2. Algunas aplicaciones funcionan normalmente pero Burp no captura ningún paquete. ¿Cómo está pasando esto? Sin eructos CA ¿cómo pueden comunicarse el teléfono y el servidor? ¿Burp solo está retransmitiendo el tráfico?

  3. Algunas aplicaciones funcionan normalmente, pero Burp solo intercepta paquetes para algunas operaciones. Las operaciones interceptadas probablemente utilizan administradores de confianza vacíos o algo así, pero ¿cómo se está comunicando el resto del código con el servidor?

pregunta mk_ 10.03.2017 - 09:31
fuente

2 respuestas

4

Lo primero que debe recordar es que Burp es un proxy HTTP (S). No hace nada con los datos que no sean HTTP (S) (OK, excepto websockets). Las aplicaciones de Android, por otro lado, pueden usar cualquier protocolo que quieran. Muchos usan HTTP (S), solo porque se ajusta al tipo de datos que están enviando, pero en realidad no es necesario.

Cuando una aplicación no usa HTTP (S), ese tráfico no aparecerá en Burp. El ejemplo más obvio de esto es el tráfico de DNS: no verás ninguna solicitud de búsqueda de DNS, incluso si estás utilizando un navegador a través de Burp.

Entonces:

  1. Aplicaciones que se niegan completamente a trabajar. Podrían estar usando el anclaje de certificados, pero hay dos opciones aquí. En primer lugar, buscan un certificado válido para que el sitio de destino se instale en el dispositivo. En este caso, la instalación del certificado de CA de Burp los haría funcionar de nuevo. En segundo lugar, utilizan algún tipo de anclaje personalizado, que requiere que el servidor proporcione un certificado específico o un certificado firmado por una entrada específica en la cadena de confianza. Estos no serán engañados por el certificado de CA de Burp.
  2. Aplicaciones que funcionan sin que se capturen paquetes. Probablemente no estén utilizando HTTP (S). Esto podría ser cosas como clientes SSH, servicios de mensajería como Whatsapp o juegos, donde la pérdida de un paquete es menos importante que la mayoría de los paquetes que llegan rápido, lo que se adaptaría mejor a una conexión de red basada en UDP que a una basada en TCP como HTTP. También pueden estar ignorando cualquier configuración de proxy que esté instalada, especialmente si solo está interceptando con una aplicación de proxy HTTP. Para ver estos datos, necesitará una herramienta como Wireshark, que puede manejar otros tipos de datos, y una tarjeta wifi que admita el modo de monitor.
  3. Aplicaciones que solo muestran algo de tráfico. Si el tráfico que está viendo es paquetes de estadísticas o anuncios, probablemente se clasifiquen en la clase 2 anterior: la mayoría de los sistemas de estadísticas parecen usar HTTP (S) porque es relativamente fácil de implementar en cualquier cosa, y generalmente tiene que tener algún tipo de HTTP Conexión abierta para descargar anuncios de todos modos.
  4. Aplicaciones que en realidad no se conectan. Hay algunas aplicaciones que parecen estar conectándose a Internet, pero en realidad no lo hacen, o solo lo hacen de manera irregular. Estas pueden incluir aplicaciones de horarios, algunos juegos (donde los puntajes altos se actualizan diariamente, por ejemplo) o cualquier cosa donde sea posible almacenar datos localmente en su mayor parte (las aplicaciones de mapas pueden almacenar el área "habitual" localmente, y hacer llamadas) críticas de lugares de interés o lugares más lejanos). En este caso, es posible que no los haya visto intentar conectarse mientras estaba mirando.

Si es posible, sugiero mirar el tráfico con Wireshark y ver qué protocolos se están utilizando, luego profundizar en los interesantes utilizando el software apropiado, teniendo en cuenta que algunos son intencionalmente difíciles de inspeccionar: paquetes cifrados de Whatsapp debe ser ilegible, de lo contrario tienen algo muy mal!

    
respondido por el Matthew 10.04.2017 - 15:54
fuente
2

Me he encontrado con un problema similar al hacer una prueba de una aplicación de iPhone. La aplicación no usaba las bibliotecas nativas y no era compatible con el proxy http. Para "arreglar" esto, reenvié todo el tráfico de manera transparente al proxy Burp. Consulte ¿Cómo captura TODO el tráfico de una aplicación de Android? para la descripción de esta configuración.

Algunas aplicaciones utilizan la fijación de certificados. Algunas aplicaciones fijarán el primer certificado que ve, otras aplicaciones lo tienen codificado en la aplicación. En el primer caso, solo debe asegurarse de que el tráfico pasará por su proxy cuando lo ejecute por primera vez.

Creo que verá una advertencia en la pestaña de alertas Burps si el cliente se desconecta prematuramente (rechaza el certificado).

En este último, es un poco más difícil ya que tendrá que modificar el binario en sí.

No he intentado subvertir el anclaje del certificado de una aplicación de Android, pero this links parece un buen enfoque.

    
respondido por el Dog eat cat world 10.03.2017 - 17:30
fuente

Lea otras preguntas en las etiquetas