Hijacking a Instagram for iOS en redes WiFi públicas

Instagram for iOS tiene un fallo en la configuración de la aplicación el cual podría permitir a un atacante realizar un hijacking de sesión de un usuario si el atacante y éste se encuentran en la misma red WiFi pública. Stevie Graham, presentó la vulnerabilidad directamente a Facebook, al cual fue contestado con un "Se conoce desde hace años". Graham decidió escribir una herramienta para comprometer las cuentas de Instagram para demostrar el fallo y darle la importancia que tiene.

Ha llamado a la herramienta Instasheep, en honor al famoso Firesheep, el plugin de Firefox que permitía obtener sesiones de usuario siempre y cuando estuviéramos en medio de una comunicación, por ejemplo mediante un ataque ARP Spoofing. Graham explica que por ejemplo, podría ir a la tienda de Apple y obtener miles de cuentas en un día para luego utilizarlas para enviar spam. Graham comenta lo siguiente respecto al ataque:

"Creo que este ataque es muy grave, ya que permite un robo de sesión completo y es automatizable fácilmente".

Figura 1: Esquema de Hijacking

Lo que realmente ha encontrado Graham es un problema de configuración que es conocido hace mucho tiempo, y que ha llevado a que muchas compañías de Internet cifren el tráfico completamente para evitar el problema. La API de Instagram realiza solicitudes no cifradas a algunas partes de su red. Este hecho representa una oportunidad para que un potencial atacante que esté ubicado en la misma red WiFi pública, la cual no utiliza ningún tipo de cifrado, pueda capturarlas sin ningún problema. 

¿Sin ningún problema? Hay que recordar que una red WiFi pública o sin cifrado, se comporta como un hub, ya que el medio de difusión de los paquetes es el aire, y cualquiera puede escuchar dicho tráfico, incluso sin estar conectado a la red pública. El atacante puede configurar su tarjeta inalámbrica en modo monitor y capturar el tráfico. Entonces, si la red WiFi no está cifrada y tampoco lo están las peticiones de Instagram, se puede obtener la cookie de sesión de cualquiera que esté utilizando dicha red.

Figura 2: El ataque ha sido automatizado con la herramienta instasheep

El co-fundador de Instagram respondió que la plataforma está en constante implementación del cifrado completo en todas sus comunicaciones, pero que el proceso no es tan ligero como puede parecer en un principio. Esperan pronto haber solventado el problema de configuración que está desembocando en un fallo de seguridad, y más hoy en día con los smartphones. En el blog de Hackplayers podemos ver los pasos para reproducir el ataque que ha expuesto Graham:

1. Conectar con un punto de acceso abierto o WEP. 
2. Interfaz en modo promiscuo filtrando por el dominio i.instagram.com. Graham pone como ejemplo la instrucción  tcpdump - In -i en0 -s 2048 -A dst i.instagram.com. 
3. Esperar a que alguien con iOS utilice Instagram.
4. Extracción de la cookie de la cabecera de una petición capturada. 
5. Suplantación de la cookie para cualquier llamada a la API.

Se puede ver que el ataque es sencillo, ya que no es nada nuevo y es de fácil reproducción. También hay que tener en cuenta que el impacto está limitado a una red inalámbrica, por lo que se recomienda no conectar el dispositivo a redes que no sean de confianza. La herramienta se puede descargar desde su repositorio de Github.

Dos formas de saltarse el filtro AntiXSS en Apple Safari

En el blog de Eleven Paths se han publicado dos formas distintas de saltarse el filro AntiXSS que implementa WebKit y que actualmente afectan a Apple Safari. La primera de ellas, que está solucionada en el proyecto Chromium pero aún ha sido implementada en Apple Safari, fue descubierto por nuestro compañero Ioseba Palop, del equipo que desarrollo el servicio de pentesting persistente Faast.

Figura 1: Código de web con iframe vulnerable a este ataque

Dicho fallo se encuentra en la implementación que hace Webkit de la etiqueta IFRAME, que en HTML5 permite el uso de srcdoc, con lo que una inyección en un iFRAME permtiría inyectar el atributo srcdoc con un campo SCRIPT que no es sanitizado por AntiXSS en la versión actual de Apple Safari, dando lugar a lo que se ve a continuación.

Figura 2: Se inyecta una cadena del tipo "srcdoc="<script>alert('XSS')</script>

El segundo de los fallos fue publicado por un investigador chino que aprovecha una inyección dentro de un bloque de código SCRIPT. En ese caso, inyecta solo la etiqueta de apertura y se aprovecha de la etiqueta de cierre que ha puesto el programador en la web.

Figura 3: Ejemplo de código vulnerable y explotación

El resultado es lo que se puede ver a continuación, basta con inyectar una cadena con la etiqueta de apertura en una web vulnerable y se obtiene la ejecución del SCRIPT.

Figura 4: Ejecución del script en Apple Safari última versión en OS X Mavericks

Esperemos que Apple Safari actualice su motor con las últimas versiones del filtro AntiXSS y soluciones estos dos bugs que abren la puerta a los ataques client-side, ya sean phishing y/o hijacking.

DNS de WhatsApp secuestrado pero los mensajes intactos

Ayer fue un día intenso para los responsables de seguridad de WhatsApp ya que además de tener que lidiar con una nueva Prueba de Concepto que muestra cómo es posible descifrar las conversaciones de WhatsApp por una red WiFi - lo que abre una gran puerta a que se genere una nueva herramienta que dé completamente la vuelta a las técnicas de cómo espiar WhatsApp - el sitios web de la compañía sufrió lo que parecía ser un defacement en toda regla.

La intrusión, que en definitiva fue "solo" un DNS Hijacking al más puro estilo Hacker Épico, fue a cargo de un grupo Pro-Palestino que logró apuntar el nombre de dominio de www.whatsapp.com a un servidor web controlado dónde se había puesto una página cambiada, pero nunca tuvieron acceso a los datos de las conversaciones almacenadas en los servidores de WhatsApp.

Figura 1: Sitio web de WhatsApp secuestrado y defaceado

Tras el susto, todo volvió a la normalidad, y a pesar de la prueba de concepto sobre el descifrado de las conversaciones, aún no hay una herramienta pública capaz de hacerlo, aunque parece que la habrá, por lo que cualquier conversación de WhatsApp que se haya grabado o que se grabe durante este periodo de tiempo, tal vez pueda ser descifrada en el futuro. No obstante, cuidado con lo que envías por WhatsApp, que ya sabes que podrá ser descifrado en breve y que aunque borres los mensajes pueden ser recuperados con Recover Messages.

Mundo Hacker TV: Demos de hijacking de iOS apps

A principios de Septiembre se emitió el Episodio número 8 de Mundo Hacker TV, dentro de lo que es la segunda temporada, dedicado esta vez a la seguridad de los dispositivos móviles. El título del programa fue "Bring Your Own Device". y en el se tocaron muchos de los temas que tratan aquí en Seguridad Apple. Nuestro compañero Chema Alonso estuvo hablando de iOS. En la parte de Welcome to the real world, hizo las demos de Hijacking  de Facebook para iOS y Hijacking Linkedin para iOS. 

Esta es la tercera vez que Chema Alonso participa en un programa, ya que estuvo en el Mundo Hacker de TV de los metadatos, del que luego se grabó una versión más reducida para Televisión que nunca se llegó a emitir.

Linkedin para iOS vulnerable a ataque de Hijacking

Hemos podido comprobar que, al igual que ya sucedía con Facebook para iOS o Dropbox para iOS, la aplicación de Linkedin para iOS también es vulnerable ante un ataque de Hijacking mediante el acceso a las cookies de sesión almacenadas en el dispositivo.

La vulnerabilidad es la misma, y se explota de forma similar, ya que basta con tener acceso a un backup del dispositivo móvil y copiar un par de ficheros que utilizar la aplicación para guardar todos los datos del usuario conectado y la sesión abierta.

Los ficheros son:

Linkedin/Cookies/Cookies.binarycookies
Linkedin/Preferences/com.linkedin.Linkedin.plist

Figura 1: Copiando los ficheros con iFunBox

Es suficiente, por tanto, que alguien pueda acceder a ellos antes de que se haya cerrado la sesión, para que pueda reutilizarlos en cualquier otro dispositivo y acceder a la sesión definida en ellos, por lo que habría que tener especial cuidado con ellos. Como es necesario que se acceda a un bakup, y que pueda ser crackeado el passcode, por lo que se hace especialmente importante proteger el backup contra ataques al passcode. La otra alternativa es un dispositivo con jailbreak y un ataque de Juice Jacking.

Figura 2: Cierre de sesión en Linkedin para iOS en iPad

Además, nos gustaría recordar que Linkedin, a día de hoy, sigue sin cifrar las comunicaciones una vez abierta la sesión, así que no solo se transmite información sensible como los datos de reuniones, sino que sigue siendo posible que alguien en nuestra misma red WiFi pueda robarnos la sesión con un hijacking de red, por lo que hay que tener mucho cuidado con usar Linkedin para iOS en redes inseguras.

Hijacking en Facebook para iOS y Android: Demostración

A principios de este mes de Abril, el investigador/desarrollador británico de plataformas móviles Gareth Wright, reportó un serio problema de seguridad en la aplicación nativa de Facebook para iOS - también en la de Android -. El problema reside en que la aplicación almacena información sensible, en los ya conocidos archivos de configuración plist - muy utilizados en los sistemas operativos de Apple -.

Entre la información que se almacena en estos archivos, se encuentran las credenciales oAuth  - oAuth key and secret - utilizadas para acceder a las cuentas de Facebook. Este fallo de seguridad da pie a ataques como hijacking de sesión, y a partir de ahí todo el destrozo que alguien malintencionado pueda causar en una cuenta personal de Facebook. Además según afirma Wright, se podría utilizar el FQL (Facebook Query Language) y obtener datos extras de la cuenta Facebook del usuario.

Figura 1: Datos de sesión en el fichero com.facebook.Facebook.plist

Tal y como comentó Wright, el error fue encontrado, mientras se navegaba por el sistema de ficheros con un explorador de ficheros de iPhone, es decir, una herramienta del tipo iFunBox, DiskAid, o similares. En Seguridad Apple hicimos pruebas para ver si continúan los errores, y poder testear el fallo de primera mano. Y este es el resultado para la demo que se enseño en The App Fest.

Esto se puede hacer ahora fácilmente con la herramienta Facebook Recover para iOS, que con solo apretar un botón extrae la sesión Facebook de un terminal iOS o de un Backup de iOS. 

Figura 1.1: Facebook Recover para iOS

Hijacking en Facebook para iOS: Prueba de Concepto

El primer paso es conectar el dispositivo - en este caso un iPhone 4 - a un equipo  con cualquier sistema operativo con iFunBox instalado para poder acceder al sistema de ficheros del terminal, y situarse en la siguiente ruta:

Figura 2: Ruta a los ficheros de sesión

En  ella se encuentran las dos carpetas que contienen los archivos que interesan, que son los siguientes:

Cookies.binarycookies
com.facebook.Facebook.plist

El primero se encuentra en la carpeta Cookies, y el segundo en la carpeta Preferences. Una vez localizados los archivos basta con copiarlos al equipo en el que se tiene instalado el iFunBox.

Figura 3: Ficheros que forman parte de la sandbox de Facebook para iOS

Una vez se tienen los ficheros en el equipo de escritorio, posteriormente dichos archivos pueden ser copiados a otro dispositivo iOS, robando de esa manera la sesión de Facebook. Para hacer las pruebas y ver de manera correcta como se realiza el robo de sesión, sería conveniente acceder primero a una cuenta iOS, y después salir o cerrar la sesión, tal y como se aprecia en la siguiente captura:

Figura 4: Una vez copiados los ficheros, cerramos la sesión de la cuenta robada

De esta manera, la próxima vez que se ejecute la aplicación Facebook, aparecerá el panel de login, tal y como se muestra a continuación:

Figura 5: La sesión está cerrada, y no se conecta la aplicación

Sin embargo, los ficheros robados mantienen la sesión via, por lo que una vez que se han copiado estos dos archivos a otro dispositivo iOS  - o al mismo que se le han robado los fichero ya que para hacer la prueba basta con un terminal -, se puede comprobar como al arrancar la aplicación de Facebook, ésta accede a la cuenta del usuario al que se le han robado los archivos, sin pedir los datos de autenticación, tal y como se muestra en la siguiente captura:

Figura 6: La sesión vuelve a aparecer

Estado del bug

En el primer mensaje de Wright no se indicaba si el fallo afectaba tan sólo a dispositivos que tuviesen el Jailbreak realizado y Facebook, contestó con lo siguiente al mensaje de Wright con el fallo de seguridad:

Figura 7: Contestación de Facebook al fallo de seguridad reportado por Wright

Así que Wright respondió de nuevo, diciendo que se puede realizar tanto en dispositivos a los que se les haya realizado el Jailbreak, como a los que no lo tengan, ya que basta con acceder a estos ficheros en un backup del terminal. Con lo que queda clara la afirmación de Wright de que todos los usuarios de Facebook en iOS son vulnerables.

Además dice Wright, que es mayor riesgo reside en el malware y virus especialmente diseñados para adquirir datos de los dispositivos conectados a un equipo de escritorio. Por lo que hay que pensárselo dos veces antes de conectar nuestro dispositivo iOS - o Android - a un PC no fortificado, y las music stations o cargadores de batería públicos en las que puedan hacernos un juice jacking.

Facebook ha confirmado que está trabajando en cerrar dicha vulnerabilidad, pero mientras tanto, cuidado donde dejáis los teléfonos y donde los conectáis.

Hijacking a Facebook y DropBox con un fichero en iOS

Hoy en día ya son muchos los usuarios que saben lo que es un hijacking o robo de sesión y el riesgo que este fallo de seguridad supone, al poner en peligro la privacidad de un usuario. Es por esto que esta noticia ha generado gran revuelo en el mundo de los dispositivos iOS.

El investigador Gareth Wright reveló un agujero de seguridad en la aplicación de Facebook para dispositivos móviles que funcionan en iOS, y también probablemente en Android.

Un sencillo truco que consiste en copiar un archivo de texto plano de tipo .plist de un dispositivo iOS y pegarlo en otro dispositivo, para conseguir acceso a la cuenta Facebook que se estaba ejecutando en el primer dispositivo. 

The next web ha descubierto que el popular servicio de almacenamiento en la nube DropBox también dispone de este fallo de seguridad en sus archivos de sincronización. El fallo de seguridad radica en la propia arquitectura de la aplicación, que almacena en el dispositivo esa información en formato texto, en lugar de cifrar y proteger ese archivo.

Esto se puede hacer ahora fácilmente con la herramienta Facebook Recover para iOS, que con solo apretar un botón extrae la sesión Facebook de un terminal iOS o de un Backup de iOS. 

Figura 1.1: Facebook Recover para iOS

Cómo se descubrió, cómo Facebook se defendió, y cómo se equivocó

Este fallo fue descubierto a través del uso de la aplicación iExplorer en un iPhone. Se analizó el archivo .plist que utiliza la aplicación de Facebook y se confirmó que contenía toda la información necesaria para realizar una suplantación de sesión. Entonces, tan sencillo como copiar este archivo a otro dispositivo iOS y ejecutar el cliente de Facebook para iOS.

Como respuesta a esto, Facebook lanzó un comunicado en el que confirmaban el fallo de seguridad, pero que éste sólo sería explotable en dispositivos iOS con jailbreak. Horas después se confirmó que esta declaración no es cierta [FAIL] ya que si se conecta un iOS a un equipo puede ser suficiente para acceder a esa información.

Es interesante reflexionar sobre que si este tipo de aplicaciones de empresas tan grandes, como Facebook y DropBox, tienen este tipo de fallos de seguridad y carencias de programación segura, es muy posible que otros servicios dispongan también de estos fallos de seguridad. 

Por último, queremos recordar que es importante tener cuidado dónde se conecta el dispositivo. Ya hablamos de las técnicas de Juice Jacking, y por supuesto, para los amantes de las herramientas de este tipo de ataques, automatizar la búsqueda de estos archivos será tarea sencilla. ¡Ah!... y no dejes tu dispositivo al alcance de otros....

Robos de sesión mediante Firesheep: POC con Facebook y Tuenti

El término hijacking es empleado para definir la acción de realizar un ataque contra uno o más usuarios con la intención de recolectar cookies y así poder suplantar la identidad de dichos usuarios. En la gran mayoría de portales web, este ataque se puede llevar a cabo gracias a que no se hace un buen uso del protocolo SSL, sea por sencillez, ahorro de recursos, etcétera. Ya que una vez el usuario ha sido autenticado mediante el protocolo HTTPS, este pasa a continuar la conexión con el protocolo HTTP, por lo que todos los datos que se estén enviando viajaran en claro por la red.

A través de Cyberhades, pudimos leer como en la ToorCon 12 (Conferencia de seguridad informática) se publicó la extensión para Firefox Firesheep soportada en Windows y Mac OS X. La función de dicha extensión es básicamente la de escuchar todo el tráfico de nuestra interfaz y detectar cuando se están enviando cookies que puedan ser de interés para el usuario, mostrándolas por pantalla y de este modo dando la posibilidad de realizar suplantaciones de identidad de una forma sencilla e intuitiva.

Seguidamente se va a realizar una prueba de concepto para visualizar la sencillez de la extensión y el peligro de la misma. Descargamos el fichero desde el portal web de Firesheep. Podremos observar que se nos ha descargado un fichero en formato XPI, si arrastramos este a nuestro navegador Firefox, automáticamente se nos informará si deseamos instalar la extensión. Una vez instalada y reiniciado el navegar podremos observar la extensión en nuestro panel de Complementos.

Figura 1: Instalando Firesheep

Por defecto la extensión aparece como oculta, si deseamos interactuar con ella, es necesario dirigirnos a ‘Ver / Panel lateral / Firesheep’  y automáticamente aparecerá un panel en la banda izquierda del navegador que nos permitirá interactuar con Firesheep.

Figura 2: Plugin en Firefox

En la parte inferior del panel se podrá abrir la ventana de preferencias para configurar la extensión:

Figura 3: Configuración de Firesheep

- Capture: Permite indicar porque interfaz se va a escuchar el tráfico.

- Websites: Desde este módulo se podrá visualizar, añadir, editar, eliminar, importar y exportar las cookies que soporta la extensión. Desde el siguiente enlace (http://github.com/codebutler/firesheep/wiki/Handlers) se puede visualizar cuales son soportadas y cuáles serán soportadas en un futuro.

- Advanced: Permite configurar el protocolo y puerto que va a filtrar en busca de las cookies.

Para hacer funcionar la extensión y que empiece a capturar cookies únicamente bastará con pulsar sobre el botón Start Capturing, y esperar a que alguien realice alguna conexión a alguno de los portales web soportados.

Figura 4: Detección de cookie de Facebook

Una vez capturada una cookie de otro usuario, la propia extensión la añadirá al panel y ya podremos interactuar con el portal web que estaba visitando la víctima, haciéndonos pasar por él.

Figura 5: Acceso a cuenta de Facebook

Como ya se ha comentado anteriormente la extensión permite añadir portales que no estén soportados, Tuenti por ejemplo no se encuentra en la lista de soportados ni tampoco en los pendientes por añadir. Bastaría únicamente con dirigirte a la pestaña de añadir Add en la pestaña de Websites de Preferencias e introducir el script necesario para que detecte el portal web que deseemos.

El siguiente código es el ejemplo del código necesario para que la extensión detecte cookies de tuenti.

// Author: SeguridadApple - http://www.seguridadapple.com
// v2.0
register({
name: "Tuenti",
url: 'http://www.tuenti.com/',
domains: [ 'tuenti.com' ],
sessionCookieNames: [ 'sid' ],

identifyUser: function () {
var resp = this.httpGet(this.siteUrl);
this.userName = 'Tuenti User';
this.userAvatar = 'http://alt1040.com/files/2009/03/tuenti.jpg';
}
});

Una vez detectado una cookie de tuenti, nuestra extensión tendrá una apariencia similar a la siguiente.

Figura 6: Detección de cookie de Tuenti y acceso a cuenta

Hay que tener en cuenta que es necesario estar escuchando el canal para poder capturar las cookies de los usuarios. Conexiones cifradas como se puede encontrar en la tecnología Wifi (WPA, WPA2) será necesario acompañar a la extensión con un ataque MITM para interceptar todo el tráfico de la víctima. En escenarios con concentradores de conexiones HUB o redes WiFi abiertas, como pueden ser universidades, no será necesario realizar el ataque MITM, ya que todo el tráfico llega a nuestra máquina en texto claro.

Una solución rápida y eficaz sería la de aplicar extensiones a nuestros navegadores para que forzaran la navegación siempre que sea permitido por el protocolo Https. Esperamos que esta prueba de concepto os haya concienciado de lo importante que es una buena implementación del protocolo SSL en portales web donde se maneja gran cantidad de información privada y de no conectarte nunca a sitios privados desde redes inseguras.