Nuestro compromiso para apoyar a las universidades en sus investigaciones es firme, no son pocas las ocasiones en las que nuestros productos y soluciones de seguridad se ponen al servicio de la comunidad científica e investigadora para ayudar en todo lo posible a los investigadores. Tacyt es un claro ejemplo de servicio prestado cuyo uso beneficia a todos, por un lado abastecemos de datasets para realizar las investigaciones y por otro obtenemos feedback de una comunidad activa y con ideas innovadoras que enriquecerán las capacidades de nuestra plataforma. Os traemos algunos trabajos finales que han sido realizados gracias a los datos facilitados por esta plataforma y que han sido realizado con la tutorización de profesores de la Universidad Politécnica de Madrid junto al Instituto IMDEA Software.

En este caso hablaremos de un TFG y un TFM enfocados al análisis de malware en aplicaciones para Android utilizando diferentes indicios y detalles para realizarlo. Para estos casos Tacyt supone una ventaja ya que esta herramienta de ciberinteligencia fue concebida como un mecanismo útil de seguridad en el terreno de las aplicaciones móviles. Gracias a Tacyt se puede automatizar el proceso de supervisión, análisis y monitorización de diferentes markets de APKs (del inglés Android Application Package; es decir, Aplicación Empaquetada de Android) para Android y análogamente para Apple mediante IPAs (iOS App Store Package, es decir, Paquete de la Tienda de Aplicaciones de iOS).

Tacyt da una visión unificada de las aplicaciones presentes en los repositorios oficiales y no oficiales ahora y en el pasado, ofreciendo un lenguaje de consulta que permite buscar correlaciones de diversos atributos de las aplicaciones que en algún momento han estado disponibles para los usuarios. En la práctica, se permite la detección automatizada de patrones de facilitan investigaciones de ciberseguridad que de otro modo serían imposibles.  Tacyt proporciona la capacidad de responder a las más variadas preguntas: ¿cuántas aplicaciones fueron retiradas por un desarrollador en el pasado? ¿cuántas de éstas presentaban un uso concreto de APIs o librerías? ¿cuántas aplicaciones comparten un content provider o un fichero? ¿cuántas aplicaciones de tipo “juegos” solicitan acceso a la cámara? Con Tacyt se vuelve un ejercicio trivial, pero sin él sería imposible responderlas.

Detección de desarrolladores de aplicaciones maliciosos

El primer TFG corresponde al Grado en Ingeniería Informática de la Universidad Politécnica de Madrid. Lleva por nombre Diseño e Implementación de un Módulo para la Detección de Aplicaciones Móviles Maliciosas en Mercados Online y su autora es Silvia Sebastián González. El TFG ha sido financiado por el Instituto IMDEA Software y dirigido por el investigador Juan Caballero.

El objetivo de este trabajo es localizar aplicaciones en Google Play pertenecientes a la misma persona pero que utilizan cuentas diferentes de desarrollador. Este problema es importante porque la misma persona puede crearse más de una cuenta de desarrollador con el mismo o diferentes nombres de usuario. Las razones que explican este comportamiento son variadas, pero este proyecto se centra en las maliciosas. Se parte de la hipótesis de que un desarrollador puede generar varias cuentas para alojar en ellas aplicaciones maliciosas con diferente apariencia exterior. De esta manera, si una resulta denunciada, puede seguir manteniendo las otras en el mercado para continuar con sus actividades.

El caso expuesto asume una simultaneidad temporal, por lo que si se detecta un desarrollador malicioso sería idóneo poder relacionarlo con sus otras cuentas para poder suspender todas a un mismo tiempo. Sin embargo, también se pueden encontrar casos de no simultaneidad temporal: un desarrollador podría decidir generar una nueva cuenta tras comprobar que la primera ha sido inutilizada para así subir de nuevo la misma aplicación, pero con un nuevo identificador y nombre. Por tanto, lo ideal en este caso sería que, cada vez que un desarrollador intenta subir una aplicación, se identificara si es el mismo desarrollador que otro previamente eliminado por ser malicioso.

Se proponen dos soluciones para determinar si dos cuentas con nombre de desarrollador distinto son mantenidas por la misma persona. Cada solución se adapta a un escenario diferente, los cuales dependen del conocimiento que se tenga del input: se pueden conocer dos nombres de desarrollador y tratar de adivinar si tras ellos se esconde el mismo individuo o, por el contrario, no tener input y disponerse a encontrar casos de desarrolladores con más de una cuenta en el mercado. Los dos escenarios planteados se detallan a continuación:

• Escenario 1: Dados dos nombres de desarrollador, identificar si pertenecen a la misma persona

Tras obtener todas aquellas aplicaciones pertenecientes a ambos nombres de desarrollador, se establecen procesos para comparar los metadatos de alto nivel, como los datos de la cuenta, tales como el nombre del desarrollador y el dominio de Internet que aparece en la página de Google Play, o los certificados de firma de las apps. En el caso de los certificados, y teniendo en cuenta que en Android casi todos los certificados están autofirmados, existen determinados patrones y variaciones que pueden ser indicativos de la autoría de las aplicaciones. Algunos ejemplos podrían ser los “Certificate subject common name”, el “Certificate subject organization name” y la “Fingerprint”.

La segunda parte de este proceso de identificación se centra en comparar las aplicaciones de ambas cuentas. Para ello primero se comparan los metadatos de las aplicaciones a través de características como el tipo de aplicación, el tamaño, las API utilizadas, los permisos, las activities y las URLs. Además, se calcula la similitud del código.

• Escenario 2: Dado un conjunto de aplicaciones, encontrar desarrolladores con más de una cuenta

Para este caso el enfoque se basa en cruzar datos con listas de publicadores de actividades anómalas o cuestionables de otras plataformas, ya que esto sería un claro indicio de desarrolladores con varias cuentas. También se utiliza el “Metadata API Key List” que es capaz de relacionar de manera indirecta a dos desarrolladores, puesto que cada usuario debe tener unas claves de acceso para cada API. Si dos nombres de desarrollador distintos tienen las mismas claves, se puede deducir que es una misma persona con varias cuentas. Explotando por tanto este parámetro, se puede agrupar a los desarrolladores en función de aquellas aplicaciones que tengan las mismas API keys.

El TFG realiza su estudio utilizando diferentes técnicas de análisis y comparación, estableciendo una senda para mejorar la selección de las características, metadatos y campos a considerar en dichos estudios. Debido al elevado número de falsos positivos, se descartaron las técnicas más agresivas. Los resultados son mejores con las técnicas llevadas a cabo en R y Weka mediante matriz de medias de features ponderadas. También se incide en lo altamente beneficioso que es la comparación de código fuente de aplicaciones para realizar este tipo de estudios. Para realizar dicha comparativa se empleó la herramienta AndroSim, pero es una técnica muy costosa cuando el input son aplicaciones grandes.

A la hora de generar la comparativa de aplicaciones a partir de sus metadatos, se llega a la conclusión de que hay parámetros muy restrictivos que pueden emplear las técnicas utilizadas en la comparación de certificados: análisis de importancia de features, utilizar información ya obtenida de los certificados en lugar del Fingerprint y considerar nuevos parámetros en el análisis. Además, se le puede sacar un mayor partido a las descripciones de las aplicaciones ya que dan mucha información sobre las tareas que debe desempeñar. Esta información es muy importante ya que si dos aplicaciones tienen las mismas finalidades aumenta la probabilidad de que sean la misma.

Correlación del comportamiento de las aplicaciones Android

El segundo es un TFM del Master Universitario en Software y Sistemas de la Universidad Politécnica de Madrid titulado Checking Android applications behaviour against Google Play descriptions at scale de Daniel Domínguez Álvarez. El objetivo de este trabajo es aplicar al conjunto de datos de Tacyt la técnica CHABADA, que consiste en un mecanismo para saber si determinadas aplicaciones incorporan código malicioso o no a partir de la correlación entre su propósito esperado y su comportamiento real. Para ello se combina el procesamiento de lenguaje natural con una técnica de clustering para detectar si el uso de la API es lícito o no para un grupo de aplicaciones.

El procedimiento de CHABADA es fácilmente razonable, se toman familias de aplicaciones Android del conjunto de aplicaciones, por ejemplo, aquellas dedicadas a gestión de mapas y GPS, y sobre estas realizar un análisis de cuales características las diferencian del resto, siguiendo con el ejemplo para estas aplicaciones de mapas sus features podrían ser el acceso al sistema GPS, a la brújula y conectividad a Internet. Sin embargo, una característica anómala sería el acceso a los contactos. CHABADA da un paso más y además intenta identificar si la aplicación describe o anuncia una cualidad que justifique el acceso a los contactos, por ejemplo, ofreciendo elementos sociales que la diferencian del resto. Y precisamente este elemento de valor provocaría una errónea clasificación de la aplicación como maliciosa, ya que no incorpora un comportamiento normal para la clase en la que está encasillada.

Para entender cuáles son los objetivos de la aplicación se acude por tanto a la descripción pública que acompaña al software en el market. El procesamiento del lenguaje de dicho texto obtiene diferentes topics y los va asociando a los respectivos grupos de aplicaciones. De esta forma si la aplicación de GPS indica que tiene funcionalidades sociales en su descripción, no será considerada maliciosa por solicitar el acceso a los contactos del dispositivo. Para ello se sigue una serie de fases:

1. Preprocesamiento de la entrada, realizando un saneamiento y normalizado de los datos, eliminando etiquetados y elementos redundantes y adecuando la salida a las peculiaridades del idioma seleccionado.
2. Modelado de temas, utilizando modelos estadísticos se agrupan términos que corresponden a grupos de palabras componiendo temas.
3. Clustering, con el resultado del modelado, obteniendo un vector de afinidad con el grado de pertenencia a los diferentes grupos temáticos utilizando K-means.
4. Analisis de la API, a continuación, se realiza un análisis estático de las llamadas a la API de Android, detectando aquellas invocaciones sensibles, es decir, que están ligadas a la solicitud de permisos declarados, y por tanto útiles.
5. Detección de casos atípicos, para ello se utiliza un modelo capaz de identificar aplicaciones que no encajan claramente en la categorización por grupos, basado en un valor límite que determina la diferenciación. Estos casos serán susceptibles de análisis y que elevarán el debate sobre su naturaleza.

Para llegar a los resultados de la aplicación de CHABADA en Tacyt, primero fue necesaria la selección de los hiperparámetros, para establecer una configuración adecuada para el desarrollo del procedimiento, como por ejemplo el número clústeres y la cantidad de grupos temáticos a usar, así como la generación del propio dataset sobre el que realizar el análisis.

Los resultados finales permiten observar aquellos casos atípicos, cuyo score ha sido mayor que cero. Para el caso de las aplicaciones que no han sido encontradas en el Google Play, pero que han pasado por él, vemos que suponen el 30% del dataset, mientras que, por contraste, de las aplicaciones que sí han sido encontradas en el market son atípicas aproximadamente el 35%. Esto supone que las aplicaciones no han sido eliminadas por cuestiones de anomalías o indicios maliciosos, sino que pueden existir otra serie de factores que lo justifiquen, como la caducidad de la licencia del desarrollador. Por tanto, no se puede correlar, a partir de este estudio que ser un caso atípico sea un claro indicio de que la aplicación sea maliciosa, sino que en la mayoría de los casos de aplicaciones eliminadas viene provocado por el abandono de la app.

Colaboración

Ambos TFMs ofrecen unos resultados centrados en sus procedimientos, expectativas y objetivos científicos, los cuales han demostrado ser herramientas útiles para realizar determinados procesos exploratorios y de análisis. Pese a abordar la problemática de las anomalías y el malware en Android de forma muy tangencial y acotada, sus investigaciones han sido valiosas tanto para sus perfiles profesionales, como para sembrar el germen de futuros proyectos, más ambiciosos y amplios que podrían culminar unas propuestas de valor impactantes y alineadas con las cuestiones de mercado. ElevenPaths continuará apoyando estas iniciativas y siempre que podamos colaborar de forma más activa en los proyectos y ayudar a reforzar los proyectos con una visión privada y más curtida en ciberseguridad.