Usar
Certificate Pinning es una de las medidas de seguridad más empleadas para evitar los ataques de man in the middle con suplantación de certificados, tal y como hemos podido ver en el artículo del
blog de Eleven Paths titulado "
Certificate Pinning. El qué, el cómo y el porqué. Para tenerlo disponible existen diversas formas de implementarlo. Se puede utilizar
HSTS, que es el camino optado por
Google Chrome - a pesar de generar el
problema de privacidad con las Super Cookies -, el sistema implementado de
Certificate Pining por Mozilla Firevox, o la que utiliza
EMET que es el camino utilizado en
Microsoft Windows y para el que desde
Eleven Paths publicamos la herramienta
EMET Rules que ayuda a gestionar el Certificate Pinning en EMET.
Hoy queremos hablar de un artículo publicado por
Matasano donde se explica en detalle
Cómo bypassear OpenSSL certificate pinning en aplicaciones iOS.
Certificate Pinning: Un resumen
A modo de resumen, comentar rápidamente que cuando una aplicación móvil se comunica con una
API o un servicio en la web debe realizar dicha comunicación a través de
TLS / SSL. El objetivo es verificar la identidad del servidor y prevenir los temidos ataques
Man in The Middle. Los navegadores y sistemas operativos móviles vienen preconfigurados con una lista de entidades emisoras de certificados de confianza. Desde cualquiera de las
CA de la lista se puede emitir un certificado para cualquier nombre de
host o servidor. Las aplicaciones conscientes de la seguridad deben
pinnear el certificado esperado en la aplicación, es decir, no aceptarán ningún certificado salvo el emitido por la
CA conocida que utiliza el desarrollador de la aplicación. En el siguiente documento publicado en el
Canal Slide en SlideShare de Eleven Paths se explica en detalle.
Cuando pensamos en un test de intrusión, disponer de
Certificate Pinning puede ocasionar problemas para interceptar la comunicación de una aplicación en un proceso de auditoría de seguridad. Generalmente, sin
pinning, la intercepción implica agregar el certificado
TLS de un
proxy, por ejemplo
Burp o
Zaproxy, al almacén de certificados del sistema operativo. Sin embargo, cuando la aplicación utiliza
certificate pinning, el almacén es ignorado.
Evitar el Certificate Pinning para auditar una app en iOS
En
iOS se dispone de la aplicación
iOS SSL Kill Switch, la cual se puede utilizar para
bypassear el
pinning y forzar a que la aplicación acepte cualquier certificado presentado por un servidor o
proxy. La aplicación utiliza
Cydia Substrate, el cual
hookea las funciones que
iOS utiliza para la validación de certificados y las modifica para aceptar cualquier certificado. Este hecho es más complejo cuando se utiliza la librería
OpenSSL, ya que no está afectada por este tipo de
hooking. Hay más de una forma de
bypassear OpenSSL based certificate pinning, lo cual puede estudiarse en un
whitepaper escrito por Daniel Mayer, utilizando
binary patching and in-memory hooking.
En él
se detalla un escenario en el cual se crea un
mock-up de una aplicación
iOS que utiliza
OpenSSL y realiza
pinning. La aplicación realiza una conexión a
https://www.example.org y realiza una petición
GET a la raíz del sitio. Existen dos tipos de ejecutables en esta prueba,
ARMv7 y
ARMv8, y accesibles en el
Github dónde se encuentra la
app. El dispositivo debe tener realizado el
jailbreak para poder realizar este proceso, por supuesto.
En primer luga
r redirigen el tráfico de la
app al
Burp. Una de las maneras sencilla que exponen es modificar el fichero
/etc/hosts introduciendo la línea
127.0.0.1 www.example.org, para que resuelva a un servidor que se encuentra en local. Una vez realizado esto, se puede realizar un
SSH forwarding para reenviar tráfico desde el puerto
443 del dispositivo al puerto
8080 sobre nuestra máquina dónde esta
Burp a la escucha en modo trasparente.
 |
| Figura 3: Port Forwarding |
La aplicación intentará conectarse al proxy pero la conexión fallará debido al
certificate pinning. En el proxy se puede leer el mensaje
"The client failed to negotiate an SSL connection to www.example.org:443", tal y como se puede ver en la imagen.
 |
| Figura 4: Fallo por Certificate Pinning |
Analizar el
pinning es una de las primeras cosas que hay que hacer. En este caso la
app utiliza como
pinning una lista restringidas de
CAs. La aplicación genera dinámicamente certificados con
OpenSSL y son almacenados en memoria. El listado de
CAs son
hardcodeadas en el código fuente de la aplicación, en formato
PEM.
En general, esto es bastante común para almacenar
CAs en el sistema de archivos y sería una acción natural hacerlo igual para
pinear certificados en aplicaciones móviles. Una desventaja de este enfoque es que los certificados pueden ser fácilmente cambiados en un dispositivo con
Jailbreak. Sin embargo, los certificado que viven en el binario son más dificiles de cambiar, ya que se tiene que modificar el binario para hacerlo.
 |
| Figura 5: Certificados hard-codeados en formato PEM |
Dada esta configuración se puede intercambiar el certificado en el binario o deshabilitar la validación del certificado de otra manera. El intercambio de certificados es un reto ya que los diferentes certificados tienen diferentes longitudes y el espacio en el binario dónde se encuentran los certificados originales pueden no ser suficientes. Los grandes cambios en los binarios pueden ser poropensos a errores. La validación de certificados utiliza
SSL_CTX_set_verify, por lo que se tiene que convertir su valor en
SSL_VERIFY_NONE para deshabilitar la validación, con el
pinning se encuentra en
SSL_VERIFY_PEER. Hacer este cambio hace que la firma de la aplicación se rompa, por lo que se debe utilizar un dispositivo con
Jailbreak, para no verificar las firmas.
Por último, se puede ver cómo decompilar la aplicación con herramientas como
dumpdecrypted. Además se contempla como hacer el proceso para binarios compilados en
ARMv7 y
ARMv8.
 |
| Figura 6: Certificate Pinning bypasseado |
Certificate Pinning es una técnica útil para proteger contra ataques de
MiTM, o para asegurar que los
proxies corporativos que interceptar tráfico
TLS no pueden acceder a dicho tráfico de las aplicaciones. A través de
iOS SSL Kill Switch,
manual crypt hooking o
binary patching como se describe en este trabajo, se podría hacer una auditoría de una
app que tenga esta medida de seguridad activada.
En anteriores ocasiones ya os hemos hablado de los certificados de empresa de Apple y de cómo estos son fácilmente utilizados con fines poco legítimos. Esta semana se ha sabido que esta situación no ha cambiado mucho, de hecho se ha descubierto que recientemente han sido utilizados para desarrollar una app que contiene un spyware capaz de recopilar gran cantidad de información. Hace apenas unos meses, en febrero, se descubrió que algunos desarrolladores abusaban del programa para distribuir aplicaciones con contenido pornográfico y de apuestas o para lanzar versiones hack de algunas aplicaciones con las que se podía evitar pagar suscripciones de música en streaming, eliminar anuncios o hacer un bypass en compras del App Store.
