Fuga de datos por avisos publicitarios

Cuando usamos las aplicaciones más populares que tienen buena calificación en las tiendas virtuales, asumimos que son seguras. Esto es cierto, pero solo hasta cierto punto. Por lo general, estas aplicaciones han sido desarrolladas teniendo en cuenta la seguridad y han sido revisadas por el equipo de seguridad de la tienda virtual. Sin embargo, descubrimos que debido a SDKs de terceras partes (por lo general SDKs publicitarios), muchas de estas aplicaciones exponen la información de usuario en Internet. Estos SDKs recopilan datos para mostrar avisos relevantes para el usuario, pero no los protegen cuando los envían a sus servidores.

En el curso de nuestra investigación sobre la seguridad de aplicaciones para citas, descubrimos que algunas de las aplicaciones analizadas transmitían datos de usuario a través del protocolo HTTP, pero sin cifrarlos. Se trata de un comportamiento inesperado porque estas aplicaciones utilizaban HTTPS para comunicarse con sus servidores. Pero junto a las solicitudes HTTPS, había algunas solicitudes HTTP dirigidas a servidores de terceras partes que se enviaban sin cifrar. Estas aplicaciones son bastante populares, por lo que decidimos analizar de cerca sus solicitudes.

Solicitud HTTP con datos de usuario no cifrados

Una de las aplicaciones enviaba solicitudes POST al servidor api.quantumgraph[.]com. De esta forma enviaba un archivo JSON sin cifrar a un servidor ajeno a los desarrolladores de la aplicación. En este archivo JSON encontramos gran cantidad de datos de usuario, entre ella información del dispositivo, fecha de nacimiento, nombre de usuario y coordenadas GPS. Además, el archivo JSON contenía información detallada sobre el uso de la aplicación y datos de los perfiles de redes sociales a los que el usuario había puesto “Me gusta”. Toda esta información se enviaba sin codificar al servidor de un tercero, y lo que realmente causa alarma es el gran volumen de esta información, recopilada gracias al uso de un módulo de análisis qgraph.

Datos de usuario no cifrados que envía la aplicación

Las otras dos aplicaciones para citas que investigamos hacían exactamente lo mismo. Usaban el protocolo HTTPS para comunicarse con sus servidores, pero al mismo tiempo enviaban solicitudes HTTP con datos de usuario no cifrados al servidor de un tercero. Esta vez se trataba de otro servidor que no pertenecía a una compañía de análisis, sino a una red de publicidad que ambas aplicaciones para citas utilizaban. Otra diferencia eran las solicitudes GET HTTP con datos de usuario usados como parámetros en una URL. Pero en general, estas aplicaciones hacían lo mismo: transmitían datos de usuario, sin cifrarlos, a servidores de terceros.

Lista de solicitudes HTTP de SDK

A estas alturas, la cosa ya se veía bastante mal, por lo que decidí revisar mi propio dispositivo y recopilé mis actividades en red durante una hora. Este periodo fue suficiente para identificar solicitudes no cifradas que incluían mis propios datos. Nuevamente, el origen de estas solicitudes era el SDK de un tercero utilizado por una aplicación popular. Transmitía mi ubicación, información de mi dispositivo y tokens de mensajes Push.

Solicitudes HTTP desde mi dispositivo con mis propios datos sin cifrar

Entonces, decidí analizar estas aplicaciones para citas con filtraciones por SDKs para saber por qué ocurrían. Como lo suponía, eran varios terceros los que los utilizaba en estas aplicaciones; en realidad, cada aplicación contenía al menos 40 módulos diferentes. Representan una gran parte de estas aplicaciones: al menos un 75% del código de Dalvik se encontraba en módulos de terceros, y en una aplicación la proporción de código de terceros era de hasta el 90%.

Lista de módulos encontrados en las aplicaciones para citas analizadas

Los desarrolladores suelen recurrir a códigos de terceros para ahorrar tiempo y aprovechar lo que ya existe. Esto tiene mucho sentido y les permite enfocarse en sus propias ideas en lugar de dedicar su tiempo a algo que otros ya han desarrollado muchas veces. Sin embargo, esto significa que es improbable que los desarrolladores conozcan todos los detalles de los códigos de terceros que usan y que pueden tener muchos problemas de seguridad. Esto es lo que sucedió con las aplicaciones objeto de nuestra investigación.

Los resultados

Sabiendo que hay SDKs populares que exponen los datos de usuario y que casi todas las aplicaciones utilizan varios SDKs, decidimos buscar más aplicaciones y SDKs. Para ello, volcamos el tráfico de red de nuestra propia caja de arena para Android. Desde 2014 venimos recopilado las actividades en la red de más de 13 millones de APKs. La idea es sencilla: instalamos y ejecutamos una aplicación y simulamos la actividad de los usuarios. Durante la ejecución de la aplicación recopilamos registros y tráfico de red. Si bien no son datos de usuarios reales, la aplicación los considera como dispositivos y usuarios reales.

Nuestra búsqueda se centró en las dos solicitudes HTTP más populares: GET y POST. En las solicitudes GET, los datos de los usuarios suelen ser parte de los parámetros URL, mientras que en las solicitudes GET los datos de los usuarios están en el campo Content de la solicitud y no en la URL. En nuestra investigación buscamos aplicaciones que transmitan los datos de usuario no codificados mediante al menos una de estas solicitudes, aunque muchas exponían los datos de usuario en ambas solicitudes.

Logramos identificar más de 14 millones de APKs que exponían datos en Internet. Algunos de ellos lo hacían porque sus desarrolladores habían cometido un error, pero la mayoría de las aplicaciones populares exponían estos datos debido a SDKs de terceros. Para cada tipo de solicitud (GET o POST) extrajimos los dominios desde los cuales las aplicaciones transmitían los datos de usuario. Luego, clasificamos estos dominios por la popularidad de la aplicación, es decir, la cantidad de usuarios que las habían instalado. De esta manera logramos identificar los SDKs más populares que filtraban datos de usuario. La mayor parte de ellos exponían información sobre dispositivos, pero algunos filtraban información más reservada, como coordenadas GPS o información personal.

Cuatro dominios muy populares desde los que las aplicaciones filtraban datos confidenciales a través de solicitudes GET

mopub.com

Este dominio es parte de una popular red publicitaria. Las dos aplicaciones para citas que mencionamos al principio de este articulo usaban este dominio. Encontramos muchas mas aplicaciones populares con este SDK; al menos cinco de ellas tienen mas de 100 millones de instalaciones segun Google Play Store y muchas otras tambien tienen millones de instalaciones.

Filtra los siguientes datos no cifrados:

• informacion sobre el dispositivo (marca, modelo, resolucion de pantalla)
• informacion de la red (MCC, MNC)
• nombre del paquete de la aplicacion
• coordenadas del dispositivo
• Palabras claves

Solicitud HTTP con datos de usuario en URL

Las palabras claves son la parte mas interesante de los datos filtrados. Pueden variar dependiendo de la configuracion de los parametros de la aplicacion. En nuestros datos aparecian algunos datos personales, como nombre, fecha de nacimiento y sexo. La ubicacion tambien debe ser establecida por una aplicacion, y por lo general las aplicaciones proporcionan las coordenadas GPS al SDK publicitario.

Encontramos varias versiones distintas de este SDK. La mas comun podia usar HTTPS en lugar de HTTP. Pero este parametro lo tienen que configurar los desarrolladores de la aplicacion, y segun nuestros hallazgos, no se molestaron en hacerlo, dejando el valor HTTP predeterminado.

SDK publicitario que usa HTTP por defecto

rayjump.com

Este dominio tambien forma parte de una popular red publicitaria. Encontramos dos aplicaciones con mas de 500 millones de instalaciones, siete con mas de 100 millones, y muchas con millones.

Extrae los siguientes datos:

• información sobre el dispositivo (marca, modelo, resolución de pantalla, versión del SO, idioma, zona horaria, IMEI, MAC)
• información de la red (MCC, MNC)
• nombre del paquete de la aplicación
• coordenadas del dispositivo

Cabe mencionar que si bien la mayor parte de estos datos se transmitían en texto simple, como los parámetros URL, las coordenadas, las direcciones IMEI y MAC se cifraban con Base64. No podemos afirmar que estuviesen protegidos, pero al menos no estaban en texto simple. No logramos encontrar ninguna versión de este SDK con el que sea posible usar HTTPS; todas las versiones tenían URLs HTTP incrustadas en el código.

Los SDKs publicitarios recopilan la ubicacion de los dispositivos.

tapas.net

Otro popular SDK publicitario que recopila los mismos datos que los demas:

• informacion del dispositivo (marca, modelo)
• codigo del operador de red
• nombre del paquete de la aplicacion
• coordenadas del dispositivo

Encontramos siete aplicaciones con mas de 10 millones de instalaciones desde Google Play Store, y muchas otras con menos instalaciones. Tampoco logramos encontrar ninguna forma en que los desarrolladores migraran de HTTP a HTTPS en este SDK.

appsgeyser.com

Este SDK publicitario difiere de los demas en que se trata de una plataforma para desarrollar aplicaciones. Permite que quienes no deseen desarrollar una aplicacion sencillamente puedan crear una. Y esa aplicacion tendra incorporado un SDK publicitario que usa datos de usuario en solicitudes HTTP. Entonces, en realidad, estas aplicaciones las desarrolla este servicio y no los desarrolladores.

Se transmiten los siguientes datos:

• informacion sobre el dispositivo (marca, modelo, resolución de pantalla, versión del SO, android_id)
• información sobre la red (nombre del operador, tipo de conexión)
• coordenadas del dispositivo

Encontramos una gran cantidad de aplicaciones se habían creado con esta plataforma y que tienen incorporado este SDK publicitario, pero la mayor parte de ellas no son muy populares. La más popular tiene apenas decenas de miles de instalaciones. Pero hay muchas aplicaciones similares.

Captura de pantalla de appsgeyser.com

Segun la pagina web appsgeyser.com, existen mas de seis millones de aplicaciones con al menos 2.000 millones de instalaciones entre todas. Y muestran casi 200.000 millones de avisos publicitarios, todos ellos probablemente via HTTP.

Cuatro de los dominios mas populares desde los cuales estas aplicaciones exponen datos confidenciales mediante solicitudes POST

ushareit.com

Todas las aplicaciones que envian datos no cifrados a este servidor las creo la misma compania, de manera que en este caso los codigos de terceros no tienen nada que ver. Pero estas aplicaciones son muy populares; una de ellas se instalo mas de 500 millones de veces desde Google Play Store. Se caracterizan por recopilar una gran cantidad de datos sobre los dispositivos:

• marca
• modelo
• resolucion de pantalla
• version del sistema operativo
• idioma del dispositivo
• pais
• android_id
• IMEI
• IMSI
• MAC

Información sobre el dispositivo recopilada por la aplicación

Estos datos se envían sin cifrar al servidor. Además, entre los datos que se transmiten aparece una lista de comandos permitidos, uno de los cuales es para instalar una aplicación. La lista de comandos se transmite en texto sencillo y la respuesta desde el servidor también llega sin cifrar. Esto significa que puede ser interceptada y modificada. Lo que es aún peor sobre esta función es que la aplicación puede en secreto instalar una aplicación descargada. La aplicación sólo necesita ser una aplicación de sistema o tener derechos de raíz para hacerlo.

Fragmento del codigo relacionado con la instalacion secreta de aplicaciones ordenada por el servidor.

Lenovo

Este es otro ejemplo de aplicaciones populares que filtran datos de usuario, pero no por culpa de un codigo de terceros sino por un error de los desarrolladores. Encontramos varias aplicaciones populares de Lenovo que recopilan y transmiten informacion no cifrada sobre los dispositivos:

• IMEI
• version del sistema operativo
• idioma
• marca
• modelo
• resolucion de pantalla

solicitud HTTP con datos del dispositivo no cifrados

Esta informacion no es muy critica. Pero encontramos varias aplicaciones de Lenovo que enviaban datos mas criticos sin cifrar, como coordenadas GPS, numeros de telefono y direcciones de correo electronico.

Codigo de aplicacion para recopilar coordenadas de dispositivos y otros datos

Informamos a Lenovo sobre estos problemas y ya los han reparado.

Nexage.com

Este dominio lo usa un SDK publicitario muy popular. Hay enormes cantidades de aplicaciones que lo utilizan. Una de ellas incluso tiene mas de 500 millones de instalaciones y otras siete tienen mas de 100 millones. La mayor parte de las aplicaciones con este SDK son juegos. Hay dos cosas interesantes sobre este SDK: los datos transmitidos y el protocolo utilizado.

Este SDK envia los siguientes datos al servidor:

• informacion sobre el dispositivo (resolucion de pantalla, tamano del almacenamiento, volumen, nivel de bateria)
• informacion sobre la red (nombre del operador, direccion IP, tipo de conexion, potencia de la senal)
• coordenadas del dispositivo

Tambien envia informacion sobre la disponibilidad de hardware:

• Camara frontal o posterior
• Permiso para NFC
• Permiso para Bluetooth
• Permiso para micrófono
• Permiso para coordenadas GPS

SDK publicitario que recopila información sobre funciones de dispositivos hardware

También puede enviar alguna información personal, como edad, ingresos, educación, etnia, preferencias políticas, etc. No hay trucos mágicos; el SDK no tiene forma alguna de encontrar esta información a menos que las aplicaciones que usan este SDK se la proporcionen. Aún no hemos visto ninguna aplicación que proporcione estos datos al SDK, pero creemos que los usuarios deberían saber sobre los riesgos de introducir sus datos en las aplicaciones. La información podría pasar al SDK y éste podría exponerla en Internet.

El SDK publicitario podría enviar información personal

La otra cosa interesante sobre este SDK es que usa HTTPS para transmitir datos, pero por lo general sólo para la comunicación inicial. Después, puede recibir desde el servidor nuevos ajustes de configuración que especifican una URL HTTP. Al menos eso es lo que sucedió en mi dispositivo y en varias ocasiones con diferentes aplicaciones en nuestros dispositivos de prueba.

URL HTTPS en SDK publicitario

Quantumgraph.com

Otro SDK que filtra datos utiliza el dominio quantumgraph.com. Este es un SDK analitico, no publicitario. Encontramos dos aplicaciones con mas de 10 millones de instalaciones desde Google Play Store y otras siete con mas de un millon. Mas del 90% de los usuarios detectados con este SDK eran de India.

Este SDK envia archivos JSON con datos mediante HTTP. Los datos pueden variar de una aplicacion a otra, porque se trata de un SDK analitico que envia informacion proporcionada por la aplicacion. En la mayor parte de los casos, entre los datos enviados figuran los siguientes elementos:

• Informacion sobre el dispositivo
• Informacion personal
• Coordenadas del dispositivo
• Uso de la aplicacion

Lista de aplicaciones instaladas enviadas al servidor sin cifrar.

En el caso de la aplicación para citas, figuraban Me gusta, pases y perfiles visitados: toda la actividad del usuario.

Los datos sobre el uso de la app se enviaban sin cifrar al servidor.

Este SDK utilizaba una URL HTTP incrustada en el código, pero después de nuestro informe crearon otra versión con una URL HTTPS. Sin embargo, la mayor parte de las aplicaciones siguen usando la antigua versión HTTP.

Otros SDKs

Por supuesto, hay otros SDKs que usan HTTP para transmitir datos, pero no son tan populares y son casi idénticos a los ya descritos. Muchos de ellos exponen la ubicación de los dispositivos, mientras que otros exponen direcciones de correo electrónico y números de teléfono.

Números de teléfono y direcciones de correo electrónico recopilados por una aplicación para enviarlos mediante HTTP

Otros hallazgos

Durante nuestra investigación encontramos muchas aplicaciones que transmitían datos de autenticación sin cifrar mediante HTTP. Nos sorprendió descubrir la cantidad de aplicaciones que todavía utilizan HTTP para autenticar sus servicios.

solicitud no cifrada con testigo de autenticación

No siempre transmitían credenciales del usuario; algunas veces también transmitían credenciales para sus servicios, como bases de datos. No tiene sentido tener credenciales para estos servicios ya que están expuestos en Internet. Estas aplicaciones suelen transmitir tokens de autenticación, pero hemos visto también nombres de usuario y contraseñas sin cifrar.

Solicitudes sin cifrar con credenciales

Programas maliciosos

Un análisis profundo de una solicitud HTTP con datos sin cifrar nos permitió descubrir un nuevo sitio malicioso. Resulta que muchas aplicaciones maliciosas utilizan HTTP para transmitir datos de usuario. Y en el caso de los programas maliciosos, esto es peor aún, porque puede robar más datos críticos, como mensajes SMS, el historial de llamadas, los contactos, etc. Las aplicaciones maliciosas no sólo roban datos de usuarios sino que también los exponen en Internet, poniéndolos al alcance de otros para que los exploten y vendan.

Datos filtrados

En esta investigacion analizamos las actividades en la red de mas de 13 millones de archivos APK en nuestra caja de arena. En promedio, una de cada cuatro aplicaciones con comunicaciones de red exponia algunos datos de usuario. Es significativo el hecho de que existan aplicaciones muy populares que transmiten datos de usuario sin cifrar. Segun las estadisticas de Kaspersky Lab, en promedio cada usuario tiene mas de 100 aplicaciones instaladas, incluyendo aplicaciones del sistema y preinstaladas, de modo que asumimos que la mayoria estan afectados.

En la mayoria de los casos, estas aplicaciones exponian los siguientes datos:

• IMEI, International Mobile Equipment Identities (Id unico del modulo del telefono) que los usuarios no pueden restaurar a menos que cambien su dispositivo.
• IMSI, International Mobile Subscriber Identities (Id. unico de tarjeta SIM) que los usuarios no pueden restaurar a menos que cambien su tarjeta SIM.
• Android ID: un numero que se genera aleatoriamente durante la configuracion del telefono, de manera que los usuarios puedan cambiarlo cuando restauran su dispositivo a los ajustes de fabrica. Pero a partir de Android 8 habra un numero generado aleatoriamente para cada aplicacion, usuario y dispositivo.
• Informacion sobre el dispositivo, como la marca, modelo, resolucion de pantalla, version del OS y nombre de la aplicacion.
• Ubicacion del dispositivo.

Algunas aplicaciones exponen información personal, por lo general el nombre del usuario, edad y sexo, pero también puede incluir el salario del usuario. También puede filtrarse su número de teléfono y dirección de correo electrónico.

¿Por qué está mal?

Porque los datos pueden ser interceptados. Cualquiera puede interceptarlos en una conexión Wi-Fi insegura: el dueño de la red podría interceptarla, y tu operador de red podría saberlo todo sobre ti. Los datos se transmiten a través de varios dispositivos de red y pueden ser leídos en cualquiera de ellos. Incluso el router de tu casa puede verse afectado; hay muchos ejemplos de programas maliciosos que infectan a los routers domésticos.

Si no están cifrados, estos datos quedan expuestos como texto sencillo y pueden ser extraídos desde las solicitudes. Si se conoce el IMSI y el IMEI, cualquiera pude rastrear tus datos desde diferentes fuentes; para modificarlos, debes cambiar tu tarjeta SIM y tu dispositivo. Con estos datos en sus manos, cualquiera puede recopilar el resto de tus datos filtrados.

Además, los datos HTTP pueden modificarse. Alguien podría cambiar los avison que se muestran o, peor aún, podría cambiar el enlace a la aplicación. Debido a que algunas redes publicitarias promueven aplicaciones y piden a los usuarios que las instalen, es posible que lo que realmente descarguen sea programas maliciosos en lugar de la supuesta aplicación.

Las aplicaciones pueden interceptar el tráfico HTTP y evitar el sistema de permisos de Android. Android usa los permisos para proteger a los usuarios contra actividades no deseadas de aplicaciones. Esto implica que las aplicaciones declaren los accesos que necesitarán. Desde Android 6, todos los permisos se han dividido en dos grupos: normales y peligrosos. Si una aplicación necesita permisos peligrosos, tiene que pedirle permiso al usuario en el momento de ejecución, no sólo antes de la instalación. Entonces, para obtener la ubicación, la aplicación tiene que pedirle al usuario que le permita el acceso. Y para leer el IMEI o IMSI, la aplicación también tiene que pedirle al usuario que le permita el acceso, porque se trata de un permiso peligroso.

Pero una aplicación puede agregar un proxy a la configuración del wi-Fi y leer todos los datos que se transmiten desde otras aplicaciones. Para ello tiene que ser una aplicación del sistema o estar estipulada como Propietario del perfil o dispositivo. O bien, una aplicación puede establecer un servicio VPN en el dispositivo que transmite los datos de usuario a su servidor. Después, la aplicación puede encontrar la ubicación del dispositivo sin acceder al mismo con sólo leer las solicitudes HTTP.

El futuro

Uso de HTTP (azul) y HTTPS (naranja) en aplicaciones desde marzo de 2014

A partir del segundo semestre de 2016, más y más aplicaciones han migrado de HTTP a HTTPS. Entonces, estamos avanzando en la dirección correcta, pero a paso muy lento. Hasta enero de 2018, el 63% de las aplicaciones usan HTTPS, pero la mayor parte de ellas siguen usando HTTP. Casi el 90% de las aplicaciones usan HTTP. Y muchas de ellas transmiten datos privados sin cifrarlos.

Consejos para los desarrolladores

• No usen HTTP. Pueden exponer los datos de usuario, lo que es muy malo.
• Activen el redireccionamiento 301 para HTTPS en sus interfaces.
• Cifren los datos. Especialmente si tienen que usar HTTP. La criptografía asimétrica es un recurso perfecto.
• Siempre usen la última versión del SDK. Incluso si esto significa pruebas adicionales antes de publicarlo. Esto es muy importante porque se pueden solucionar algunos problemas de seguridad. Por lo que hemos visto, muchas aplicaciones no actualizan los SDKs de terceros, y en su lugar usan versiones obsoletas.
• Verifiquen las comunicaciones de red de sus aplicaciones antes de publicarlas. Sólo les tomará unos minutos pero podrán detectar si alguno de sus SDKs migran de HTTPS a HTTP y exponen los datos de usuario.

Consejos para los usuarios

• Verifiquen los permisos para sus aplicaciones. No permitan ningún acceso si no entienden el por qué. La mayor parte de las aplicaciones no necesitan acceder a su ubicación. Entonces, no lo permitan.
• Usen una VPN. Se cifrará el tráfico de red entre sus dispositivos y los servidores externos. Permanecerá cifrado para los servidores de la VPN, pero al menos es una mejora.