WhatsApp: Mezclando churras con merinas.

Mientras que las ovejas de la familia de las churras proporcionan una excelente leche y carne, las merinas son conocidas por su lana blanca de alta calidad. Por lo que no es para nada una buena idea ordeñar una merina para aprovechar su leche o hacerse un abrigo con lana de una churra. Pese a que amabas puedan parecer ovejas, y lo son, sus características hacen que sean muy distintas aunque a simple vista parezca lo contrario.

Fig. Ovejas merinas

En el mundo ciber ocurre lo mismo, podemos tener dos ciberataques que parezcan iguales, pero en realidad sus diferencias hacen que no tengan nada que ver el uno con el otro, un buen experto en ciberseguridad deberá entender y ser capaz de identificar estas diferencias. Estos días hemos vivido una serie de ataques informáticos que han sido tratados y expuestos en los medios de comunicación, en algunos con mayor atino que en otros. Estamos acostumbrados, al menos yo lo estoy, que cuando se tratan temas ciber en un ámbito no técnico se cometan errores en cuanto a la interpretación o capacidades de un ciberataque. En cierto modo es normal y entendible, no son periodistas especializados en el mundo de las nuevas tecnologías, tan pronto tienen que comentar la noticia de un asesino que anda suelto, como si en Murcia ha llovido más de lo normal o si han aprobado alguna ley estrambótica. Pero si considero que tienen que tratar de rodearse de profesionales de la ciberseguridad que los asesoren cuando tengan que explicar algún tema complejo o que desconozcan, algunos me constan que sí lo hacen, ya que de no ser así, se generará una situación de alarma social y preocupación totalmente innecesaria.

Fig. Playa Carolina en Murcia

El motivo de escribir este artículo es dar respuesta de la forma más adecuada y tranquilizadora posible a todos esos conocidos y seguidores en RRSS que me escribían preocupados por no saber qué hacer para evitar que les roben el Whatsapp y les vacíen su cuenta bancaria. Todo ello a raíz de una noticia aparecida en algún medio de comunicación.

Aunque para los expertos en ciberseguridad esa noticia no tenía mucho sentido, en realidad si lo tiene, pero no de la forma que estamos pensando. No hace muchos años salían de vez en cuando noticias sobre ciberataques, cada una de ellas distinta a la anterior, no existía relación entre ellas, pero eso se terminó. Nos tenemos que acostumbrar, por mucho que me duela decirlo, que el cibercrimen está en aumento y cada día vamos a ir viendo ciberataques más elaborados, ciberataques que son similares entre sí y que se ejecutan al unísono, pero no por ello ejecutados por las mismas personas u organizaciones criminales. Pensad que las organizaciones criminales que se dedican al cibercrimen no tienen un calendario en común en el que van reservando fecha para realizar sus fechorías y que otras organizaciones no le “pisen” el día. La realidad es que distintas organizaciones pueden ejecutar un ciberataque de similares características en la misma fecha sin haberlo acordado previamente.

Fig. Calendario de ciberataques de un día cualquiera

Esto fue lo que ocurrió en esta ocasión, por una lado, tenemos una operación de Policía Nacional en la que se desmantela una organización criminal formado 19 cibercriminales que fueron detenidos, los cuales obtuvieron un botín de más de 450.000€ mediante transferencias bancarias fraudulentas realizadas con la técnica del SIM Swapping. Por otro lado, tenemos un aviso policial en el que se notifica el robo de cuentas de Whatsapp a través del SMS de verificación de la cuenta. Hechos totalmente independientes, pero que al parecer se ha creado cierta confusión al relacionarlos.

Fig. Operación Policía Nacional SIM Swapping

Así que una vez explicada la diferencia entre churras y merinas, o lo que es lo mismo, entre SIM Swapping o Secuestro de Whatsapp, os voy a explicar detalladamente en qué consiste cada uno de estos ciberataques y cómo podemos defendernos de ellos, ya que es realmente lo que importa: CONCIENCIAR a cuantas más personas mejor para que aprendan a protegerse de este tipo de delitos sin caer en el alarmismo.

Ataque número 1: SIM Swapping.

Este es un tipo de ciberataque viejo, pero que por desgracia hoy en día sigue funcionando, no tanto como años atrás, ya que muchas de las entidades bancarias ya no verifican las operaciones de transferencia mediante un SMS, aunque si lo siguen haciendo los operadores de tarjetas bancarias para confirmar ciertos cargos o pagos online.

Seguir leyendo

Router Forensics: El ojo que todo lo ve.

No, en este artículo no os voy a hablar del “Ojo de Horus”, os voy a hablar de otro ojo que posiblemente tengáis mucho más cerca de lo que creéis, incluso en este mismo momento estéis leyendo este artículo gracias a ese “Ojo que todo lo ve”, un ojo que podéis encontrar en vuestra casa, en vuestra oficina o en la cafetería a la que vais a tomar café todos los días. Este ojo tampoco es una cámara IP, es algo mucho mas mundano. Este ojo es un simple router, si, ese dispositivo que todos tenemos en nuestros hogares y oficinas para poder conectarnos a Internet, ya sea a través de WiFi o de cable. Quizás os parezca otro cacharro más que podemos tener en casa, un cacharro que no merezca mas atención que la que le prestamos cuando se nos “cae” Internet o nos va lento.


En este artículo os voy a explicar todo el potencial que puede tener un simple router doméstico a nivel forense. Será un artículo extenso, ya que prefiero centralizar toda la información en un solo artículo, que en fraccionarlo en varias partes, de este modo será mas sencillo utilizarlo como artículo de referencia.

Fig. Router doméstico

Desde mi punto de vista, un router doméstico es uno de los elementos mas críticos que podemos tener en casa en cuanto a lo que ciberseguridad se refiere, pensad que para empezar es de los pocos dispositivos que podéis tener en vuestros hogares que están encendidos 24 horas al día, un dispositivo que tiene un sistema operativo y que es el que decide que conexiones de red se pueden establecer y cuales no, un dispositivo que está diseñado para ser administrado remotamente, y por si no fuera poco, un dispositivo que normalmente no esta adecuadamente actualizado y puede ser una puerta abierta de par en par a la red local de nuestra casa, es decir, una puerta abierta a nuestras SmartTV, nuestros PC, enchufes inteligentes, cámaras IP, smartphones… así como un sinfín de dispositivos que podemos tener conectados a Internet en nuestros domicilios, cuya única protección hacía el exterior es el router y su correspondiente firewall.

Fig. Seguridad en routers

Quizás ahora ya estáis viendo ese cacharro con luces que tenéis en vuestro salón con otros ojos, pero no se queda aquí la cosa, un router doméstico normalmente dispone de un punto de acceso WiFi para que podamos conectarnos a Internet desde nuestros teléfonos o ordenadores portátiles ¿y que ocurriría si alguien ataca nuestra red WiFi y se conecta a ella para cometer cualquier tipo de cibercrimen?¿estamos preparados para recoger todas los vestigios que el cibercriminal haya dejado en el router?. Y si una botnet toma el control de nuestro router para lanzar una campaña de DDoS contra una red concreta, ¿sabremos como detectarlo y extraer todas las evidencias?. De todo eso va este artículo, vamos a ver toda la información forense que se puede obtener de un simple router doméstico entregado por nuestra compañía telefónica.

Fig. Malware para routers “Ghost DNS”

Comenzamos por lo más sencillo, realizar un análisis desde el propio interfaz web del router, para esto tan solo tendremos que acceder a la página de administración avanzada. Normalmente la encontraremos en la dirección IP: 192.168.1.1:8000 o 192.168.1.1:8080. No hay que confundir este portal avanzado, con el portal de gestión básica, habitualmente el portal básico está diseñado por el propio operador telefónico, este nos permitirá configurar la contraseña de la WiFI, el nateo, quizás un filtrado por MAC y poco más. El portal básico no nos servirá para el análisis que pretendemos realizar. El acceso al portal “pro” del router suele estar en el puerto 8000 o 8080 y el básico en el 80.

En primer lugar vamos a ver que información podemos obtener a través del portal web del router, obviamente está será una información muy básica pero posiblemente en algunos casos nos será suficiente.

Fig. Router admin

En caso de tener una sospecha de que alguien nos pueda estar “pirateando” el WiFi, podemos acudir al menú “Lease DHCP” de nuestro router y ver un listado de todos los equipos que están conectados a la red WiFi, la ventaja de hacerlo así y no con aplicaciones móviles tipo Fing, es que podemos ver el tiempo de expiración (caducidad) de la IP. Básicamente el Lease DHCP es una tecnología que utiliza un router para repartir las direcciones IP disponibles a los distintos clientes de forma dinámica, normalmente esta dirección se la “alquila” (leasing) al cliente por 24 horas, si en 24 horas no se ha conectado se borrará de la lista y se podrá asignar esa misma IP a otro cliente / usuario (dispositivo). La ventaja de esto, es que no necesitamos que el pirata esté conectado al mismo tiempo que nosotros estamos analizando las conexiones, si se conectó en un plazo de 24 horas, quedará registrado en esta tabla, es más, podremos saber a que hora se conectó, ya que tan solo tendremos que restar la hora de expiración a la hora actual, como se puede ver en la siguiente foto.

Fig. Menú Lease DHCP Vodafone

Esta tecnológica es común para todo tipo de router domésticos, por ejemplo, en la fotografía superior lo podemos ver en router doméstico de la compañía Vodafone y en la siguiente fotografía, el mismo menú en un router también doméstico de Movistar, cambia el diseño pero la información es la misma. Con la dirección MAC y el nombre del dispositivo podremos identificar fácilmente a nuestro pirata.

Fig. Menú Lease DHCP Movistar

Hoy en día es común que nuestros routers domésticos puedan ser telegestionados en remoto por la propia compañía telefónica, esto nos puede ser útil para que nos lo actualicen, configuren o reparen de forma remota, sin necesidad de que un técnico acuda a nuestro hogar. Normalmente la compañía telefónica no utiliza VPNs o similar para conectarse de forma remota y segura a nuestro router, básicamente de forma previa han grabado sus IP públicas en el Firewall de nuestro router para que solo desde estas IP se puedan conectar de forma remota al router y configurarlo. Aquí nos podemos encontrar con dos problemas:

El primero es que alguien tome el control de alguna de esas IP por una cesión de rango, o incluso que por un fallo de routeo estas IPs puedan pertenecer al resto de clientes del mismo proveedor, es decir, cualquier cliente del ISP (operador telefónico) podría llegar a tomar el control remoto de nuestro router, con todo lo que esto implica, esto ocurre si la compañía ha grabado la misma dirección IP o rango de telegestión que las direcciones IP públicas que se le asignan al resto de clientes.

Por otra parte, en caso de que el operador telefónico sea comprometido, a través de su red podemos recibir un ataque contra nuestra red local (doméstica), al tener una puerta abierta a todo lo que llegue desde la red del operador (no de Internet), por ejemplo, un ataque del tipo ransonware contra algún servicio que tengamos levantando en nuestra red, como un SAMBA. Con esto no quiero decir que tener habilitada la telegestión del router es algo malo o inseguro, simplemente es conveniente tener en cuenta las implicaciones que tiene, por supuesto, en caso de avería nos resultará mucho mas fácil que la compañía se conecte al router y nos lo repare. Así es como se vería este menú con las diferentes direcciones IP grabadas, en caso de ver una dirección IP o rango, perteneciente a un país con tundra, igual nos deberíamos preocupar un poco y pensar que alguien nos ha modificado las “trusted ip” de nuestro router, ya que con una IP maliciosa en esta configuración, el cibercriminal podrá acceder a nuestra red local sin ningún problema, ya que tiene una puerta abierta a nuestra LAN a través del router.

Fig. Menú Trusted Network

Dejando ya a un lado el menú web de nuestro router doméstico, ahora vamos a subir un poco el nivel y vamos a entrar al corazón del dispositivo. Para ello necesitaremos conectarnos vía SSH a nuestro enrutador, normalmente no nos tendremos que complicar mucho, ya que no suelen estar los puertos cambiados, con un SSH al 22 y a la IP local del router será suficiente.

Fig. Acceso via SSH al router

Si por lo que sea no logramos establecer la conexión, siempre podemos analizar el router con la herramienta Nmap para ver que servicios tiene levantados y en que puertos están, en el caso de la siguiente fotografía está todo en su sitio. Si es la primera vez que escaneáis un router y veis tantos puertos abiertos, no os preocupéis, es normal.

Seguir leyendo

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