Análisis de vulnerabilidadesAndroid

Nuestra privacidad vibra con CLM Messenger

Hola a todos!

En el día de hoy os traigo junto a Francisco Palma (@1c3t0rm) una entrada sobre el análisis de la versión NO oficial de MSN Messenger para Android disponible desde hace pocos días en la Play Store.

Antes de empezar, si acabas de enterarte del lanzamiento de MSN Messenger para Android, recomendamos la siguiente lectura: https://www.proandroid.com/msn-messenger-android-clm-messenger/

Hemos decidido “separar” esta entrada en dos pequeñas partes, la primera en la cual Francisco nos enseñará a realizar un pequeño análisis de la aplicación obteniendo grandes resultados. Y la segunda, en la que yo (@alvarodh5), os contaré los movimientos que siguió el autor de esta aplicación cuando se le reportaron dichos fallos.

Primera Parte

Antes de nada, me gustaría agradecer a todos que forman parte del blog y sobre todo a Marcos (@_N4rr34n6_) y a Álvaro (@alvarodh5) por darme la oportunidad de realizar esta entrada y por el gran trabajo que realizan todos los usuarios de la comunidad informándonos con sus posts.

La idea de este post no es más que concienciar a todos de la importancia de nuestros datos y de que una mala práctica de implementación puede poner en peligro nuestra privacidad.

Sin nada más que añadir… ¡Comencemos!

A través de Twitter llegó a mí una aplicación que se hacía llamar “CLM – Chat Live Messenger” que decía reproducir aquella sensación nostalgia que nos hacía tener Messenger (MSN) de una manera muy similar a la aplicación del 2005.

No soy muy dado a instalar aplicaciones en mi dispositivo actual, sin antes echar un ojo… (Creo que todos aquí tenemos ese tipo de curiosidad con las cosas de vez en cuando 😉 )

Empecé por algo sencillo: ¿Qué me proporciona Play Store?

¿Versao Beta? ¿500k descargas? Algo no me cuadraba mucho, pero cuando visité el sitio web que proporcionaba me quedó más claro…

 

 

A partir de este punto me decidí a descargarme la apk en mi ordenador y proceder a analizarla.

Una buena fuente de APKs sería Apkpure (https://apkpure.com/es/clm-chat-live-messenger/com.welbertsoft.chatlivemessenger), así que la usaremos en este post.

En este punto una vez identificada nuestra aplicación a analizar podemos partir hacia muchas ramas, dos de ellas comunes podrían ser o centrarnos en la lógica que hay detrás de esta aplicación o simplemente observar como realiza las conexiones nuestro dispositivo con su servidor.

En este post vamos a tratar ambas, para la primera utilizaremos JADX (https://github.com/skylot/jadx) que nos echará una mano en decompilar el archivo .dex de la apk para así poder leer un poco la lógica de la misma. Y para la segunda usaremos algunas aplicaciones tanto en Android como en escritorio, que serán Packet Capture, Postman y cURL.

Pero procedamos primero a analizar la aplicación decompilando sus clases con JADX y leyendolas para ver que encontramos. Para esto me gusta iniciar la decompilación en consola e ir abriendo tranquilarmente en un editor como podría ser Sublime Text o VS Code dichas clases según se van decompilando.

Si recibimos algunos errores durante el proceso de decompilación, no les prestemos atención de momento, mientras no notemos nada extraño durante nuestra investigación, estos errores quedarán reflejados en los archivos que hayan sucedido. (Podéis echarle un ojo al README de Jadx para haceros una idea de como funciona.)

 

 

Una vez decompilé la aplicación miré los permisos que requería, no noté nada en especial que no se requeriera en una aplicación de mensajería. Hasta aquí, todo normal. Pero realmente sentía curiosidad de como era la lógica que usaba para conectarse con ese posible “servidor” que habíamos encontrado en Play Store.

 

Así que realicemos una búsqueda rápida del dominio “msnmessenger.xyz

 

 

 

Nos encontramos con lo que podrían ser los endpoint de nuestra aplicación, un directorio /app/ y dos puertos, 3000 y 4000. De momento centrémonos en /app/, donde podemos ver nuestro querido “Index of” que deja poco a la imaginación enseñandonos archivos PHP y directorios de “images”, curioso de mi cliqué en “images”, ni si quiera cargó, olvidé por completo la cantidad de descargas que había obtenido esa aplicación, así que preferí utilizar cURL y cargar toda la web en un fichero para más tarde hacerme una idea de la cantidad de información con la que estaba trabajando.

 

curl http://msnmessenger.xyz/app/pictures/ > clmdump.html

 

Tras filtrar solo el nombre de los archivos que se encontraban en ese directorio obtuve un archivo de en torno a 11MB, unos 421365 archivos de imagen a día de 7/06/18, en mi opinión, bastante crítico para tratarse solo de nombres de archivos y su extensión.
No contento con esto, decidí observar un poco más esa “TelaPrincipal” de nuestro análisis, observé que utilizaba uno de los puertos que descubrimos antes para comunicarse con la API de nuestra APK. Más tarde, en una actualización que realizó el desarrollador cambió este puerto por otra dirección IP distinta al dominio que utilizaba, debido a la alta demanda de este.
Sobre este puerto o IP, lanzaba distintas peticiones a su servidor, algunas de ellas podemos encontrarlas definidas en la lógica de la APK haciendo una búsqueda tras analizar como añadía el desarrollador su endpoint en el resto de clases.

 

 

En este punto tras ver lo tedioso que sería analizar todas las llamadas a la API y al observar que su servidor no disponía de un certificado, procedí a usar Packet Capture (https://play.google.com/store/apps/details?id=app.greyshirts.sslcapture&hl=es) en uno de mis dispositivos para analizar los paquetes enviados al servidor, esta aplicación muestra los paquetes a través de un proxy creado en una VPN que se crea en nuestro dispositivo, este método es muy útil ya que nos permite visualizar directamente el tráfico de paquetes sin necesidad de ser root.

 

 

Una vez llegados a este punto, observé que solo era necesario un id de usuario para obtener los mensajes que tenía en espera y que no habían sido almacenados en dispositivo, procedí a divulgarlo así como a avisar a su desarrollador para que lo arreglara lo antes posible tal y como me sugirió Marcos. Además de ello, podíamos obtener el MD5 de la contraseña de los usuarios si estos nos enviaban una petición de amistad…

 

 

Pensé que viendo el estado de la aplicación el correo que mostraba el desarrollador en Play Store no sería muy útil si quería que actuase rápidamente. Así que procedí a analizar como agregar un contacto en la aplicación.
Descubrí que se mandaba una petición de amistad y una vez aceptada, nuestra aplicación agregaba al contacto a nuestra lista de amigos con una llamada a la API teniendo en el body el “from” y el “to”; esto me hizo pensar que si mi id de usuario era tan elevada, la del administrador sería una baja. Efectivamente, la id número 2 era la del desarrollador, así que me agregué a su lista de contactos para hablarle y explicarle lo sucedido.

 

Os dejo una pequeña muestra de lo que pasó.

 

Segunda Parte

Hola de nuevo! Como os adelantaba anteriormente en esta parte comprobaremos que hizo el autor ante el reporte de las vulnerabilidades, pero antes, me gustaría mencionar algunas “features” que tenía esta aplicación (aparte de sacar las contraseñas de los usuarios).

 

Obteniendo conversaciones a través del ID único de la conversación:

 

Obtención de todos los emails de los usuarios registrados a través del campo “busca”:

 

Y la mejor, spamear a base de zumbidos, si, podrías replicar esta petición todas las veces que quisieras, provocando que el móvil de la víctima no dejase de vibrar. Para ello simplemente necesitabas ser su amigo (recordamos que podías aceptar la petición de otro) y tener su ID y Token, estos valores eran de fácil acceso a través del buscador o al acceder a una conversación con dicha persona.

 

Llegados a este punto, ¿Qué creéis que hizo el autor? Pues borrar la aplicación hasta ahí todo bien… Hasta que después de borrarla la subió con otro nombre apuntando a otro dominio y si, añadiendo más funcionalidades y aunque ésta ya no está disponible en la Play Store es 100% funcional si instaláis la APK.

 

Concretamente la nueva aplicación es la siguiente (https://apkpure.com/es/my-live-messenger/br.lm.livemessenger.android)

 

 

Decompilamos rápidamente el código para visualizar los cambios y el nuevo endpoint, en el propio MainActivity podemos observar las primeras llamadas.

 

 

En este caso, el nuevo dominio es: http://msnmessenger.live además, al acceder a éste nos aparece el siguiente index.

 

 

De hecho, obtenemos lo mismo si accedemos a http://msnmessenger.live/app/

 

 

A simple vista parece que la cosa mejoraba, pero realmente no era así, ya que en lugar de desactivar el Directory Listing simplemente se limitó a subir el index a esos dos directorios, por lo que, las imágenes (entre otros datos) seguían siendo accesibles.

 

 

Además, con las nuevas funcionalidades, tenemos más directorios de imágenes, a las imágenes de perfil se suman las imágenes que se envían de forma privada vía conversación y vía grupos.

 

Por último, pese a que se nos negase el acceso a dichos directorios, seguría siendo viable el acceso a dichas imágenes, ya que el nombre de éstas es simplemente el ID de la imagen (con autoincrement) seguido de un guión bajo y el timestamp de subida, por lo que con una fuerza bruta sencilla deberíamos ser capaces de obtenerlas.

 

Además, todo esto sin contar que seguían disponibles una gran cantidad de ficheros PHP a nuestra disposición, algunos de ellos subían archivos, otros realizaban consultas a la BBDD, etc… No revisamos la seguridad de éstos en la nueva aplicación, pero no creo que haya mejorado mucho.

 

Mencionar que algunas vulnerabilidades como un posible File Upload y un SQLi fueron descubiertas durante el análisis de la aplicación, sin embargo,  y como es lógico éstas no fueron explotadas y obviamente, fueron reportadas. Dicho objetivo no es otro que informar de la importancia de nuestra privacidad y de los riegos que corremos en instalar aplicaciones de desconocidos y/o inseguras.

 

Por último, si habéis llegado hasta aquí, es buen momento para escuchar este audio que la propia aplicación nos facilita: http://msnmessenger.live/app/music/1059_zigb_1528248475984.mp3

 

Esperamos que os haya parecido interesante, y cualquier duda que tengáis no dudéis en preguntarla y os responderemos en la medida de lo posible 😉

 

Autores:
Francisco Palma (@1c3t0rm)
Álvaro Díaz (@alvarodh5)

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Los datos introducidos se guardarán en nuestra base de datos como parte del comentario publicado, como se indica en la política de privacidad.