Posted in

Pentesting de aplicaciones iOS (Parte 3) Interceptar el tráfico con Burp Suite y Bypass de SSL Pinning

by Lior•

En esta serie de entradas, vamos a ver como realizar pruebas de pentesting en aplicaciones para iOS. En este tercer artículo vamos a ver como interceptar las tramas que genera una aplicación utilizando Burp Suite. Además, vamos a ver como evadir el control de SSL Pinning en caso exista dentro de la aplicación.

Advertencia: La información y las técnicas compartidas en este post son sólo con fines educativos o para realizar pruebas debidamente autorizadas. Atacar aplicaciones sin consentimiento, puede ser considerado ilegal. Utilice este conocimiento bajo su propio riesgo.

Antes de iniciar, te sugerimos leer las dos primeras parte de esta serie, las cuales podrás encontrar en los siguientes enlaces:

Bien, comencemos:

Para poder interceptar las tramas que genera una aplicación contra sus servicios back-end, necesitamos colocarnos en medio, utilizando un software que nos sirva como proxy intermedio.

Un proxy, dentro de este contexto, es un intermediario entre un cliente (dispositivo iOS) y servidor que responde a sus peticiones. Su principal función es interceptar, modificar y redireccionar las solicitudes y respuestas entre ambos dispositivos. Esto nos va a permitir encontrar vulnerabilidades en las funcionalidades de nuestra aplicación objetivo.

Es importante recordar que, generalmente, cuando se trata de aplicaciones, el tipo de protocolo más usado para comunicarse con los servicios backend es HTTP/HTTPs. En el contexto del pentesting de aplicaciones móviles, es muy importante conocer la diferencia básica entre ambos protocolos. HTTP no utiliza certificados de cifrado en tránsito, mientras que HTTPs sí.

Aunque esto último parece bastante obvio. Tenemos que saber que, por defecto, no podemos interceptar el trafico HTTPs con un software proxy intermedio, ya que como podrás haberte dado cuenta, si el tráfico va cifrado, necesitamos que la aplicación use un certificado que está bajo nuestro control para poder descifrar la trama, y como no tenemos el certificado privado real (el del servidor), tenemos que generar uno, y «engañar» a la aplicación para que confíe en el. Luego nuestro proxy tendrá que devolver la trama al servidor, estableciendo conexiones HTTPs con el servidor original.

Interceptando el tráfico con Burp Suite

Primero, veremos como interceptar el tráfico no cifrado, a través del protocolo HTTP:

  • Lo primero es identificar la dirección IP privada de nuestro equipo de escritorio:
  • Ahora, configuraremos nuestro dispositivo móvil para que utilice un proxy loca, apuntando a nuestra dirección IP de escritorio:
  • Por defecto, se encuentra en estado «Desactivado». Cambiaremos a modo «Manual» e ingresaremos la IP y un puerto definido por nosotros (en este caso 8080):
  • Verificamos que todo está correctamente configurado en el dispositivo:
  • Desde nuestro equipo, ejecutaremos Burp Suite, el cual es el software que nos servirá como proxy intermedio. Recuerda, que existen otras opciones, como OWASP Zap Proxy, por lo que tu puedes elegir aquella con la que te sientas más comodo. Vamos a ejecutar Burp Suite:
  • Una vez levantada la aplicación, vamos a configurar la opción de Proxy. Dentro de «Proxy Settings», vamos a editar el listener, colocando la dirección IP privada del equipo, así como el puerto que habíamos seleccionado:
  • Ahora que tenemos todo listo, desde nuestro dispositivo móvil, vamos a abrir la aplicación DVIA y entraremos al módulo «Network Layer Security» y enviaremos algunos datos a través de HTTP:
  • Se valida que, utilizando la herramienta Burp Suite, se logró interceptar el tráfico de la aplicación iOS, confirmando que se está utilizando el protocolo HTTP.

Es poco usual que encontremos aplicaciones que utilicen tráfico HTTP, sobre todo si estamos lidiando con alguna aplicación empresarial. Estas se conectarán a un backend a través de HTTPs. Veamos que pasa si enviamos la misma trama, pero esta vez haciendo click a la opción «Send over HTTPS»

  • Si el certificado de Burp Suite no está instalado como certificado de confianza, en la pestaña de eventos aparecerá una alerta indicando que no se pudo establecer una conexión segura con el servidor. El mensaje de error será: “The client failed to negotiate a TLS connection to example.com:443: Remote host terminated the handshake”, lo que significa que el servidor rechazó la conexión porque no se pudo completar el proceso de seguridad (TLS handshake).
  • Otra forma de comprobarlo es ingresando a Safari o cualquier navegador, y al colocar una dirección con HTTPs, nos saldrá un mensaje de alerta, indicando que la conexión no es privada.:
  • ¿Por qué ocurre esto?: Burp suite utiliza internamente un certificado TLS por defecto que no está firmado por una Autoridad Certificadora, por lo que el navegador detecta que no es de confianza. Esto mismo ocurre al momento de intentar interceptar la trama desde la aplicación móvil.
  • Para corregir esto, añadiremos a la lista de certificados de confianza del equipo móvil, al certificado de Burp Suite. Para ello, seguimos los siguientes pasos:

Instalando el certificado de confianza en el equipo móvil

  • Como ya tenemos configurado nuestro proxy, vamos a ir al navegador y colocaremos la URL http://burp
  • Descargamos el certificado, haciendo click en CA Certificate
  • Después de descargar el certificado, es necesario instalarlo. Para ello, dirígete a Configuración > General > Admón de dispositivos y VPN, donde aparecerá el perfil descargado “PortSwigger CA”, correspondiente al certificado de Burp Suite.
  • Dentro del perfil descargado, presiona el botón “Instalar”, luego ingresa la clave del dispositivo cuando se solicite y vuelve a presionar “Instalar”. Una vez completado el proceso, se verificará que la instalación fue exitosa y el perfil de configuración aparecerá como “PortSwigger CA”.
  • Finalmente, se debe configurar el certificado de confianza de Burp Suite en el dispositivo iOS. Para ello, dirígete a Configuración > General > Información > Ajustes de confianza de certificados y activa la opción “PortSwigger CA”. Esto permitirá que el sistema reconozca el certificado como confiable, habilitando la inspección del tráfico HTTPS. Al completar este proceso, la configuración quedará correctamente aplicada.
  • Para validar que la instalación y configuración del certificado de confianza de Burp Suite fue exitosa, se debe intentar interceptar el tráfico. Para ello, abre Safari en el dispositivo iOS y navega a google.com. Si Burp Suite captura la solicitud en el proxy, significa que la configuración se realizó correctamente y el tráfico está siendo interceptado con éxito.
  • En Burp Suite, veremos lo siguiente:
  • Ahora, desde la aplicación DVIA, vamos a repetir el envío de la trama a través de HTTPs
  • Verificamos en Burp Suite que ahora si podemos ver la trama:

Evadiendo el control de SSL Pinning

El protocolo SSL/TLS establece una comunicación segura entre cliente y servidor mediante un handshake que garantiza autenticación, confidencialidad e integridad. Sus principales características incluyen:

  1. Negociar la suite de cifrado (cipher suites) que se utilizará durante la transferencia de datos y intercambar números aleatorios (Client Random) que se usará más adelante en la generación de la clave maestra.
  2. Establecer y compartir un ID sesión entre el cliente y servidor.
  3. Autenticar el servidor ante el cliente, el servidor envía su certificado digital emitido por una Autoridad de Certificación (CA). El cliente verifica este certificado para asegurarse de que es válido y confiable para seguir con el proceso de handshake.
  4. Autenticar el cliente ante el servidor, donde el sistema que requieren identificación segura. Por esto, el cliente envía un certificado digital que el servidor verifica de manera similar a como el cliente validó el certificado del servidor.

Como ya explicamos antes, en SSL/TLS, los certificados son verificados para confirmar que están firmados por una autoridad de certificación (CA) confiable, sin embargo, un ataque MiTM con un certificado falsificado puede engañar al protocolo. Si el atacante consigue que el dispositivo confíe en un certificado arbitrario, el aplicativo lo considerará legítimo, permitiendo así la captura de las tramas entre el cliente y servidor.

SSL Pinning

La técnica de SSL Pinning o HTTP Public Key (HPKP) apareció en los últimos años como un control de seguridad para fortalecer la comunicación basada en HTTPs contra ataques MiTM. Las técnicas de SSL Pinning han sido mayormente utilizadas como complemento para reforzar la seguridad de las comunicaciones SSL/TLS para aplicaciones móviles.

El control de seguridad SSL Pinning se implementa para prevenir ataques de hombre en el medio (MITM) al restringir la validación de certificados SSL/TLS a un certificado confiable «fijado o pinneado». Esto impide que herramientas como Burp Suite el tráfico de la aplicación, dificultando el análisis de las solicitudes y respuestas en busca de vulnerabilidades.

¿Cómo funciona el SSL Pinning?

Podemos resumir el proceso en dos etapas. En la primera etapa, la aplicación del dispositivo móvil debe iniciar la comunicación con el servidor. El servidor responde para saber si está disponible el servicio o no. Si el servicio está disponible, el cliente solicita el certificado del servidor y el servidor responde con el contenido de la información de su certificado y llave pública.

En la segunda etapa se verificará el SSL Pinning. Cuando el cliente recibe la llave pública del servidor, la compara con la que esta almacenada dentro de la aplicación. En caso de que exista coincidencia, el cliente abre una negociación o envía paquetes firmados con esa clave pública. Cuando la llave pública no coincide entonces se corta la comunicación. Por lo tanto, no envía paquetes al servidor.

Ahora bien, ¿por qué no podemos interceptar el tráfico cuando hacemos uso de Burp Suite teniendo SSL Pinning implementado?: porque la llave pública que envía Burp como parte de la negociación (del par de llaves publica – privada que utiliza), no coincide con la que está pinneada en el dispositivo.

Evadiendo el SSL Pinning

Cuando el control de SSL Pinning no se encuentra bien implementado, es posible evadirlo a través de técnicas de instrumentación dinámica.

Si deseas ver como realizar un ataque de instrumentación dinámica, puedes ver nuestro artículo: https://labitacoradelhacker.com/pentesting-de-aplicaciones-ios-parte-2-evadir-el-control-anti-jailbreak/, en donde utilizamos ese tipo de ataque para evadir el control anti-jailbreak.

Iniciemos el proceso:

  • Lo primero que hay que verificar, es que el certificado de Burp Suite ya esté instalado como certificado de confianza en el dispositivo:
  • Ahora, desde el aplicativo DVIA-2, vamos a lanzar la misma trama del ejercicio anterior, pero esta vez seleccionaremos «Send Using Certificate Pinning»
  • Como vemos, nos arroja un error. Ahora veamos la pantalla de logs desde Burp Suite:
  • Burp Suite intentó establecer una conexión segura TLS con el servidor “example.com”, sin embargo, la negociación fue interrumpida antes de completarse, lo que sugiere que la aplicación implementa un mecanismo de SSL Pinning, bloqueando la conexión debido a la validación del certificado por parte del aplicativo.
  • Existen varias formas de evadir el SSL Pinning, por lo que exploraremos algunas:

Evasión de SSL Pinning vía Tweaks:

  • Ahora que hemos confirmado la implementación de SSL Pinning en la aplicación, procederemos a evadir este control utilizando el tweak “SSL Kill Switch 3”. Esta herramienta permite deshabilitar la validación de certificados SSL/TLS, facilitando la interceptación del tráfico en Burp Suite sin que la aplicación detecte un certificado no confiable
  • Un tweak, es un paquete de software diseñado para añadir nuevas funciones, cambiar la apariencia o modificar el comportamiento de un dispositivo iOS. Para instalar un tweak necesitamos que el dispositivo se encuentre jailbrekeado. En este caso, podemos instalar SSL Kill Switch 3, añadiendo el siguiente repositorio a Sileo: sileo://source/https://repo.misty.moe/apt.
  • Si tienes otros gestores de aplicación, puedes ubicar las fuentes aquí: https://repo.misty.moe/apt/
  • Una vez que hayamos agregado la fuente, descargamos e instalamos el tweak en el equipo. El Tweak debe estar activo:
  • Ahora repetiremos una vez la petición desde el aplicativo DVIA:
  • Ahora vemos que Burp Suite ya captura la trama sin problemas:

Evasión de SSL Pinning con Frida

  • No siempre el uso de Tweaks consigue evadir el control de SSL Pinning. Por ese motivo es mejor conocer como evadirlo de forma manual usando Frida.
  • Primero debemos reconocer el identificador de la aplicación
frida-ps -Uai
  • Al igual que cuando evadimos el control anti-root, el script busca métodos conocidos para la implementación de SSL Pinning, y modifica los valores de retorno en tiempo de ejecución, para que el dispositivo se salte las verificaciones de la llave pública «pinneada». Vamos a ejecutar el script con Frida:
  • Vemos que el Bypass ha sido satisfactorio, y podemos conseguir interceptar la trama:

Evasión del SSL Pinning con Objection

  • Como ya sabemos, Objection se soporta en Frida, por lo que reconoceremos primero el identificador de la aplicación:
  • Ahora iniciaremos Objection: 
objection -g [identificador] explore
  • Dentro de Objection, ejecutaremos el comando «ios sslpinning disable«
  • Ahora volvemos a lanzar la petición:
  • Y podemos ver como hemos logrado capturar la trama, evadiendo el control SSL Pinning

Es importante considerar que de las tres formas de evasión mostradas, la que tiene mayor grado de fiabilidad es la que evasión manual con Frida, ya que el script puede ser personalizado, dependiendo de las clases y métodos que use la aplicación para implementar el control, incluso aunque existiera algún tipo de ofuscación de código.

Eso ha sido todo en esta serie de artículos. Después de haber logrado capturar las tramas evadiendo los controles iniciales, ya podemos lanzar ataques sobre las peticiones, modificando las cabeceras o el cuerpo de las mismas, siguiendo alguna guía de referencia como OWASP o MITRE.

Esperamos que te sea de utilidad.