Mostrando entradas con la etiqueta mensajeria. Mostrar todas las entradas
Mostrando entradas con la etiqueta mensajeria. Mostrar todas las entradas

05 noviembre 2013

Análisis forense preliminar de Snapchat

Mucho se ha hablado en este blog sobre las aplicaciones de mensajería para los smartphones y de los fallos de seguridad de las mismas.

No hace mucho tiempo leí este artículo sobre la aplicación de la que os voy a hablar a continuación, esta aplicación y cuyo nombre está en el título del Post es SNAPCHAT.

Podría deciros que SNAPCHAT no es más que otra aplicación de mensajería instantánea, pero no es así, el gancho que tiene dicha aplicación es que permite a los usuarios enviar imágenes, videos cortos o mensajes a través de sus smartphones. El remitente elige el tiempo que desea que su mensaje sea visible para la otra persona, con un mínimo de 10 segundos. Y después es eliminada del mensaje, vamos que desaparece. Pero...¿Desaparece totalmente?

Bien, pues ya os hacéis una idea de lo que hace la aplicación, no obstante en el artículo que menciono en los párrafos superiores, su uso entre adolescentes es para casos de sexting, así que como disponía de algo de tiempo libre me dispuse a instalarla en mi smartphone y ver si realmente cumplía su objetivo, pero eso sí, iba a ir un poco más allá en mi investigación.

Tras una primera prueba he de decir que realmente la aplicación cumple su objetivo, recibes una foto (es la prueba que hice) y al tiempo estipulado por el remitente de la misma ésta se borra.

Pues bien, aquí es donde entra mi curiosidad, y me acordé del principio de transferencia de Locard, que viene a decir en resumen "cada contacto deja un rastro", así que me puse manos a la obra.

He decir que la "mini" investigación está realizada sobre un terminal Android rooteado.

En primer lugar fué localizar la aplicación en el terminal, por regla general las aplicaciones que se instalan en terminales Android se almacenan en el directorio data o datadata (según versión).


Ya tenía localizada el directorio de la aplicación, así que para ver los datos que contenía de forma más cómoda me la descargué a un directorio de mi equipo:


Como podéis observar, he desplegado todo el contenido de los directorios para que os hagáis una idea de lo que contiene.


Mi primera intención, y en la consola antes de descargarla a mi equipo, fué dirigirme al directorio Files a ver si hay se almacenaba una copia de la imagen recibida, pero...Mi gozo en un pozo.

Mi siguiente paso fué abrir una de las bases de datos, las de google anaytics no me interesaban, así que abrí tcspahn.db. Tras indagar en la base de datos, la cual como podréis ver en la siguiente imagen, tiene unas cuantas tablas, personalmente me llamaron la atención las tablas "StoryImageFiles" y "StoryImageThumbnailFiles", pues dicho y hecho a por ellas :)

La primera tabla "StoryImageFiles" no contiene datos, al menos en mis pruebas, ya que son eliminados de la misma, pero la siguiente "StoryImageThumbnailsFiles" si como podéis ver:


No hay que ser un hacha, nos está diciendo en qué directorio hay almacenada una miniatura de la imagen, pues ya tenemos la evidencia :) (Volved a mirar la captura de los directorios), y he aquí la imagen que me remití en mis pruebas, las zapatillas de mi niña :) :


Comentar, que la miniatura se guarda con la extensión jpg.no-media así que hay que eliminar el no-media para que sea legible su visualización.

Mi investigación no quedo ahí, me propuse indagar algo más, el resto de tablas que componen la BBDD podemos encontrar información de números de teléfonos añadidos a la aplicación, quién te ha mandado un mensaje, a quién se lo has mandado, campos TIMESTAMP etc... y además, podríamos obtener información EXIF de la imagen recuperada. Además, en los ficheros XML, se puede ver la información de la cuenta de correo que se ha utilizado para crear la cuenta, aunque el resto de datos esté cifrada.

No he realizado pruebas con los videos ni ninguna otra, así que animo a otros investigadores a realizar sus propias pruebas, y quien sabe, quizás algun investigador con más conocimientos es capaz de obtener más datos.

Jesús Angosto (@jdangosto)
Leer más...

10 mayo 2012

Registra cualquier número en TU Me

La entrada de hoy pretende ser un resumen rápido desde el punto de vista de seguridad de la aplicación TU Me, presentada ayer por Telefónica para móviles iPhone y que se ha mostrado en Internet como la competencia de WhatsApp.

Detrás de TU Me se encuentra la compañía jajah, con sede en California pero origen israelí, está especializada en VoIP y fue adquirida por Telefónica en 2010. Por lo que parece, todo ha sido desarrollado fuera de España y sus sistemas también se encuentran en California.

Teniendo en cuenta la experiencia ganada de ver como funciona WhatsApp he comprobado algunos de los fallos que hemos encontrado y contado. En algunos casos los resultados son buenas noticias y en otros no.

El registro solo se puede hacer mediante la recepción de un SMS, sin posibilidad de recibir una llamada u otro método de validación, como ocurre con su amigo verde.


Cuando se introduce el número, se manda una petición https con ese número de móvil, TU Me responde por SMS un código pin de tan solo cuatro números para verificar que ese teléfono es de nuestra propiedad, ya que como último paso hay que introducirlo en la aplicación, para que sea nuevamente valido. El proceso tendría un esquema similar a esto:

Registro en TU Me

---------------------------------------------------------------------------------------------------------------------------
ACTUALIZACIÓN:
Lo comentado a continuación ha sido solucionado a las pocas horas de publicarse esta información en el blog.






----------------------------------------------------------------------------------------------------------------------------

Desgraciadamente el número de veces que se introduce el PIN no está controlado y con una herramienta como burp es muy fácil automatizar el proceso y registrar el número que queramos en unos minutos.


En otro orden de cosas, revisando el directorio de la aplicación y la base de datos de conversaciones que se almacena en el fichero Connect.sqlite, me he encontrado que guarda la geo localización de todos los mensajes. Aunque no sea necesaria ni se solicite. Una vez mandas tu posición, los siguientes mensajes también llevarán esta información. Con todo lo que ello implica. ¡No hemos aprendido!

Connect.sqlite (geolocalización)

La sorpresa, esta vez buena, ha sido encontrar que las imágenes compartidas no son públicas y requieren autenticación para acceder a ellas. Además de estar solo disponibles por SSL, a diferencia de WhatsApp que cualquiera puede acceder a ellas si conoce la ruta y se sirven sin cifrar.

Almacenamiento de imágenes en https://store.yarnapp.com

Intento de acceso a una imagen sin credenciales

También las conversaciones se hacen usando protocolos cifrados, por lo que será difícil encontrar herramientas del tipo WhatsAppSniffer.

De momento, ¡esto es todo!


Leer más...

25 mayo 2010

Seguridad en protocolos de mensajería

Pese al paso de los años y los nuevos conceptos que se van 'inventando', el chat mediante protocolos de mensajería sigue teniendo una amplia cuota de protagonismo en las actividades online.

Con la transición del PC en casa a los dispositivos de tipo portátil y smart*, pasamos de entornos 'seguros' a entornos potencialmente mas peligrosos como Wifis públicas o centros de trabajo, donde es realmente fácil interceptar comunicaciones.

Existen muchos mitos sobre 'que te pueden hacer' si haces login en el MSN o Gtalk desde un lugar donde haya ojos curiosos, por eso vamos a explicar como funciona cada protocolo y el tipo de riesgos potenciales de cada uno.

Empezamos por 'el rey':
MSN / Messenger

Sin duda el protocolo mas empleado y con mas cuota de usuarios en España. El protocolo MSN no es un protocolo estático, va mutando periódicamente y Microsoft va sacando actualizaciones en las que varia ligeramente su funcionamiento. Dado que sus internals no son públicos, toca 'reversear' y deducir como funciona. A día de hoy la última especificación de la que se cuenta con información es esta y la parte que mas nos interesa es la que concierne a como se realiza la autenticación.

A grosso modo:
  • El cliente lanza la petición de login al servidor MSN, 
  • El servidor MSN facilita un 'reto' (un montón de caracteres aleatorios para generar entropía) y un servidor 'de tickets'
  • El cliente envía el Login + Password + Reto mediante una conexión SSL al servidor de tickets y, en caso de ser válida, obtiene un ticket
  • El cliente envía ese ticket al servidor MSN


Una vez completada esta secuencia, el resto de la comunicación se realiza en texto plano sin codificación alguna

Gtalk (cliente oficial)

Como es bien sabido, Google para implementar su sistema de mensajería se ha decidido por una implementación basada en XMPP / Jabber. El problema es que Jabber aun siendo un protocolo estandarizado admite mil y una forma de hacer las cosas (algunas mas seguras, otras mas inseguras). En concreto, Google en su implementación ofrece como formas de hacer auth dos posibilidades, una llamada Google-Token (totalmente fuera de especificación y propietaria de Google) y otra basada en TLS. El cliente oficial, como es lógico, emplea Google-Token y ciertamente debilita mucho la seguridad del sistema. Funciona de la siguiente manera:
  • El cliente se conecta vía SSL a Google para hacer el auth
  • Google entrega un token al cliente
  • El cliente usa ese token como método de autenticación

Terminada esta fase, el resto de la comunicación va en texto plano

Gtalk (clientes XMPP / Jabber alternativos)

Si obviamos el cliente oficial de Google y nos decantamos por alternativas como Gajim o Pidgin (necesario si empleas una plataforma como Linux), la cosa cambia radicalmente. El método empleado está completamente basado en TLS.
  • El cliente inicia la comunicación con el servidor XMPP
  • Se negocia un túnel TLS
  • Se envían las credenciales
A partir de ahí toda la comunicación va cifrada

Facebook

Recientemente Facebook ha abierto su chat públicamente mediante una plataforma basada en XMPP / Jabber. Como ya decía anteriormente, las formas en las que se puede hacer auth en XMPP son increíblemente versátiles. En el caso de Facebook han optado por un método basado en Digest SASL. SASL es un protocolo ampliamente utilizado para autenticación en servicios como IMAP o SMTP. Para hacerlo aun mas divertido, SASL soporta tres modos de autenticación en función de la seguridad que se quiera aplicar. El primero llamado 'auth' únicamente sirve para intercambiar credenciales de forma segura basado en retos, el servidor genera una cadena aleatoria y el cliente debe responder con un hash de sus credenciales + el reto. El segundo modo 'auth-int' añade una capa de integridad añadiendo a cada intercambio un 'código de integridad' empleando HMAC. El tercero, 'auth-conf' añade a todo eso una capa de cifrado. ¿Cual método ha elegido Facebook? auth normal.

Después de eso la conversación continua en texto plano

Conclusiones

Una vez explicado como funciona cada protocolo, a modo resumen una tabla con los riesgos potenciales que podemos sufrir si una sesión de chat es interceptada.

Los criterios de evaluación han sido

[ ] Crackeable: La posibilidad de que un atacante que capture la autenticación pueda aplicar fuerza bruta sobre lo interceptado para averiguar la contraseña
[ ] Usuario deducible: Se evalúa si durante la fase de autenticación un atacante podría averiguar el login / dirección de correo ej: fulano@hotmail.com
[ ] Sniffing conversación: El hecho de que los mensajes de chat intercambiados sean susceptibles de leerse en texto plano

** En el caso de Gtalk solo se contempla en formato 'cliente alternativo'


Leer más...