Apple pone a Safari a luchar contra las SuperCookies

Apple se ha movido para bloquear un vector de ataque en el marco del WebKit, el cual se aprovechaba del navegador Safari y permitía abusar de HSTS para que actuase como una SuperCookie con el objetivo de hacer tracking de usuarios. El HSTS permite a un sitio web declarar a los navegadores que solo se puede acceder a un sitio a través de HTTPS. Si un usuario intenta acceder a la versión HTTP del sitio, no se llega a realizar la petición por parte del navegador, directamente se realiza la conexión de HTTPS. El problema viene porque un sitio podía utilizar la información de este proceso como una SuperCookie para el rastreo. 

La RFC 6797 lo describe como se indica a continuación: "Los UA, User-Agent, deben conservar datos persistentes sobre sitios web que indiquen la habilitación estricta de la política de seguridad para períodos de tiempo declarados por los sitios web. Además, los UA deben almacenar en caché la información de la política de seguridad estricta más reciente para permitir que los sitios web actualicen la información". El RFC reconoce el potencial para el seguimiento de HSTS, y las posibilidades de abuso se demostraron ya en el año 2015. 

Figura 1: User Agent en el RFC

El investigador Sam Greenhalgh estableció el concepto de PIN HSTS para cada sitio redireccionado HTTPS, es exclusivo para el usuario y el sitio, y es legible desde la configuración del navegador por cualquier sitio. Esos pines podrían recuperarse en el futuro y el usuario no tiene la oportunidad de borrarlos. Un atacante que busca rastrear los visitantes del sitio puede aprovechar la caché HSTS del usuario para almacenar un bit de información en el dispositivo de ese usuario. Por ejemplo, cargar este dominio con HTTPS, podría representar un 1, mientras que ninguna entrada representaría o sería representado por un 0. Al registrar una gran cantidad de dominios, por ejemplo 32, y forzar la carga de recursos desde un subconjunto controlado de esos dominios, se puede crear un vector de bits lo suficientemente grande como para representar de forma única a cada visitante. 

Apple ha decidido mitigar ambos lados del ataque, al limitar el estado de HSTS y abordar cómo se graba el estado de HSTS. Sin duda, un interesante paso que ha dado Apple hacia una mejora en lo que a privacidad se refiere.

Las páginas de Phishing están usando páginas con HTTPS para parecer legítimos

Actualmente más de la mitad de sitios web usan protocolos de cifrado de Internet para mantener los datos protegidos. Esto se debe a que desde hace ya unos años ha surgido un esfuerzo masivo para cifrar el tráfico web, hoy en día es habitual ver candados verdes y direcciones con "HTTPS". Esto ha supuesto un gran avance para la ciberseguridad, pero como con cualquier reforma amplia, el progreso viene acompañado de nuevas oportunidades para el fraude. La semana pasada PhishLabs publicó un nuevo análisis en el que se muestra un notable incremento del uso del protocolo HTTPS en páginas fraudulentas.

El Phishing es uno de los métodos más utilizados por los ciberdelincuentes para exfiltrar datos, es habitual que en este tipo de ataques se proporcione un enlace a una página supuestamente legítima en la que se solicitan los credenciales de alguna de nuestras cuentas. Muchas veces su apariencia idéntica a la página oficial o el simple hecho de que la página disponga de cifrado proporciona a las victimas una falsa sensación de seguridad que les puede acabar saliendo muy cara. El estudio realizado por PhisLabs ha revelado que el 24% de estos sitios fraudulentos disponen de cifrado frente al 3% obtenido en un estudio similar realizado hace 2 años. Esto se debe a que muchos estafadores implementan el protocolo HTTPS a propósito o construyen su sitio web a través del secuestro de otro sitio web legítimo.

Figura 1: Pagina fraudulenta de iCloud.

"En dos tipos sumamente frecuentes de estafas con PayPal y Apple como objetivo, aproximadamente el 75 por ciento de los sitios usaban el protocolo HTTPS, de hecho los atacantes optan por esta opción aunque no sea necesario para completar el crimen." ha dicho Crane Hassold, director de inteligencia en PhishLabs.

No cabe duda de que el uso del protocolo HTTPS ha sido un gran paso para incrementar nuestra seguridad en la red, sin embargo esto no nos protegerá frente a un ataque Phishing. La función de este protocolo es garantizar que la información intercambiada entre nuestro navegador y los servidores viaje cifrada, en el caso de los ataques Phishing la información no estaría siendo enviada a los servidores de una empresa legítima sino que estaría siendo enviada directamente a los servidores de un ciberdelincuente.  

Wallet-Snatch Hack: Apple Pay vulnerable a dos ataques en BlackHat USA

La Black Hat USA y la Defcon de este año ya han pasado. Siempre hay noticias relacionadas con el mundo Apple y, en esta ocasión, tenemos que hablar del Apple Pay. El mecanismo para los pagos de Apple sigue estando en el punto de mira de muchos investigadores. En esta ocasión, han presentado dos ataques distintos contra el Apple Pay, destacando lo que se afirma como debilidades en el método de pago móvil. Uno de los ataques requiere del Jailbreak en el dispositivo, mientras que el otro ataque no.

En el primer ataque, los investigadores de Positive Technologies, se debería tener un dispositivo con Jailbreak e infectado con malware. Habiendo logrado esto, se podría interceptar el tráfico que se dirige al servidor de Apple, en este caso, con los datos de pago que se agregan a la cuenta del dispositivo. Es el escenario más sencillo, desde el punto de vista técnico. El segundo ataque se puede realizar contra cualquier dispositivo dónde se intercepta y manipula el tráfico de transacciones SSL sin emplear ningún equipo sofisticado, según indican los investigadores. El ataque consiste en reproducir o manipular los datos de la transacción, cambiando la cantidad o la moneda que se está pagando o cambiando los detalles de entrega de las mercancías que se están comprando. 

Figura 1: Apple Pay

El primer paso del segundo ataque consiste en que el atacante robe el token de pago del dispositivo de la víctima. Para ello, utilizarán una WiFi pública u ofrecerán su propio hotspot WiFi falso. Ahora, se solicitará a los usuarios que creen un perfil. Desde este instante se puede extraer el criptograma de Apple Pay, la clave para cifrar los datos. Apple indica que el criptograma sólo debe utilizarse una vez. Sin embargo, los comerciantes y las pasarelas de pago se establecen para permitir que los criptogramas puedan ser utilizados más de una vez. Dado que la información de entrega se envía en texto claro, sin comprobar su integridad, el atacante puede utilizar un criptograma interceptado para realizar pagos posteriores en el mismo sitio web, cargando a la víctima dichas transacciones. Según los investigadores: "Los atacantes pueden registrar los datos de la tarjeta robada en su propia cuenta de iPhone o pueden interceptar el tráfico SSL entre el dispositivo y el servidor de Apple para realizar pagos fraudulentos directamente desde el teléfono de la víctima". 

La recomendacion de Positive Technology y de sus investigadores es que los usuarios estén atentos cuando utilicen Apple Pay para comprar artículos en línea, en particular monitorizando el uso de HTTPs y evitar realizar transacciones en entornos WiFi públicos dónde el tráfico pueda ser fácilmente detectado y manipulado.

OS X / Dok: Nuevo malware para Mac

Invesitgadores de seguridad han descubierto el pasado viernes una nueva pieza de malware para Mac. Esta nueva pieza de malware denominada OSX / Dok afecta a todas las versiones de OS X, incluyendo la última versión macOS Sierra. Una vez instalado, OS X / Dok es capaz de interceptar todo el tráfico web, incluso el que es transmitido a través de HTTPS. El vector de infección de OS X / Dok se difunde a través de campañas de phishing. Según los investigadores de CheckPoint, OS X / Dok apunta principalmente a los usuarios europeos de Mac. 

El correo electrónico de phishing contiene un archivo denominado Dokument.zip, el cual cuando es abierto, muestra un archivo llamado Dokument, el cual utiliza un antiguo icono de aplicación de vista previa que no se utiliza desde OS X 10.9. En comparación con el icono actual de la aplicación de vista previa utilizado hasta OS X 10.9, se puede ver la gran diferencia, simplemente con la calidad del icono. 

Figura 1: Vector de infección

¿Dónde se instala OS X / Dok.A? Cuando se abre el archivo Dokument, se muestra una advertencia falsa mientras la aplicación maliciosa AppStore.app se coloca en la carpeta /Users/Shared. Cuando se encuentra en la nueva ubicación, OS X / Dok se ejecuta y da a todos los usuarios en el sistema permiso para ejecutar el malware, eliminar la copia de la aplicación original y luego colocarse en los elementos de inicio de sesión para asegurarse de que tiene la oportunidad de instalar su carga o payload. OS X / Dok muestra un mensaje de pantalla completa, indicando que se ha identificado un probelma de seguridad y que se requieren actualizaciones. Esta ventana no se puede mover ni cerrar. 

Esta falsa alerta de seguridad es una táctica para obtener la contraseña del administrador del sistema. La ventana se mantendrá durante unos 5 minutos, mientras que en el fondo se realizan varios cambios en el sistema. Estos cambios incluyen la instalación de TOR y SOCAT. Si OS X / Dok obtiene privilegios de administrador, otorga privilegios dónde sea necesario sin que el usuario vea una solicitud de contraseña de nuevo. Esto se hace con la modificación del archivo sudoers.

Cuando Dok termina, se cierra la ventana de pantalla completa y se eliminará el elemento de inicio de sesión. El elemento de inicio de sesión se reemplaza con varios LaunchAgents en /Users/User/Library/LaunchAgents. Otros cambios en el sistema que el malware realiza son cambios en la configuración de red para configurar un proxy y la instalación de un certificado raíz en System.Keychain, el cual permite a un atacante interceptar todo el tráfico de web enviado a través del proxy.

Figura 2: Configuración de proxy

Como se puede ver, el malware tiene un gran potencial y es bastante dañino a la hora de obtener información privada de los usuarios. El atacante puede obtener información que viaja cifrada gracias a la instalación del certificado y puede controlar como administrador todo el sistema. Sin duda, uno de los malware para Mac más completos y potentes.

ATS: Se sigue esperando a que las apps de los iPhone sean más seguras

En el mes de diciembre hablamos de que la mayoría de las aplicaciones de la AppStore no estaban preparadas para la obligatoriedad de uso con ATS, App Transport Security. Llegando a final de diciembre Apple lanzó un comunicado dónde indicaban que se retrasaba la fecha de obligatoriedad de integración con ATS por parte de los desarrolladores de aplicaciones. Como es lógico, esto fue debido a la noticia anterior de la poca preparación de la mayoría de apps.

El pasado 1 de enero era el día en el que Apple quería hacer que ATS fuera obligatorio, si no tu aplicación dejaría de funcionar. Ese era el propósito de la gente de Cupertino. Eso sí, desde el comienzo de este año, todo desarrollador que ofrezca nuevas actualizaciones deberá hacerlo con ATS integrado. Hay que recordar que el ATS, entre otras propiedades o características, permite a las apps conectarse a través de comunicaciones HTTPS, dejando atrás los tiempos del HTTP en las aplicaciones móviles. De este modo, la información estará protegida y se logrará un estado de confianza en el manejo de la información a través de la red. El movimiento de Apple puede estar orientado a lograr que los iPhone sean una de las mejores opciones de cara a adquirir móviles de empresa, aparte de dotar de seguridad a los usuarios en sus comunicaciones.

Figura 1: Info.plist con ATS

A día de hoy, Apple está muy lejos de alcanzar su objetivo. Los desarrolladores no están integrándose con ATS y los datos son muy claros, solo el 3% de las 200 apps más descargadas para iOS han implementado la solución ATS. Es más, el 83% de las apps tienen deshabilitado completamente ATS, mientras que el 55% permite el uso de conexiones HTTP. Estamos seguro que ATS seguirá dando que hablar. Poco a poco los números irán mejorando y la mayoría de las apps que en el día a día utilizamos serán más seguras con el uso del sistema, mientras tanto estaremos atentos.

Apple cambia la fecha para la obligatoriedad de ATS en la AppStore

Apple ha tenido que ceder. El mecanismo ATS que mejora la seguridad de las comunicaciones entre apps y otras entidades que se relacionan con las aplicaciones del día a día de los usuarios tendrá que esperar para estar en todas las apps de la AppStore. Ya hemos hablado de que la fecha límite era el 1 de enero de 2017, pero al final Apple ha tenido que ceder. Según se pudo leer en un informe previo, solo un 3% de las apps estarían preparadas al 100% para cumplir con el mecanismo. Ante estos números, la empresa de Cupertino ha tenido que ceder y retrasar el mandatory de ATS.

ATS fue publicado por Apple en el año 2015 como un método para mejorar la seguridad y privacidad, forzando a las apps a transferir la información a través de comunicaciones bajo HTTPS y nunca bajo HTTP. Esto es algo hacia lo que tiende el mercado y es totalmente necesario para la sociedad en la que vivimos. Aunque ATS está puesto por defecto en los kit de desarrollo de Apple, desde iOS 9 y  OS X 10.11, el desarrollador, a día de hoy, tiene la opción de incluirlo o no. En el enlace podemos ver la notificación pública que ha realizado Apple.

Figura 1: Nota de Apple sobre el retraso de ATS en la AppStore

Apple se ha visto obligado a modificar su fecha de obligatoriedad de ATS en las apps de la AppStore. La fecha no ha sido publicado, pero se espera que se proporcionen algunos meses más a los desarrolladores para dejar configuradas las aplicaciones según los requisitos de Apple. Seguro que 2017 nos sigue trayendo noticias sobre este tema, porque parece que Apple dependerá de los números para obligar a todos los usuarios a utilizar ATS. Sin duda, es necesario para mejorar la seguridad de las apps y los usuarios.

La mayoría de las apps de la AppStore no están preparadas para ATS

A falta de un mes para que Apple aplique ATS a las comunicaciones de las aplicaciones en iOS, los desarrolladores de empresas no parecen listos para aceptarlos. De esto ya hemos hablado en Seguridad Apple recientemente, y es que la política de Apple es clara y estricta. En el caso de hoy, hablamos de un nuevo estudio realizado sobre las aplicaciones de la AppStore. El estudio fue realizado sobre las 200 aplicaciones más comunes instaladas en dispositivos iOS en entornos empresariales. 

Los investigadores analizaron la conformidad de estas aplicaciones con los requisitos de seguridad de las aplicaciones que se deberán cumplir. La característica ATS obliga a todas las aplicaciones a comunicarse con servidores de Internet mediante conexiones HTTPS y garantiza que solo se utilizan protocolos de cifrado estándar y algoritmos sin debilidades conocidas. Por ejemplo, la versión 3 de SSL no está permitida y tampoco lo está el algoritmo de cifrado RC4. A día de hoy, iOS proporciona un método para que las aplicaciones no utilicen ATS o para usarlo en ciertas conexiones, pero Apple cambiará eso. Meses atrás anunciaron que se requerirá que todas las aplicaciones publicadas en la AppStore active ATS a finales de este año. El requisito se aplicará a nivel de proceso de revisión de la AppStore. Habrá la posibilidad de utilizar algunas excepciones de forma "razonablemente justificada", pero deberán ser aprobadas por la empresa de Cupertino.

Figura 1: Resumen de estudio

Durante el estudio, se encontraron que el 97 por ciento de las aplicaciones analizadas, es decir 193 de 200, utilizaban excepciones y otros ajustes que deshabilitaban la configuración ATS predeterminada. De las 200 aplicaciones analizadas, 166 aplicaciones evitan algunos requisitos ATS, estableciendo el atributo NSAllowsArbitraryLoads con un valor de true en su archivo Info.plist. Sin embargo, no todos evitan los requisitos ATS para todas las conexiones de red, hay empresas que soportan ATS para conexiones en su dominio, mientras que no lo hacen con dominios externos. 

Se puede argumentar que algunas conexiones no necesitan HTTPS porque no son utilizadas para transferir datos sensibles, los investigadores del estudio se encontraron 10 aplicaciones que enviaban ID de dispositivo, direcciones de correo electrónico, direcciones físicas, códigos postales o información de geolocalización sobre comunicaciones HTTP no cifradas. El debate está montado, Apple tendrá que tramitar o rechazar una gran cantidad de solicitud de excepciones, visto lo visto. ATS está muy cerca y la AppStore no parece preparada.

Cómo afectará el cambio de las apps de iOS a ATS

En Seguridad Apple ya habíamos hablado de ello, y es que ATS está aquí para quedarse en las aplicaciones iOS. En el año 2015, Apple liberó iOS 9 e introdujo la función de seguridad ATS, App Transport Security, la cual requiere que la aplicación se conecte siempre vía HTTPS. Cuando la característica fue lanzada no era obligatoria y muchos desarrolladores utilizaron excepciones para evitar esta característica.

Lo que muchos no conocen es que el próximo 1 de enero de 2017, esta característica de seguridad será obligatoria para todos los nuevos envíos a la tienda de Apple, y será un requisito de las aplicaciones ya publicadas en la tienda. Con la aparición de iOS 10 se descubrieron algunos detalles interesantes y que traerán problemas en la adopción de ATS. Cuando un usuario, por ejemplo, utiliza la app de Facebook y navega hacia una fuente externa para reproducir un video o un audio que se entrega por HTTP, éste no se reproduce, ya que el contenido se transmite de forma insegura.

Como se puede imaginar, de aquí al 1 de enero de 2017, no todo estará migrado a HTTPS y se prevén bastantes problemas. Es sabido que se necesitan unas cuantas horas para pasar un sitio de HTTP a HTTPS: solicitud de certificado, instalación de certificador, auditar activos vinculados al sitio web para asegurarse de que se transmiten a través del nuevo protocolo, etcétera. Por ejemplo, el New York Times y Los Angeles Times no disponen del cambio a HTTPS, por lo que su contenido dejará de ser accesible, esto supone un problema importante.

Figura 1: ATS cambiará las comunicaciones de red inseguras

Algunas entidades, como las mencionadas anteriormente, podrán solicitad excepciones. Es decir, habrá algunas excepciones a los requisitos obligatorios de ATS, pero esto no significa que todas las excepciones anteriores sean válidas. Los desarrolladores tendrán que proporcionar una justificación razonable para estas excepciones, y en el caso de Apple existe poca transparencia cuando se trata de un proceso de toma de decisiones.

¿Qué se puede hacer? A continuación, enumeramos lo que se ha comenzado a indicar cómo consejos para los desarrolladores y organizaciones que tienen aplicaciones iOS:

• Si estás desarrollando una nueva aplicación para iOS, utiliza HTTPS de primeras para toda la comunicación en red.
• Si tienes una aplicación que ya ha sido aprobada por Apple, debes dedicar un equipo a auditar la aplicación y comprobar que todo va por HTTPS, adáptate a los cambios antes del nuevo año.
• Si tienes una aplicación que se conecta a servicios web que no están protegidos, debes declarar sus dominios como excepciones en la aplicación a través del info.plist como una solución a corto plazo y comienza a evaluar las opciones de migrado a HTTPS.
• Si tienes una aplicación que carga contenido de terceros a través de HTTP, debes trabajar con los proveedores de contenido para crear un endpoint con HTTPS, y evitar cualquier interrupción en la transmisión y visualización.

Tendremos un comienzo de año 2017 movido con la nueva característica ATS y, sobretodo, con las excepciones, ¿Cuál será válida y cuál no? ¿Cómo decidirá Apple?

InstaAgent volvió a la AppStore con otro nombre

El pasado mes de Noviembre hablamos en Seguridad Apple de la aplicación IstaAgent, el cual era un cliente bastante popular de Instagram que estaba robando credenciales de los usuarios. La aplicación enviaba dicha información a un servidor externo. Apple eliminó la aplicación de la AppStore y la amenaza parecía erradicada. Ahora parece que el desarrollador que estaba detrás de dicha aplicación ha conseguido dos nuevas aplicaciones aprobadas por Apple y Google, ambas aplicaciones están robando credenciales de Instagram.

El investigador que descubrió la función maliciosa en la primera aplicación, es decir, en InstaAgent, publicó la semana pasada una entrada en la que las nuevas aplicaciones podían robar credenciales de la misma forma. Este investigador escribió un artículo dónde se detalla cómo capturar las credenciales que se envían al servidor remoto. La aplicación InstaAgent atajo a los usuarios de Instagram con la promesa de realizar un seguimiento de las personas que visitaban su perfil. Las dos nuevas aplicaciones hacen promesas similares.

Figura 1: InstaCare app que roba credenciales de Instagram

Ambas aplicaciones dicen que pueden mostrar un listado de usuarios que interactuan a menudo con una cuenta o perfil de Instagram, pidiendo permiso a los usuarios para iniciar sesión. En ese instante es dónde las credenciales son robadas y enviadas al servidor externo. El envío de los usuarios y contraseñas no se realizaba por HTTP, y sí por HTTPs, de esta forma se intentaba ocultar la evidencia. Varias revisiones en la AppStore afirman que después de utilizar aplicaciones maliciosas de este tipo, sus cuentas se vieron comprometidas con fotos a modo de spam. Tanto Apple como Google llevarán a cabo la eliminación de ambas apps.

OSX: Muchas aplicaciones vulnerables a Man in the Middle

Un gran número de aplicaciones son vulnerables a los ataques conocidos como Man in the Middle y la posterior ejecución de código a través del sistema de actualización implementado. Esto es una afirmación que hoy día puede sorprender, o no, a muchos lectores, pero muchas de las aplicaciones más populares de OS X fueron evaluadas recientemente y se vio que eran vulnerables a este tipo de ataques. La vulnerabilidad se dirige especificamente a las conexiones HTTP sin cifrar y el marco de actualización de software de terceros.

Un ingeniero de seguridad de Vuln Sec llamado Radek comentó que este tipo de vulnerabilidades están funcionando en OS X El Capitan y en Yosemite. El gran número de aplicaciones afectadas no se conoce, pero Radek indicó que haciendo un ejercicio rápido de aplicaciones afectadas teníamos:

• Camtasia 2.
• DuetDisplay 1.5.2.4.
• uTorrent 1.8.7.
• Sketch 3.5.1.

  

Figura 1: Vídeo de demostración de RCE Vulnerability en aplicaciones OS X

Además, el investigador de seguridad Jonathan Zdziarski comentó que la herramienta de ingeniería inversa Hopper también es vulnerable. Si quieres ver la lista completa de aplicaciones que podrían ser vulnerables a ataques de ejecución de código a través de un MitM puede encontrar la lista en Github. Hay que señalar que no todas estas aplicaciones se comunican a través de HTTP. Los usuarios finales no tienen forma de conocer qué aplicaciones son vulnerables o no, por lo que se recomienda actualizar a través de la Mac App Store siempre que sea posible.

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.

FREAK: Factoring RSA Export Keys afecta a Safari

Esta semana se ha publicado una investigación que revela cómo, una debilidad de seguridad introducida por el gobierno de los Estados Unidos para no permitir que países extranjeros utilizasen criptografía segura, ha generado un problema de seguridad en todo el mundo - incluyendo Estados Unidos -. Esto se debe a que, productos como OpensSSL o Apple TLS/SSL venían con algoritmos de cifrado RSA permitidos para exportación al extranjero que usaban cifrado con RSA de 512 bits de longitud, algo que para los años 90 era "decentemente seguro" pero ni mucho menos invulnerable para la NSA.

Hace décadas, estos algoritmos han dejado de ser seguros para nada. Con los años, OpenSSL y Apple TLS/SSL han seguido manteniendo soporte de estos protocolos de "cifrado para exportación", y navegadores como Android o Apple Safari permiten negociar estos algoritmos de cifrado. Esto permite que se pueda hacer un ataque, al que se ha denominado Freak - de Man In The Middle impersonando un servidor web si tanto el servidor web como el cliente permiten la negociación de estos algoritmos de cifrado inseguros. El siguiente vídeo muestra su funcionamiento.

Figura 1: Vídeo demostrativo de FREAK

Ya ha habido partes de seguridad en OpenSSL y Apple ha prometido parchear todas las versiones de Apple Safari que aún permiten negociar este tipo de algoritmos de cifrado para exportación. Curioso que Estados Unidos inyecte un fallo de seguridad criptográfico y acabe afectándole.

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.

SSTP: Configurar conexiones VPN SSL con EasySSTP

En la entrada de ayer hablamos de las alternativas configurar VPN SSL en Mac OS X con SSTP. Hoy queremos realizar un paso a paso e ir mostrando cómo configurarlo en un OS X Mountain Lion, primero con la utilidad Easy SSTP y luego lo haremos con sstp-client. En primer lugar debemos descargar la aplicación de prueba, o pagar directamente la licencia, en el sitio oficial de EasySSTP. La instalación de la herramienta es un sencillo asistente gráfico. Una vez instalada la aplicación, podremos observarla en la barra superior de nuestro Mac OS X. 

La aplicación no dispone de grandes pantallas de configuración donde se deba indicar cientos de parámetros. Su configuración, como vamos a ver, es realmente sencilla, solamente deberemos indicar dónde conectarnos, qué tipo de conexión queremos, el certificado que usaremos - si hay autenticación basada en certificados - y las credenciales de usuario. 

Figura 1: Menú de Easy SSTP en la barra de OS X Mountain Lion

Configuración de EasySSTP

Para llegar a la pantalla de configuración pincharemos sobre el icono de la aplicación en la barra superior de nuestro Mac OS X y pulsamos sobre "Configure". En primer lugar nos saldrán las conexiones, con los nombres de ésta. Como se acaba de realizar la instalación no tendremos ninguna conexión, por lo que creamos una y le damos un nombre.

Figura 2: Creación de la plantilla para la conexión

Después debemos configurar la conexión con los parámetros necesarios, los cuales enumeramos y configuramos a continuación:

• Tipo de conexión. Este parámetro indicará si la conexión requerirá solamente credencial de usuario o si requerirá credencial de usuario con certificado. Es recomendable que el servidor solamente permita el tipo de conexión de password con certificado, ya que dota al sistema de un plus de seguridad.

• Server. Debemos proporcionar la dirección IP del servidor.

• CA Certificate. En caso de utilizar el tipo de conexión Password With Certificate, se debe indicar el certificado, en formato PEM. Más adelante hablaremos de como transformar un certificado en PEM mediante OpenSSL.

• Username y Password. En estos campos se introducirán las credenciales de usuario.

Figura 3: Configuración de la conexión VPN

Hay que hacer un inciso para indicar cómo convertir el certificado a formato PEM, que es el requerido por la aplicación. Para ello utilizaremos la herramienta OpenSSL con la siguiente sintaxis:

openssl x509 -inform der -in -out .

Una vez configurada la conexión almacenamos la configuración y pulsamos sobre el icono de EasySSTP para lanzar la conexión, tal y como se puede apreciar en la imagen.

Figura 4: Conectado a la VPN

Si todo marcha bien habremos realizado la conexión y dispondremos de una VPN bajo SSL en nuestro sistema Mac OS X. Es interesante recalcar que el uso de estas VPN frente a las clásicas radica en la utilización del puerto y trafico bajo HTTPs, por lo que estemos en el entorno que estemos disfrutaremos de nuestra conexión VPN para poder seguir trabajando.

SSTP: Configurar conexiones VPN SSL en Mac OS X

El protocolo SSTP (Secure Socket Tunneling Protocol) se utiliza para configurar las llamadas VPN SSL, es decir, Redes Privadas Virtuales que usan como capa de cifrado SSL y funcionan por los mismos puertos que HTTPs. Esto les confiere una ventaja frente a las conexiones VPN tradicionales basadas en IPSEC, L2TP o PPTP, ya que todas ellas necesitan puertos especiales. El que no requieran del uso de puertos especiales, hace que sea fácil conectarse con ellas desde cualquier red, mientras que cuando hablamos de conexiones PPTP o L2TP es posible que desde redes de hoteles o ciber-cafés, los puertos necesarios para la negociación no estén habilitados.

En Mac OS X las conexiones VPN que se pueden crear, sin embargo, sólo son aquellas basadas en PPTP, L2TP e IPSec, por lo que por defecto no es posible hacer uso de SSTP sin instalar software añadido.

Figura 1: Opciones de VPN en OS X Mountain Lion

Las opciones para configurar una conexión VPN SSL en Mac OS X no son demasiadas. Se puede utilizar SSTP-Client, un port de la herramienta cliente de Linux migrado con MacPorts.

Figura 2: VPN SSL con sstp-client

Y si quieres la vida fácil, lo más cómodo es comprarse EasySSTP para Mac OS X que por menos de 10 USD te da un interfaz gráfico para configurar todo, aunque no es difícil hacerlo por scripts. Puedes probarla durante 30 días.

Figura 3: EasySSTP para Mac OS X

Con cualquiera de estas dos herramientas es posible configurar las VPN SSL en Mac OS X, aunque en sstp-client hay que hacer un poco más de trabajo. Pero para que veáis que no es tan complicado, en un post siguiente os dejaremos un paso a paso para montarlo con un certificado autofirmado en el servidor SSTP y hacer certificate pinning.

Apple implementa HTTPs por defecto en App Store

El movimiento de Apple hacia HTTPs ya se veía venir. Hace ya algún tiempo fue implementado en iTunes, y con lo que consiguió proteger a los usuarios contra la censura de apps en sitios como China, donde las utilizadas para privacidad estaban bloqueadas. Ahora el paso se ha dado en la App Store, donde se aplicaban ataques clásicos de esquemas de man in the middle por culpa de no  cifrar correctamente el tráfico. Aquí algunos ejemplos:

- Robo de contraseñas de App Store: Como la petición se hace en HTTP, el atacante podría interceptar la petición y devolver un falso cuadro de login para robar la contraseña, tal y como se ve en el siguiente vídeo.

Esta credencial se podría utilizar para después descargarse el backup de iCloud con herramientas como ElcomSoft Phone Password Breaker.

- Intercambio de apps: El usuario solicita la app que quiere instalar por medio de su ID, pero si el hombre en medio cambia ese ID por el de otra app, la víctima acabaría instalado otra app dentro de su sistema.

Esto podría utilizarse para descargar software malicioso dentro de sistemas que se conectasen a redes WiFi comprometidas.

- Falsas actualizaciones: Podría lograrse manipular la página donde se muestran las actualizaciones disponibles en la App Store, y que el usuario atacado instalara una nueva app.

Por supuesto, también se podría sacar información de las apps instaladas de un usuario, o bloquearle la posibilidad de que se instale uan determinada app, como sucede en países que aplican la censura.

Con este movimiento, como dicen en Una al día, se acaban de una vez todos estos posibles ataques, algo que los usuarios de iOS agradecerán sin duda, pues no todo el mundo está teniendo cuidado de las redes que utiliza para actualizarse sus apps.

HTTP-s y la censura de iTunes en el Gran Firewall Chino

Hace poco Apple ha habilitado el soporte de HTTP-s para la mayoría de las consultas de la tieneda de iTunes, lo que hace que la búsqueda de aplicaciones y la descarga de las mismas estén siendo realizadas bajo conexiones cifradas HTTP-s. Esto, como explican en GreatFire.org ha hecho que aplicaciones para VPNs, tradicionalmente filtradas por el Firewall Chino ya que evitan la inspección de tráfico, estén pudiendo ser descargadas ahora mismo. Esto puede comprobarse desde la siguiente web, que intenta conectarse a una URL desde detrás del firewall para ver si es posible o no.

Figura 1: Test de censura de URLs en Greatfire.org

Sin embargo, no creemos que el gobierno Chino permita que esto pase mucho tiempo, y comience de nuevo a inspeccionar este tráfico como suele hacer, mediante un proceso de SSL bridging con HTTP-s en el que genera un nuevo certificado para el sitio que quiere inspeccionar, pero firmado por una CA controlada por el gobierno - como hace con la mayoría de los servicios HTTP-s de Internet. Es decir, hay dos tramos de cifrado HTTP-s, tal y como se puede ver en la siguiente imagen:

Figura 2: Esquema de funcionamiento de un SSL Bridge con HTTP-s

De esta forma, el tráfico entre los clientes y el firewall va en HTTP-s cifrado con el certificado que tienen controlado, descifran el tráfico, lo analizan, y si consideran que debe pasar, vuelve a cifrar el tráfico entre el firewall y el servidor de iTunes, utilizando el certificado oficial de iTunes. 

Figura 3: Certificado original usado por itunes.apple.com

Para mitigar este tipo de ataques de SSL Bridging en HTTP-s por parte de gobiernos de dudosas prácticas, el investigador español Yago Jesús (@YJesus), de Security By Default, publicó SSLCop, una herramienta que en sistemas Microsoft Windows elimina la confianza en las CAs de determinados países.

Figura 4: SSL Cop permite revocar las CAs de determinados países en Windows

En sistemas Mac OS X hay que hacerlo manualmente - aunque haya habido bugs que lo evitaban -, y en los terminales iOS, por desgracia, no es posible dejar de confiar en una CA que Apple haya introducido en los equipos, lo que deja poco de elección en las manos de los clientes, y en este tipo de situaciones no puede defenderse - como ya pasara con las CAs de Comodo hace ya más de un año -.