domingo, 20 de abril de 2014

A vueltas con la localización: Viber, WhatsApp y sus leaks


Continuando con los últimos errores descubiertos en la aplicación de WhatsApp, unos unos investigadores de la Universidad de New Hampshire han detallado paso por paso el procedimiento que realizada WhatsApp cada vez que compartimos una ubicación, mostrando que al compartir una ubicación entre dos usuarios, la aplicación necesita en primer lugar ubicarlos en Google Maps dentro de una ventana de la propia aplicación.

WhatsApp obtiene la ubicación y miniaturiza una imagen del propio Google Maps para compartirlo como el icono del mensaje, pero desafortunadamente WhatsApp descarga esta imagen a través de un canal no seguro, sin utilizar SSL, lo cual implica que podría ser descubierto durante un ataque man-in-the-middle:

Este mismo error también lo comete la gente de Viber. Durante nuestra charla de WhatsApp: mentiras y cintas de vídeo, que mostramos Pablo y yo en RootedCON 2014, mostramos que también era posible capturar los datos de localización y los ficheros que se comparten entre dos usuarios, debido a que se envían en claro sin utilizar ningún canal seguro.

Esto, de la misma forma que en el caso de WhatsApp, nos permitiría interceptar esta información con un sencillo ataque man-in-the-middle o utilizando un Rogue AP:

Si queréis conocer más detalles del funcionamiento de este tipo de ataques y el funcionamiento interno de aplicaciones como Viber, Snapchat, WhatsApp o cualquier otra mensajería, os recomiendo echar un vistazo a las diapositivas de nuestra charla:

lunes, 14 de abril de 2014

Crash remoto de WhatsApp para iPhone en versiones < a 2.11.7


Como todos sabéis, el los últimos meses, tanto Pablo como yo, hemos estado investigando sobre diferentes clientes de mensajería instantánea para móviles, y poniendo el foco sobre WhatsApp.

Entre los diferentes descubrimientos que hicimos, nos dimos cuenta de las inseguridad que presentaba el uso de RC4 en el cifrado de mensajes, la posibilidad de poder modificar el remitente de forma transparente, y mucho más, así que nos planteamos diseñar un programa, que bautizamos como WhatsApp Privacy Guard, que fuera capaz de añadir diferentes capas de seguridad a la aplicación, usando cifrado más seguro, opciones de anonimato o servidores propios de mensajería XMPP.

Mientras estábamos haciendo las diferentes pruebas con el cifrado adicional, además, nos dimos cuenta de que el podíamos generar un crash en la aplicación si el destinatario final de los mensajes con cifrado no estaba conectado al sistema.

Dentro de nuestra presentación WhatsApp: mentiras y cintas de vídeo, del congreso RootedCON, mostramos una prueba de concepto del funcionamiento del programa, en el que podemos observar el intercambio de mensajes a través de nuestra plataforma.

Nuestro programa detecta el envío de un texto en claro en WhatsApp, y utilizando la clave de sesión de RC4, descifrará el mensaje y extraerá el texto. Una vez tenemos este texto, lo cifraremos de nuevo utilizando el algoritmo que hayamos implementado, y lo vuelve a encapsular en el formalo de WhatsApp, utilizando RC4 y su clave correspondiente. Para ello también recalcularemos el HMAC del mensaje:

El proceso en la parte del receptor será el inverso del que acabamos de explicar, para que pueda visualizar el mensaje original. Veámoslo en una demostración real:



El resultado de la recepción de estos mensajes cifrados por parte de un cliente que no esté conectado al sistema, y que por tanto no es capaz de descifrar el contenido del mensaje, inicialmente nos devolvía algo así:

Pero un día nos dimos cuenta que WhatsApp nos es capaz de representar por pantalla la codificación de algunos caracteres no imprimibles, por lo que el cliente sencillamente tendrá un crash cuando abramos alguno de estos mensajes. Esto implica que cuando el receptor intente abrir la conversación donde existe un mensaje de este tipo, el programa automática se cerrará, impidiéndole ver la conversación, por lo que finalmente tendrá que borrarla para recibir mensajes que sea capaz de procesar la aplicación (quizá has puesto un mensaje anteriormente del que te arrepientes y no quieres que finalmente vea :P).

Una muestra de lo que os estoy explicando la podéis ver en el siguiente mensaje:



He publicado el código necesario para enviar este tipo de mensajes en mi repositorio de GitHub, y en la sección de Proyectos de la página.

Necesitaréis tener instalado yowsup, una interfaz de línea de comandos que permite enviar y recibir mensajes de WhatsApp como un cliente de móvil, configurado con una cuenta válida, para poder enviar los mensajes.

Que os divirtáis }:)

jueves, 10 de abril de 2014

Más allá de Heartbleed y HTTPS


Como todos conoceréis, hace un par de días se hacía pública una vulnerabilidad sobre OpenSSL, una de las bibliotecas de criptografía más usadas, descubierta por uno de los expertos en seguridad de Google y la compañía de seguridad Codenomicon, que ha sido catalogada con el código CVE-2014-0160 y bautizada como Heartbleed, al estar vinculada a un error en la funcionalidad heartbeat de dicha librería.

Esta vulnerabilidad afecta desde la versión 1.0.1 (Marzo 2012) a la 1.0.1f (Enero 2014), y existen gran cantidad de sitios web que permiten comprobar si un sitio Web es vulnerable, como Heartbleed test page, creada por Filippo Valsorda.

Lo realmente preocupante es la extensión que ha podido y puede tener esta vulnerabilidad, ya que OpenSSL es utilizado, entre otros muchos, por servidores web como Apache o nginx, que de forma conjunta abarcan el 66% de los sitios activos en Internet (de acuerdo con la Encuesta de Netcraft sobre Servidores Web para Abril de 2014). Por otro lado, tambien tiene su punto entretenido, ya que es como jugar a una especie de ruleta rusa proque no sabes a ciencia cierta que se expondrá en los siguientes 64kb :)

Pero existe una parte que la gente parece que está obviando... OpenSSL también se utiliza para proteger servidores de email (SMTP, POP3 e IMAP), servidores de mensajería (XMPP), SSL VPNs, y muchos otros servicios.

Podemos localizar gran cantidad de servidores XMPP públicos, como por ejemplo aquí, con detalle de los diferentes servicios que prestan, algunos registran el tipo de autenticación etc. buscando a través de Google. 

Si prestamos atención a las listas, veremos que hay algunos que podemos deducir que podrían haber sido parcheados, fijándonos por el uptime que han sido reiniciados en los dos últimos días.

Utilizando las diferentes pruebas de concepto que han sido publicadas, no tardaremos en encontrar algún servidor XMPP con TLS activado que sea vulnerable a Heartbleed:

También se ha incorporado un módulo de Metasploit que permite comprobar la vulnerabilidad para SMTP/IMAP/POP3/XMPP dentro de su repositorio oficial.

Recordad que es posible que algunos de estos servicios hayan sido atacados en los últimos meses, por lo que el atacante podría haber tenido acceso a claves privadas, credenciales, información sensible de navegación sobre VPN SSL o direcciones de memoria y contenido para evadir mecanismos de mitigación, con los riesgos que ello conllevaría.

Debido a que la explotación de esta vulnerabilidad no deja rastro en los logs, será complicado averiguar si ha existido algún tipo de compromiso de forma retroactiva.

A partir de ahora, si queremos monitorizar los diferentes intentos de explotación de esta vulnerabilidad, podemos utilizar diferentes reglas de detección para:

Si quieres comprobar si tus servicios podrían estar afectados, puedes utilizar los módulos que se han publicado hasta el momento:

Muchos proveedores de servicio se han visto afectados después de la publicación oficial del aviso y las diferentes pruebas de concepto del ataque, por lo que no sería mala idea cambiar tus credenciales de acceso, por seguridad, si en los últimos días has estado utilizando sus plataformas:


Como hemos visto, Hearbleed no sólo puede afectar a nuestro servidor web 'seguro' }:)