Time-Sync con NTP en OS X & Delorean Attack a HSTS

El investigador español José Selvi presentó en Defcon su trabajo sobre los problemas que pueden provocar la sincronización de tiempos en diferentes sistemas operativos. Selvi se aprovechaba de este hecho para atacar y poder manipular las respuestas de los servidores NTP con todo lo que ello podía conllevar. Además, ha publicado en su blog una cadena de artículos dónde va explicando paso a paso los diferentes conceptos y cómo llevó a cabo la investigación.

Cuando hace el estudio sobre la sincronización de tiempos se detalla que los sistemas OS X anteriores a Mavericks utilizan una sincronización de reloj muy sencilla, sin ningún tipo de restricción de seguridad por lo que utilizando el ataque Delorean, del propio Selvi, se podría manipular los tiempos realizando un MiTM. Estos sistemas utilizan un servicio denominado NTPd que se ejecuta y sincroniza el tiempo cada 9 minutos.

Apple cambió la forma de funcionar en sus sistemas más nuevos. El servicio NTPd ya no cambia la hora por sí mismo. La diferencia de tiempo se almacena en /var/db/ntp.drift y otro servicio denominado pacemaker comprueba el valor y cambia el reloj si es necesario. Pacemaker no implementa ninguna función de seguridad, por lo que podría ser atacado utilizando Delorean. En el siguiente video se puede ver el ataque Delorean en un sistema OS X.

Figura 1: Delorean Attack en OS X

Cuando un usuario abre el menú Date & Time Preferences, OS X sincroniza de forma automática la hora, es decir, de forma transparente para el usuario. En este instante también se podría utilizar el ataque Delorean. En el siguiente video se deja la charla que presentó Selvi en Black Hat Europe 2014 en la que realiza bypass de HSTS basándose en el estudio del protocolo NTP.

Figura 2: Confrencia de ataques a HSTS de José Selvi en BlackHat Europe 2014

En el blog de nuestro compañero Chema Alonso tienes un artículo resumen que explica y describe de forma resumida el ataque descrito por José Selvi y cómo puede aplicarse también en ataques con los protocolos IPv6.

Bypass a OpenSSL Certificate Pinning en aplicaciones iOS

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.

Figura 1: Contramedidas en la suplantación de autoridades de certificación. Certificate pinning

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.

Figura 2: Bypass OpenSSL Certificate Pinning on iOS

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 lugar 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.

La aplicación de Gmail en iOS no hace Certificate Pinning

La app de Gmail para dispositivos iOS tiene una importante vulnerabilidad que pone en riesgo la comunicación, ya Google no verifica adecuadamente los certificados digitales con Certificate Pinning en ella, lo que permite que los usuarios puedan ser víctima de ataques de interceptación de comunicaciones, más conocidos como Man in the Middle (MitM). Avi Basán de la empresa Lacoon Mobile Security, ha comentado que la aplicación de Gmail para iOS no lleva a cabo como debiera el denominado Certificate Pinning al establecer una conexión segura entre la aplicación móvil y los servicios web alojados en el back end.

Un potencial atacante puede visualizar en texto plano los datos que la aplicación maneja, por ejemplo los correos electrónicos de la víctima y robar las credenciales de usuario de su cuenta, mediante el uso de un MitM. El proceso de Certificate Pinning está enfocado en evitar que un usuario pueda ser víctima de un ataque de suplantación de identidad del certificado SSL. ¿Cómo se logra esto? Las apps sólo permite la conexión SSL a sitios firmados con certificados almacenados dentro de la misma aplicación, rechazando por lo tanto cualquier otra conexión. Si un usuario malicioso intenta colar un certificado emitido de manera fraudulenta se rechazará la conexión, siempre que se utilice este proceso.

Figura 1: Explicación del ataque a Gmail para iOS

La empresa Lacoon informó de la vulnerabilidad a Google a finales de Febrero, según informa la propia empresa. Google validó el problema y comunicó que lo habían solucionado. Este hecho hizo de nuevo comprobar a Lacoon la vulnerabilidad y observar que sigue siendo explotable en la aplicación de Gmail de iOS. Finalmente para que el ataque tenga éxito, se debe conseguir modificar el perfil de configuración del dispositivo iOS. ¿Cómo podemos hacer esto? Realmente la ingeniería social puede ser un punto a favor aquí, conseguir engañar a un usuario para que descargue dicha configuración. En el libro de hacking de dispositivos iOS se puede encontrar diversas técnicas para realizar este tipo de acciones.