Whatsapp & Facebook ¿Crees en las Casualidades?

Hace ya unos días que al cerdito de barro que utilizo de hucha no le entran mas monedas. Tengo la costumbre de que cuando tomo un café, pago con una moneda de dos euros o con una moneda de un euro y otra de cincuenta céntimos de euro, lo que suelo llevar en los bolsillos, normalmente los cafés me cuestan entre 1,1€ y 1,4€, así que me suelen dar la vuelta en monedas de 20 y 10 céntimos. Luego esas monedas (las de 20 y 10 céntimos) siempre las echo a mi cerdito hucha, nunca las gasto en otras cosas, así cada día que tomo café, así durante muchos meses y muchos cafés. ¿Para qué hago esto?, os estaréis preguntando, muy sencillo, cada vez que se llena la hucha, la vacío y dono todo ese dinero a la causa que mejor me parezca, al día no me supone mucho dinero, pero con el paso de los meses al final se llega a juntar dinero, casi 4 kilogramos de monedas en esa ocasión.

Fig. Babe, el cerdito de barro.

El problema está en que por muy buena que sea mi intención, si voy con cuatro kilos de monedas a cualquier organización para donárselas, las van a recibir gustosamente, pero les vas a suponer un trabajo contarlas e introducirlas en blísteres para poder ingresarlas en el banco, trabajo y tiempo que es mejor que dediquen a realizar otros menesteres. Por eso, normalmente lo que hago es meter las monedas en blíster y entregárselas ya contadas y empaquetadas para ahorrarles trabajo. Problema: yo no dispongo de blísters, por eso le envié un mensaje por Whatsapp a un amigo para que me consiguiera unos cuantos blisteres, para ser exactos necesitaba: 15 blísteres de monedas de 20 céntimos de Euro y 10 blísteres de monedas de 10 céntimos.

Fig. Mensaje reenviado desde Whatsapp

Si os estáis preguntando si previamente he tenido que contar cuatro kilos de monedas para saber exactamente cuántos blíster voy a necesitar, no es necesario, hay una solución más sencilla: “las matemáticas son tus amigas“. Simplemente sabiendo que una moneda de 20 céntimos pesa 5,74 gramos y una de 10 céntimos pesa 4,10 gramos, solo tenemos que separarlas y pesarlas, luego dividir el peso total por el unitario, y ya sabremos el número de monedas aproximadas que tenemos de cada tipo.

Fig. Peso de un blister con monedas de 20 céntimos.

A los pocos minutos de haberle enviado el mensaje a mi amigo por Whatsapp con el número y tipo de blísteres de monedas que me tenía que conseguir, accedo a la aplicación Facebook de mi teléfono móvil y me encuentro con un anuncio de Amazon, en el que aparece un contador de monedas automático. Quizás puede parecer este un hecho sin la mayor importancia, pero teniendo en cuenta una serie de detalles que voy explicar a continuación sobre el funcionamiento del cifrado extremo a extremo (end to end encryption) de Whatsapp y la arquitectura de los sistemas operativos Android, esto no debería haber podido ocurrir nunca, ya que estaría contravenido absolutamente las políticas de uso de esta aplicación, a no ser claro está, que todo ello fuera fruto única y exclusivamente de la casualidad. Casualidad en la que justamente la publicidad que Facebook me muestre a los pocos minutos de haber hablado por Whatsapp sobre blísteres de monedas, sea un producto tan extraño y concreto como un contador automático de monedas. Un contados de monedas automático no es el típico producto que se muestra en los anuncios de Facebook… ¿tú qué crees?.

Fig. Anuncio de Facebook del contador de monedas

Cada cual después de haber leído este artículo, tendrá que valorar en su yo interior cual es la explicación más lógica o razonable para explicar lo que ha ocurrido. Yo no sé lo que ha ocurrido, solo sé lo que no ha podido ser y esto exactamente es lo que voy a explicar a continuación.

Volviendo a la situación anterior, el caso es que a mi amigo, realmente no le envié un mensaje por Whatsapp escrito por mí, con los blíster de monedas que me hacían faltan, lo que hice es reenviarle el mismo mensaje que le había enviado semanas antes para recordarle el número exacto de blísteres que necesitaba. La diferencia no es pequeña. Si le hubiera escrito el mensaje ese mismo día, existiría la posibilidad de que el teclado que utiliza mi teléfono móvil estuviera enviado parte de lo que escribo a sus servidores centrales para tratar esa información. Por ejemplo, el caso del teclado de Google para Android (GBoard), necesita enviar a Google parte de los textos que el usuario escribe para que las funciones de autocompletar o escritura por gestos funcionen óptimamente. Si nunca te has parado a pensar en el que el propio teclado de tu teléfono es una aplicación independiente que tiene acceso a todo lo que escribes, quizás ahora sea un buen momento para tomar en consideración este detalle.

Fig. App Gboard de Google

Pero como decía: el hecho de que Facebook me muestra publicidad sobre algo que he “dicho” por Whatsapp tiene que tener una explicación. En este caso se puede descartar que la “filtración” de datos pudiera estar relacionada con el teclado de mi teléfono, ya que el mensaje con el número de blísteres que necesitaba, realmente no lo he llegado a escribir con la aplicación del teclado, para enviarlo usé la opción de “Reenviar” que dispone Whatsapp, de este modo el teclado no opera, puesto que esta función de Whatsapp no hace uso del portapapeles del teclado, si no que, queda todo el proceso de reenvío dentro del propio Whatsapp. La opción del teclado: descartada.

Fig. Detalle del reenvío de un mensaje por Whatsapp

Otra opción es que sea la propia aplicación de Whatsapp la que estuviera enviando estos datos a sus servidores para ofrecer un servicio de publicidad orientada a sus usuarios. Esto se podría hacer de dos modos:

El primero, sería que existiera un proceso en la aplicación de Whatsapp que de forma automática enviara estos datos a dónde quiera que los tuviera que enviar. Podría ser posible (al menos técnicamente), si no fuera porque en Android las aplicaciones se instalan en un ejecutable en formato “APK(Android Application Package), este APK no deja de ser un contenedor (ZIP) en el que se almacena el código fuente o de programación de la aplicación compilado en JAR (Java Archive). Los JAR se pueden decompilar. Por ejemplo con la herramienta libre apktool, podríamos “abrir” una aplicación de Android y leer el código de programación que el diseñador escribió, con sus manifest, res, assets, etc… Lo que significa que se puede ver/auditar el código de programación de una app para comprobar si se ha programado para que realice alguna tarea “oculta”, por ejemplo, el famoso caso de la linterna espía, una app de linterna que realmente su código de programación incluía todo tipo de estratagemas para espiar a los usuarios que la usaban. Whatsapp con cerca de 1.500.000.000 usuarios en todo el mundo, si no es la que mas, es una de las aplicaciones mas auditadas y analizadas por expertos de ciberseguridad en todo el mundo, por no hablar de las versiones para beta testers. Si Whatsapp tuviera una sola línea de código malicioso, no tardaríamos mucho tiempo en averiguarlo. Esta opción, aunque sea por sentido común, también se podría descartar.

Fig. Apktool

El segundo modo, sería que otra aplicación, por ejemplo Facebook, pudiera acceder a la base de datos de conversaciones que Whatsapp almacena dentro del teléfono sin cifrar. Whatsapp, por defecto, en la actualidad almacena la base de datos con las conversaciones de cada usuario en dos sitios distintos. Todos los días a las 2:00 AM Whatsapp genera un backup de todas las conversaciones almacenadas hasta el momento, las cifra, y o bien las sube a un almacenamiento en la nube de Google Drive (método actual) o las guarda en el almacenamiento compartido del teléfono (por ejemplo la tarjeta MicroSD). En este punto podríamos llegar a pensar que este cifrado no es lo suficientemente robusto y cuando se sube la copia de seguridad de nuestras conversaciones a la nube de Google Drive, Google tiene la capacidad de descifrar el fichero y leer nuestros chats, aunque esto fuera posible, en este caso concreto tampoco se podría aplicar, ya que la conversación en cuestión se mantuvo a las 21:00 horas, y la copia de seguridad no llegaría a los servidores de Google (cifrada) hasta las 02:00 horas del día siguiente. Descartado también.

Fig. Backup de Whatsapp

Hemos estado hablado de la base de datos cifrada que hace la función de copia de seguridad, pero Whatsapp dispone de otra base de datos (la de verdad), la que está utilizando en producción para ir almacenando los distintos mensajes que se van generando. Como esta base de datos no está cifrada de ningún modo (es una fichero SQLITE llamado msgstore.db), podríamos pensar, ahora sí, que Facebook accede a este fichero SQLITE con la base de datos de Whatsapp y lo va consultando según sea necesario. Pues tampoco, resulta que las aplicaciones en Android, se ejecutan en una maquina virtual llamada Dalvik, esta máquina es independiente y aislada por cada app, además, el espacio reservado para cada una de las aplicaciones está protegido por una contraseña distinta por app, en el caso de Whatsapp, la base de datos se encuentra almacenada en la ruta: /data/data/com.whatsapp/databases/, ruta que solamente es accesible únicamente por el usuario creado por Android para ejecutar la aplicación Whatsapp (cada app en Android opera con un usuario/contraseña distinto). Entonces si las aplicaciones están totalmente aisladas ¿Cómo es posible que por ejemplo Whatsapp puede acceder a los contactos o Facebook pueda compartir información con otra app?, esto es posible gracias a los “Content Provider“, un mecanismo proporcionado por Android que nos permite compartir información entre diferentes aplicaciones, pero solo la información que hemos autorizado (¿Os suena lo de los permisos de Android?), en este caso, ninguna otra aplicación tiene acceso a los datos de conversaciones de Whatsapp.

Fig. Distintos usuarios en Android

La única excepción sería un móvil rooteado, rootear un móvil no es otra cosa que activar el usuario “Super Administrador“, deshabilitado por defecto en la mayoría de los teléfonos. Si activamos este usuario en nuestro smartphone, sería el único que puede acceder al contenido del resto de usuarios del sistema y por lo tanto acceder al fichero msgstore.db (Conversaciones de Whatsapp) y leer su contenido, de ser así, este artículo no tendría sentido alguno. Pero no, el smartphone en cuestión no ha sido rooteado, es más, opera con una versión “pura” de Android.

Fig. Usuario root en Android

Ahora llega el momento de hablar del punto más controvertido de todo esto, hasta ahora hemos estado hablando de la comunicación en uno de sus estados, cuando los datos de chats se encuentran almacenados en nuestro dispositivo (bases de datos estáticas). Pero existe otro estado de los datos, este estado lo encontramos cuando los datos se encuentran en tránsito de un dispositivo a otro, es decir, del emisor al receptor. Si estos datos no viajan cifrados, o no lo suficientemente cifrados, alguien los podría interceptar y leer/ver nuestras conversaciones a través de Whatsapp. En el caso de Whatsapp, desde hace ya unos años se implementó el cifrado extremo a extremo, una tecnología que permite enviar un mensaje a otro usuario, de tal forma que ninguna otra persona conozco las claves de descifrado del mensaje a excepción del destinatario (ni el emisor las conoce). Esto se consigue gracias a la implementación del protocolo criptográfico Diffie-Hellman en Whatsapp y la tecnología Signal.

Fig. Croquis Diffie Hellman

Este protocolo se basa en las matemáticas (la teoría dice que son grupos de enteros multiplicativos módulo p, con p primo). Para que nos entendamos, se basa en la propiedad matemática en la que es fácil operar un número A con otro B para que salga C, (50×30=1500) pero a partir de c (1500) es muy difícil saber qué números A (50) y B (30) lo han generado. Obviamente el protocolo no se aplica con una operación de multiplicación, es un simple ejemplo para hacerlo entendible, además se deben utilizar números primos suficientemente elevados. De este modo, cada usuario (realmente el proceso lo realiza Whatsapp de forma transparente para el usuario) crearía su propia clave pública y privada, la privada la custodiaría y la pública se la enviaría a la persona con la que quiere hablar (B), la persona con la quiera hablar (B) cifra el mensaje con la clave pública que le han enviado y cuando le llegue a la primera parte (A) el mensaje cifrado con su clave pública, solamente la tiene que descifrar con su clave privada (la de A). En este esquema, los servidores de Whatsapp nunca tendrían acceso al contenido de los mensajes enviados por cada usuario, siempre y cuando, no tengan acceso a su clave privada, extremo que según sus términos y condiciones, exponen que no es posible ¿o sí?.

Fig. Anuncio de cifrado en Whatsapp

Así que a estas alturas de la “película”, solo puede decir: ¿y tú?, ¿crees en las casualidades? Si todavía no lo tienes claro, puedes seguir leyendo un poco más.

A raíz del tuit que publiqué hace unos días en el que os contaba lo que ahora estoy explicando más detalladamente en este artículo, varios de mis “seguidores” en Twitter comprobaron por si mismos si esto que estaba contando podía ser real o no. Aquí os dejo dos tuits de @TheCybertus y @menektoni en los que comparten con todos nosotros las pruebas que han realizado con el tránsito de datos confidenciales entre conversaciones de WhatsApp y anuncios en Facebook.

Pruebas de @TheCybertus
Prueba de @menektoni

Os animo a que seáis vosotros mismos quien probéis en vuestros propios smartphones esto que os estoy contando. Podéis enviar un mensaje de WhatsApp a un conocido vuestro comentando que necesitáis un producto concreto y extraño, luego solo tendréis que revisar vuestra aplicación de Facebook o Instagram a ver si os muestra algún tipo de anuncio relacionado.

No me gustaría que os quedarais con la idea de qué este puede ser el típico artículo conspiranoico en el que todos somos espiados, nada más lejos de mi intención. Simplemente busco con este artículo contar un suceso que me ha ocurrido tanto a mí cómo a otras personas, suceso al que difícilmente se le podrá buscar explicación sin involucrar al cifrado extremo a extremo de WhatsApp.

Tinder, cuando haces Match, no hay STOP.

Hoy os traigo un artículo un tanto distinto, pero no distinto por la temática del mismo, distinto por la aplicación que vamos a “trinchar”. Posiblemente ya os imaginareis por el título del artículo, que hoy va a pasar por el bisturí y la mesa de autopsias de GLIDER la aplicación para smartphones: Tinder. Como seguro que nadie conoce esta aplicación 😉 , os explico brevemente para que sirve. Tinder básicamente es una aplicación de citas o contactos, cada usuario crea un perfil con su descripción: nombre, foto (normalmente sugerente), edad, estatuara, empleo… y todo (todo) lo que quiera dar a conocer para ser mas “matcheable”.

Fig. 1 Match en Tinder by mashable.com

El tema de los match es muy sencillo, el usuario al darse de alta indica que es lo que busca: (hombres, mujeres, bi), edad del candidato/a y distancia en kilómetros a su posición actual. Por ejemplo podemos configurar Tinder para que nos muestre mujeres de entre 35 a 40 años, interesadas en hombres y que se encuentren en un radio de 30Km de nuestra posición. Lo de configurar la distancia es una autentica declaración de intenciones… no dejes para mañana lo que puedas hacer hoy. Configurado todo, en este caso, al usuario le irán apareciendo candidatas y este en base a la foto y su bio indicará si le gusta o no le gusta cada una de ellas, a la candidata también se le mostrará de forma aleatoria el usuario, si esta también hace match, ambos podrán chatear entre sí, si no hay match mutuo, nunca podrán hablar entre ellos. Lógicamente, a mi todo esto me lo han contado, yo no uso esta aplicación. De hecho, no hay muchas personas que confiesen que usen esta aplicación, pero la realidad es bien distinta, si nos vamos a las estadísticas de Google, Tinder ha sido descargada por más de 100 millones de usuarios en todo el mundo, y esto solo en Android.

Fig. 2 100 millones de descargas

Cierto es, que tengo algunos amigos y amigas, que me cuentan que usan esta aplicación simplemente para conocer a gente, sin mayor intención que esa, en este momento es cuando se me viene a la cabeza el anuncio de la App Chicfy, que decía algo tal que: “Claro que sí….” bueno, sea como fuere, el caso es que nosotros somos forenses y nuestra finalidad ha de ser obtener datos y evidencias empíricas de un vestigio, nada de valorar el motivo por el cual alguien decide instalar o usar una aplicación concreta en su móvil.

Fig. 3 CLARO QUE SÍ, GUAPI

Como es costumbre en cualquier sistema Android, los datos de las aplicaciones que tenemos instalados en nuestro smartphone se encuentran en la ruta “/data/data”, en este caso estamos analizado la app Tinder, tan solo tendremos que dirigirnos a la ruta “/data/data/tinder” para extraer toda la información de esta aplicación. Existen varias formas para obtener estos datos, hoy me voy a decantar por ejecutar un elegante “adb pull” para traerme todo el directorio de la aplicación a mi ordenador de análisis. Como es habitual, podemos tener problemas con los permisos de los ficheros a los que estamos accediendo a través de ADB, una buena solución es comprimir todo el directorio en .ZIP, para posteriormente “descargar” el fichero .zip el cual hemos creado desde ADB. De este modo no vamos a tener ningún problema con nuestros privilegios de usuario.

Fig. 4 adb pull al zip

Ya con el fichero .ZIP en nuestro equipo forense (en este caso un sistema Linux) descomprimimos la extracción y comprobamos que contiene una estructura con todas las carpetas y ficheros que ha generado la aplicación Tinder. Para este articulo me voy a centrar exclusivamente en cuatro directorios clave: databases, shared_prefs, app_webview y cache.

Fig. 5 Contenido de la carpeta extraída

La primera carpeta que vamos a “trinchar” será la denominada: “shared_prefs”. En ella hay un fichero de texto llamado: “appsflyer-data.xml”, en el que podemos encontrar y por lo tanto determinar, cual es el género con el que el usuario se ha registrado (hombre, mujer…), la localización GPS de su posición, su edad (la que haya puesto, que ya sabemos lo que pasa en estas apps), la versión de Android con la que está operando Tinder, el nombre del usuario, en este caso: “manu” (usuario para pruebas), marca y modelo del teléfono móvil y por último la compañía telefónica. Esta información nos puede resultar de interés si resulta que alguien se ha hecho pasar por quien no debe.

Fig. 6 fichero appsflyler

En el fichero “LastActivityDatePreferencesRepository_last_activity_date.xml”, encontraremos un registro con la fecha y la hora en la que se utilizó/abrió por última vez Tinder en ese teléfono en concreto. “– Nah, yo tengo el Tinder pero no lo uso…

Fig. 7 Información con timestamps

Otro de los ficheros que encontraremos en la carpeta “shared_prefs”, es el fichero “sp.xml”, el cual, entre otros datos, contiene el User Agent concreto con el que opera la aplicación Tinder. Este dato se podría llegar a utilizar como un fingerprint o huella digital de la navegación web que se ha realizado desde el propio Tinder.

Fig. 8 User Agent

De nuevo, en el fichero “sp.xml”, tambien podremos determinar la geoposición del usuario a través de unas coordenadas GPS. Que Tinder necesite registrar en varios sitios la geoposición del usuario es normal, ya que según dicen, yo nunca lo he probado, para buscar a otros usuarios/as es necesario estar físicamente cerca de su posición, o al menos que el GPS crea que está cerca de una posición.

Fig. 9 Información de ubicación

El fichero xml “com.tinder_preferences”, en principio no tiene demasiados datos relevantes, a excepción de dos timestamps, el: “SESSION_APP_START” con la fecha en formato epoch del momento en el que se inició la aplicación, y la variable “SESSION_APP_END”con la fecha en la que se cerró la sesión. De este modo se puede llegar a determinar el tiempo que la aplicación/sesión permaneció abierta.

Fig. 10 fechas de las sesiones

Como sabréis, yo no, se puede iniciar sesión en Tinder con una cuenta de Facebook, eso sí, ya os anticipo que no es buena idea mezclar Tinder y Facebook si lo que buscáis es tener una cuenta de Tinder “undercover”. En el fichero “com.facebook.loginManager.xml”, queda registrado si el login de Tinder es mediante una cuenta de Facebook o no.

Fig. 11 Vinculación a Facebook

Es el turno de analizar la segunda de las carpetas, en el directorio “app_webview/…/leveldb”, encontraremos un fichero llamado “LOG”, que como su propio nombre indica es un pequeño registro de tareas de la aplicación. No vamos a entrar en lo que significa cada uno de los registros. Desde el punto de vista del análisis, es interesante saber que en este fichero podemos encontrar un registro tipo timestamp de “cosas” que hace la app Tinder, y si hace “cosas” es que está abierta, o lo que es lo mismo, es otra forma de contrastar o determinar si esta aplicación en un momento dado estaba abierta.

Fig. 12 Ficheros de log

Subiendo un nivel a la ruta: “Web Data”, encontraremos una base de datos muy curiosa, o mejor dicho, un tabla. En la tabla “unmasked_credit_cards”, podremos localizar las distintas tarjetas bancarias que el usuario vinculó a la aplicación para poder realizar pagos. Resulta, que según me han dicho, si no se es muy ducho/a en los temas del amor, existe la posibilidad de pagar cierta cantidad de dinero a Tinder y de este modo entras en una especie de modo “pro” o “turbo” para lograr más “matchs” en menos tiempo.

Fig. 13 Datos bancarios

La tercera carpeta que vamos a analizar en este artículo se llama “cache/image_manager_disk_cache”. En ella habrá un fichero de texto llamado: “journal” que contiene una serie de líneas con un “string/hash” suficientemente largo como para que no pueden existir duplicidades. Además cada línea termina con un número aparentemente aleatorio. SPOILER: No es un número aleatorio, es el tamaño en bytes del fichero al que hace mención.

Fig. 14 Journal

Resulta que en ese mismo directorio existen otro tantos ficheros como líneas que contiene el fichero: “image_manager_disk_cache” y con el mismo nombre, por supuesto, también con el mismo tamaño al que se hace mención en el fichero de “journal”. Básicamente el fichero “jourunal” es un listado con los nombres y tamaño de todos los ficheros almacenados en esta carpeta.

Fig. 15 Caché

En un primer momento estos ficheros nos pueden parecer “garbage”, pero si abrimos cualquier de ellos con un editor hexadecimal pronto veremos que todos comienza con el mismo patrón: xFF xD8, o lo que es lo mismo, la cabecera hexadeciamal de un fichero de imagen tipo JPG. Lo que significa que estos ficheros son imágenes sin extensión, por lo que las podremos visualizar con cualquier visor de imágenes. Esto nos permitirá determinar si el usuario en algún momento ha visto el perfil de la otra persona.

Fig. 16 Cabecera hexadecimal de los ficheros

Para terminar esta primer parte del artículo sobre Tinder, analizaremos quizás una de las carpetas más importantes de esta aplicación, la carpeta “databases” dónde se almacenan todas las bases de datos de la aplicación. Como es habitual en este tipo de aplicaciones, las bases de datos se operan en ficheros del tipo SQLite, por lo que solamente necesitaremos un visor compatible con estas bases de datos para poder leer todo su contenido. A grandes rasgos, una base de datos SQLite es como un fichero en “Excel”, contiene tablas, y cada tabla contiene: columnas y filas, cuya intersección es una celda. Comenzaremos analizando la base de datos “Tinder-1.db

En la tabla “photos_processed”, de la base de datos “legacy_tinder-1.db”, encontraremos las fotos del usuario que está utilizando en la aplicación. Si nos fijamos, la ruta de la imagen no es local, si no que apunta a una URL de Internet.

Fig. 17 Foto subida públicamente

En ese caso vemos hasta cuatro URLs distintas, esto no significa que el usuario de Tinder tengo subidas cuatro fotos de perfil, si no que es la misma imagen pero en cuatro tamaños distintos: 84×84; 172×172; 320×320 y 640×640 pixeles. Resulta curioso que podamos ver la imagen del usuario tan solo con la URL, sin necesidad de estar logados en la aplicación, ni tan siquiera es necesario tratar de ver la fotografía desde un smartphone, desde cualquier navegador la imagen es visible.

Fig. 18 DB photos

Antes de alarmarse pensado que las fotos de Tinder pueden ser tan fácilmente accesibles por un tercero, hay que tener en cuenta que la URL es lo suficientemente compleja para que no sea tarea sencilla poder hacer fuerza bruta contra las posibles combinaciones de URLs.

Existe otra tabla llamada “photos”, en esta tabla podremos encontrar la misma foto anterior, pero sin redimensionar.

Fig. 19 Foto principal del usuario

Finalmente, en la tabla “user” de la DB “legacy_tinder-1.db”, podremos encontrar los datos del usuario, datos como: fecha de nacimiento en epoch (1 de enero de 1970); distancia (en millas) que el usuario ha indicado en la aplicación para localizar a otros usuarios; género; nombre; bio; si es un superuser (ha pagado); intereses y número de teléfono, entre otros datos personales.

Fig. 20 Información de usuario

Vamos a cambiar de base de datos, ahora le toca a la DB: “tinder-3.db”, dónde podremos encontrar información diversa. Por ejemplo en la tabla “gif”, como su propio nombre indica podremos ver los gif que el usuario ha enviado.

Fig. 21 Información de los gif

No hay que olvidar que este análisis de la aplicación Tinder lo estoy realizando sobre un sistema Android, para iOS (Apple) funcionará todo igual, a excepción del nombre de las bases de datos que suelen comenzar por el carácter “Z”, como por ejemplo: ZMESSAGE; ZUSER; ZPROCESSEDPHOTO; Z_5SHAREDFRIENDS

Y ahora viene lo más importante de todo: ¡los casos de éxito!. En la tabla “match” veremos un listado con todos los match que el usuario ha conseguido, en este caso solo han sido dos (para evitar suspicacias comentar que ningún usuario real ha interactuado con el perfil simulado creado para este análisis). Gracias a esta tabla podremos determinar la fecha del match y el ID del usuario/a con la que el usuario ha logrado hacer match.

Fig. 22 Casos de éxito

Ahora que sabemos que el usuario ha logrado conseguir dos matchs, podremos ir a la tabla: “match_person” para ver la información personal de los usuarios con los que el usuario analizado ha hecho match, podremos ver: ID del usuario, nombre de usuario y fecha de nacimiento entre otros datos.

Fig. 23 Listado de matchs

Finalmente, si ha habido un match, ¿qué habrás después?, pues lógicamente una conversación. Tinder dispone de un sistema de chat integrado, el cual solamente se pude usar con los contactos con los que el usuario hubiera conseguido un match. Antes de continuar, me gustaría aclarar que los mensajes que a continuación se describen los he creado de forma artificial entre dos cuentas de Tinder controladas por mí, tampoco es cuestión de crearle exceptivas falsas a ningún usuario de esta red social hacía un usuario que en la vida real no existe. Podremos consultar todas la conversaciones del usuario con otros usuarios en la tabla “messages”. Veremos datos como las ID de los distintos usuarios, fecha de envío, el identificador del match y por supuesto, el texto del mensaje en sí.

Fig. 24 Chats

En este artículo no he hablado de todas las bases de datos, ni de todos los ficheros con los que trabaja la aplicación Tinder, simplemente he comentado los que a mi criterio me parecen más interesantes, si tienes que realizar un análisis forense sobre esta aplicación te recomiendo que no te quedes solamente en las bases de datos que he comentado y que trates de profundizar un poco más en el resto de ficheros. En la siguiente parte de este artículo seguiremos comentados otros lugares de los que poder obtener datos de interés en esta aplicación tan conocida, o no.

OK Google ¿Me estás espiando?

-OK Google, dime cual es el próximo Ave a Madrid”. Aquí estoy, en la estación de tren de Madrid-Atocha, tomando un café con leche mientras espero al tren que me llevará a casa después de una intensa semana de formación, ha sido una semana de Análisis Forense de telefonía móvil con el curso FOR-585 de SANS: “Smartphone Forensics in-depth”.

 


Fig. SANS 585 Challenge coin.

 

Como suele ocurrir en estos cursos, la carga lectiva es muy importante, pero no menos importante que las pausas para café, pausas que te permiten intercambiar opiniones, puntos de vista e ideas con otros compañeros de profesión, tanto de empresas privadas como de otras organizaciones. En uno de esos cafés, fue cuando surgió este artículo, un compañero del curso nos mostró la noticia sobre los dispositivos Alexa y de como supuestamente “Los empleados de Amazon escuchan todo lo que le decimos a Alexa y además saben dónde vivimos”, bueno, ese era el titular. Alguien que sepa un poco como funciona esto del reconocimiento de voz, ya se imaginará por “dónde irán los tiros”. No seré yo quien ponga la mano en el fuego por ninguna compañía de este tipo, pero tampoco es cuestión de vender una imagen de espionaje, desde mi punto de vista, irreal.

 


Fig. Momentos de relax.

 

¿Y cual es la realidad?, en estos tiempos vivimos en una realidad paralela, dos afirmaciones distintas pueden ser ciertas y falsas al mismo tiempo, todo depende del enfoque que le demos en la exposición. La noticia de Alexa no iba a ser menos, tampoco voy a escribir un artículo explicando lo que hace o deje de hacer esta compañía con la información que tenga que gestionar, pero la cosa es mas o menos así: básicamente los sistema de reconocmiento de voz como: Alexa, Google Home, Siri, etc… Necesitan depurar sus fallos en el reconocimiento de voz, es decir, cuando le decimos una frase al dispositivo y este no es capaz de interpretarla, ese audio se envía a un equipo concreto de personas que deben interpretarlo (mas allá de transcribir literalmente lo que el usuario dijo, tendrán que comprender lo que el usuario quiso decir) y enseñarle a la aplicación como hacerlo, así, la próxima vez que algún usuario vuelva realizar la misma petición, esta se gestionará correctamente. De este modo la aplicación sabrá interpretar lo que le están diciendo, lo que viene a ser una depuración de código de toda la vida. – ¿Y que tiene que ver Alexa con este artículo?, en realidad nada, pero así fue como surgió este articulo sobre Google Home y así os lo cuento.

 

Fig. Google Home Mini.

 

Hace ya unos meses que me compré un Google Home modelo Mini. En realidad mi intención, como es habitual, no era hacer un uso real del dispositivo, lo compré para realizar un análisis forense sobre el mismo. Estaba, estoy y estaré convencido, que este tipos de dispositivos domésticos del tipo: Internet of Things serán el futuro del análisis forense informático. Lo mismo que nos pasó con la telefonía móvil hace 10-15 años, nos pasará con el IoT, por eso, cuanto mas podamos aprender y entender como funcionan estos dispositivos a nivel forense y mas rápido seamos capaces de hacerlo, será lo que llevemos de ventaja cuando tengamos que realizar análisis exhaustivos y masivos de estos dispositivos. Ese día llegará. Seguir leyendo

Tor Forensics Advanced. Part 2

Aquí estoy de nuevo, después de un pequeño parón para poder dedicarme a otros quehaceres, vuelvo a retomar GLIDER.es justo dónde lo dejé, hablando de lo que más me gusta, de análisis forense informático, en este caso, hablando de análisis forense en TOR. En la primera parte de este artículo: “TOR Forensics I”, os contaba todos los artefactos forenses que podemos extraer del navegador Tor Browser, ya que este no es otra cosa que un Mozilla Firefox modificado. Sin embargo en esta segunda parte, un poco más avanzada y técnica, os voy a hablar en primer lugar del resto de artefactos forenses que nos podemos encontrar cuando se ejecuta el navegador Tor Browser, ya sea en un sistema Linux o Windows, artefactos como por ejemplo los ficheros de configuración de Tor, así como los vestigios que Tor puede dejar en la memoria RAM.


Fig. 1 Tor Forensics II

 

Como ya comenté muchas veces, Tor no es solo un cliente, es decir, un sistema para conectarnos a un lugar. Ese lugar al que nos conectamos también formará parte de la red TOR y de ello también os voy a hablar en este nuevo artículo, comentando toda la información forense que se puede extraer de un servidor que se ha utilizado para ofrecer un servicio a través de la red Tor.

Comenzaremos hablando por un fichero bastante importante en lo que a forense en Tor Browser se refiere, este es el fichero: “state”, el cual nos permitirá determinar los distintos bridges que el navegador Tor Browser ha usado, así como sus direcciones IP (¡OJO! Estas no son las direcciones IP públicas del usuario), de forma indirecta podremos averiguar cuando fue la última vez que se escribió este archivo, o lo que es lo mismo, la última vez que se inició Tor Browser en ese equipo, ya que para que Tor Browser puede conectarse a la red, tiene que tener actualizado este fichero.

 


Fig. 2 Actualización del fichero “state”

 

Otro dato importante del fichero “state” es la versión de Tor con la que se está operando (No confundir con la versión del navegador Web). Normalmente, podremos encontrar este fichero en la ruta de instalación de Tor Browser: “/Browser/TorBrowser/Data/Tor/state” (Linux o Windows)

 


Fig. 3 Versión Tor

 

Es importante distinguir a la hora de realizar un análisis forense sobre Tor: Tor Browser (el Mozilla Firefox modificado) de lo que es la red Tor en sí (sistema de servidores y enrutadores que nos permite acceder a los distintos nodos y servicios que nos ofrece esta red). Lógicamente, una cosa necesita de la otra, pero son independientes al a hora de realizar el análisis.

 


Fig. 4 Versión Tor Browser

 

Que en la primera parte de este artículo, hubiera nombrado una serie de bases de datos y ficheros, no significa que solo sean estos los ficheros que pueden ser interesantes a nivel forense. He reseñado los que desde mi punto de vista pudieran ser interesantes, pero para poder realizar un análisis en profundidad de este navegador es necesario realizar un trabajo pormenorizado con cada uno de los ficheros que nos podamos encontrar durante el análisis, ya que en caso de que se actualice el navegador o el sistema Tor, estos artefactos pueden modificarse y dejar de proporcionar la información que ahora nos dan, o también que simplemente pase a almacenarse en un lugar distinto al ahora explicado.

 


Fig. 5 Aviso de actualización de Tor Browser

 

Pero… – ¿Que es lo que no nos podemos olvidar de analizar en un artículo de este tipo?, eso es, – ¡La memoria RAM!. Como ya dije al principio de este artículo, TOR Browser, está pensado para enrrutar tráfico a través de la red Tor, pero no está pensado para ofrecernos anonimato mas allá de lo que es la propia red, por lo que a nivel forense, podremos aplicar técnicas usables en cualquier otro navegador, como por ejemplo el análisis de RAM. No os voy a contar como capturar la RAM de un equipo, ya que lo he explicado en otros artículos anteriores. Tampoco hablaremos de Volatility, la navaja suiza del análisis de memoria RAM, hoy vamos a ser un poco mas artesanales, tan solo utilizaremos dos herramientas para realizar este análisis de RAM, un “grep” y un “uniq” (comandos de Unix) . ¡Vamos a ello!. Seguir leyendo

TOR Forensics. Part 1

En este nuevo artículo de GLIDER.es os quiero mostrar otro punto de vista sobre TOR. Hasta ahora había hablado de TOR desde el punto de vista de la red, es decir, del enrutamiento de comunicaciones a través de la red onion. Pero hoy voy hablar sobre Tor Browser, es decir, uno de los navegadores web mas usados a la hora de acceder a la red TOR. En primer lugar es importante reseñar que no es lo mismo la red TOR, que el navegador TOR. Algunas veces escuchamos que alguien es usuario de la red TOR por usar el navegador Tor Browser, esto realmente no es así, el navegador es simplemente un medio para poder conectarnos a esta red. En realidad el navegador Tor Browser es un navegador Mozilla Firefox, modificado para que se puede conectar a la red TOR, pero por detrás prácticamente la forma de operar de un Tor Browser y un Mozilla Firefox es muy similar. De esto precisamente es de lo que voy hablar en este artículo: de un análisis forense del navegador Tor Browser para mostrar toda la información que se puede extraer de este. No hay que olvidar que la red TOR está pensada para ofrecer anonimato a sus usuarios, pero este anonimato se queda en el enrutamiento de los distintos paquetes a través de la red. A nivel local, es decir, a nivel del ordenador del usuario que se conecta a esta red, TOR no ofrece ninguna medida de anonimato, ya que realmente no está diseñado para ello, por lo que lo que voy a contar a continuación no se puede considerar una vulnerabilidad en la red TOR, ni mucho menos en el navegador Tor Browser, simplemente está diseñado así, y de eso, sea mucho o poco, nos tendremos que aprovechar para poder realizar nuestro análisis forense.

 

Fig. Tor Forensics

 

En primer lugar vamos a comenzar por el estudio del navegador Tor Browser, y toda la información que este va almacenado en sus distintas bases de datos y ficheros de configuración. Como ya dije anteriormente, si alguna vez habéis realizado un análisis forense del navegador Mozilla Firefox, os daréis cuenta que muchos de los pasos que a continuación voy a describir serán muy similares a los que ya conocéis de este otro navegador web.

Este análisis forense lo voy a realizar sobre una maquina Linux, mas concretamente sobre un Ubuntu v16 de 64bits. Aunque podréis comprobar que Tor Browser en sistemas Windows opera exactamente igual. En el caso de Windows podréis encontrar todos los ficheros “interesantes” en la ruta: “Tor Browser/Tor/TorBrowser/Data/Browser/profile.default/”, como así se puede observar en la siguiente imagen.

 


Fig. TOR Browser en Windows

 

Por el contrario, si necesitáis realizar un análisis forense de navegador Tor de un sistema Linux, tendréis que buscar estos ficheros en la ruta: “/home/user/.tor-browser_es-ES/Browser/TorBrowser/Data/Browser/profile.default”, que será el caso del análisis que ahora nos ocupa:

 


Fig.TOR Browser en Linux

 

Tor Browser, al igual que Mozilla Firefox, puede operar con un grado de “secretesimo” mayor o menor en función de la configuración que hubiera seleccionado el usuario. A continuación os muestro como sería la configuración de privacidad por defecto de un navegador Tor Browser recien instalado.

 


Fig. Configuración por defecto TOR Browser

 

Ahora nos metemos en materia y comenzamos con el análisis de las distintas bases de datos y ficheros de Tor Browser, comenzaremos, desde mi punto de vista con uno de los ficheros mas importantes que Tor Browser nos puede ofrecer a niver forense, la base de datos “places.sqlite”. Como su propio nombre indica, es una base de datos tipo SQLite, por lo que la podremos abrir si ningún problema con un visor de bases datos de este tipo.

 

Seguir leyendo