DroidKungFu y los exploits RageAgainstTheCage y Exploid para Android

Resumen

La muestra analizada es de tipo troyano debido a que se hace pasar por una aplicación para jugar solitario mientras realiza otras actividades sin el consentimiento del usuario, como explotar vulnerabilidades e instalar aplicaciones adicionales o publicidad (adware). Este troyano pertenece a la familia de malware DroidKungFu, que se detectó en el 2011 y comenzó afectando aplicaciones en China. Las variantes de DroidKungFu tienen dos características importantes: utilizan exploits para escalar privilegios (conocidos como RageAgainstTheCage y Exploid) y estos están cifrados con AES. Sus acciones principales son: recolectar información del dispositivo para enviarla a servidores remotos, explotar una vulnerabilidad para escalar privilegios, instalar otras aplicaciones y recibir instrucciones de un C&C (aunque esta funcionalidad no pudo ser investigada debido a que los dominios fueron dados de baja).

 

 

Introducción

El rápido crecimiento y popularidad de Android ha provocado un aumento considerable de aplicaciones maliciosas desarrolladas para esta plataforma. El malware normalmente llega a un dispositivo móvil a través de una aplicación que ha sido descargada e instalada, ya sea por el usuario o por otra aplicación.
La mayoría de las variantes de DroidKungFu pueden ser encontradas en sitios web de venta de aplicaciones o en foros, aunque en los primeros años los atacantes se enfocaron en los usuarios chinos. El reporte de VirusTotal puede ser consultado aquí.

 

 

Análisis estático

Las aplicaciones en Android son en realidad archivos comprimidos con extensión "apk", aunque con una estructura específica. Esto se puede comprobar utilizando el comando file con la muestra, a la que en este caso se le asignó el nombre solitaire.apk.

 

Todas las aplicaciones deben tener un archivo AndroidManifest.xml en su directorio raíz. El archivo AndroidManifest.xml contiene información esencial para el sistema Android sobre la aplicación: describe los componentes de la aplicación, los permisos necesarios, lista las bibliotecas que la aplicación necesita, etc.

Cuando se compila una aplicación para Android, el archivo de manifiesto es convertido a formato binario.

 

 

AndroidManifest.xml

Después de decodificar el archivo de manifiesto para hacerlo legible, se puede observar que la aplicación solicita los siguientes permisos:

•      ·    INTERNET: Acceso a internet.
•      ·    READ_PHONE_STATE: Permite conocer el estado del teléfono.
•      ·    ACCESS_NETWORK_STATE: Conocer el estado de la red.
•      ·    ACCESS_WIFI_STATE: Conocer el estado del Wi-Fi.
•      ·    CHANGE_WIFI_STATE: Cambiar el estado del Wi-Fi.
•      ·    WRITE_EXTERNAL_STORAGE: Escribir en un dispositivo externo de almacenamiento, como la tarjeta de memoria.
•      ·    INSTALL_PACKAGES: Instalar aplicaciones.
•      ·    ACCESS_COARSE_LOCATION: Permite acceder a la ubicación aproximada.
•      ·    READ_SMS: Leer mensajes de texto.
•      ·    WRITE_SMS: Escribir mensajes de texto.
•      ·    RECEIVE_BOOT_COMPLETED: Recibir el mensaje de que el dispositivo ha terminado de encenderse.
•      ·    READ_EXTERNAL_STORAGE: Leer de un dispositivo externo de almacenamiento, como la tarjeta de memoria.
•      ·    ACCESS_FINE_LOCATION: Permite conocer la localización del dispositivo.
•      ·    ACCESS_LOCATION_EXTRA_COMMANDS: Acceso a comandos adicionales de localización.

 

Casi al final del archivo AndroidManifest.xml, en la etiqueta “activity”, se especifica la primera sección de código que se va a ejecutar al abrir la aplicación; que en este caso es “.Solitaire”.

 

A diferencia de las aplicaciones para Windows, los archivos apk pueden tener múltiples puntos de entrada que pueden ser activados por las acciones del usuario o por eventos del sistema. En este caso, la aplicación solitaire.apk está formada por cuatro actividades principales:

      -    La del juego de cartas .Solitaire

      -    com.google.update.Dialog

      -    cn.domob.android.ads.DomobActivity

      -    com.adwo.adsdk.AdwoAdBrowserActivity

 

 

También contiene un servicio, com.google.update.UpdateService, que se ejecuta en segundo plano y contiene el payload del malware, y un receptor, com.google.update.Receiver, que revisa si el dispositivo ha encendido (BOOT_COMPLETED) para después ejecutar el servicio antes mencionado.

Definido como meta-data está ST_START_DELAY que es utilizado por la aplicación para especificar el tiempo de retraso con el que el payload se ejecutará, es decir 1800 segundos o 30 minutos.  Y también ADMOGO_KEY con un valor de b2609a99a69045269897d92cc685d4b3.

El siguiente paso es convertir el archivo APK a un archivo JAR y continuar con su análisis.

 

Cadenas en otro idioma

Al analizar el código de la aplicación maliciosa se encontraron varias cadenas que Google Translate identifica como chino simplificado, como las que se muestran a continuación junto con su posible traducción:

请授权: Autorizar

确认: Confirmar

打开USB调试  : Depuración de USB

本软件: Software

需要root权限才能使用全部功能: Se requieren privilegios de root para utilizar la funcionalidad completa.

 

 

Adware

En el código decompilado, se pueden observar 4 paquetes: l, cn.domob.android, com y uk.co.lilhermit.android.core. Algunas de las clases con APIs de terceros que se encontraron dentro de estos paquetes son com.adwo.adsdk, com.madhouse.android.ads y com.admogo.adapters.com. Madhouse,Domob y Adwo son empresas de publicidad para dispositivos móviles que funcionan principalmente en China. De acuerdo con HKCERT, tanto Admogo como Domob aparecen como nombres de familias de malware debido a que instalan un plugin de alto riesgo y roban información del dispositivo para enviarla a un servidor remoto.  Admogo, en particular, tiene una clase para varias empresas de publicidad de distintos países, como se puede observar en la siguiente imagen.

Por otro lado, parece que lilhermit es un desarrollador de aplicaciones no maliciosas de Android, por lo que es probable que la clase Native de uk.co.lilhermit.android.core fuera copiada del código de otra aplicación o del repositorio de GitHub del autor para ser reutilizada con fines maliciosos.

  

 

 

Payload

El payload se encuentra en una clase llamada com.google.UpdateService para hacerse pasar como una actualización oficial de Google, de tal forma que parece ser legítima y benigna. Esta clase contiene las funciones para generar peticiones POST con información del dispositivo, ejecutar los exploits y, si estos tienen éxito, ejecutar las instrucciones enviadas por el C&C: execHomepage, execInstall, execStartApp, execDelete, execOpenURL, execSysInstall y execUpBin.

 

 

Exploits

El directorio assets/ contiene  varios íconos con imágenes PNG, además de cuatro archivos llamados foobin, init.db, newinit y rawicon de tipo “data”. Estos archivos están cifrados con AES y contienen, entre otras cosas, dos exploits que la aplicación maliciosa utiliza para escalar privilegios y poder instalar aplicaciones adicionales sin la intervención del usuario. Estos exploits son conocidos como: RageAgainstTheCage (CVE-2010-EASY) y Exploid (CVE-2009-1185).

 

 

Las aplicaciones normales, como las que se instalan a partir de Google Play Store, se almacenan en /data, que es la partición de Android donde se guardan los datos, configuraciones y archivos necesarios para el funcionamiento de las aplicaciones instaladas.

 

Las aplicaciones del sistema, como las que vienen preinstaladas en el dispositivo, se almacenan en /system y un usuario estándar de Android no puede instalar ni desinstalar nada debido a que no tiene permisos de escritura. Esta muestra de malware necesita ejecutar comandos como root para poder instalar otra aplicación.

 

La aplicación descifra con AES los archivos foobin, init.db, newint y rawicon utilizando la llave definida dentro de la clase com.google.update.RU.

 

 

Una vez que los archivos fueron descifrados, se descubrió que:

      -    El archivo foobin es un ELF (ejecutable para Linux) con el exploit CVE-2009-1185.

      -    El archivo init.db es un archivo Jar que parece ser una copia de la muestra con los mismos archivos foobin,newinit y rawicon también en el directorio assets/.

      -    El archivo newinit es un ELF con el exploit CVE-2010-EASY

      -    Y el archivo rawicon es de tipo data.

 

Los hashes md5, así como los reportes de VirtusTotal, se enlistan a continuación:

e789e154ad68e2cbb2d405220bc01529  foobin.decrypt

a6083f69ced5412b89a55658d33af175    init.db.decrypt

a6b6df55eb0404406f7b66879e34d581    newinit.decrypt

78437157c5d2df45be73caa5ed9b0a13  rawicon.decrypt

 

 

·         RageAgainstTheCage

La muestra hace uso de un exploit conocido como RageAgainstTheCage, que explota la vulnerabilidad CVE-2010-EASY, para escalar privilegios e instalar aplicaciones como usuario root. Este exploit crea procesos “zombie” hasta que la bifurcación de procesos realizada por la función fork() indica que se ha alcanzado el número máximo de procesos que el UID dado puede ejecutar (RLIMIT_NPROC) y falla. Posteriormente, el proceso padre del exploit detiene el proceso adbd, cuando éste se reinicia es ejecutado como root. Después de inicializar, sus privilegios pasan a ser los del usuario shell.

Durante el funcionamiento normal, setuid() disminuiría el conteo de los procesos del usuario root e incrementaría el conteo de procesos del usuario Shell; sin embargo, el número de procesos permitidos para el usuario shell está al límite por lo que setuid() falla y, debido a que no hay una validación para saber si la llamada a setuid() tuvo éxito o no, el proceso sigue ejecutándose como root. Esto provoca que al usar el comando “adb –d shell”, adb siga ejecutándose como root y por lo tanto se obtenga una terminal del usuario root.

Esta vulnerabilidad fue corregida en las versiones 2.3 y posteriores de Android.

 

·         Exploid

Al ejecutarse envía mensajes utilizando el protocolo NETLINK_KOBJECT_UEVENT, que fue diseñado para que los procesos escucharan eventos del kernel, no para enviar mensajes a través de él. Dado que en circunstancias normales sólo el kernel envía mensajes por medio de este protocolo, los otros procesos ejecutados con permisos de root asumen que los mensajes maliciosos vienen del kernel, ejecutándolos también con permisos de root. Esto se logra tan sólo creando un socket y especificando NETLINK_KOBJECT_UEVENT en el parámetro netlink_family. La ruta al exploit es indicada mediante un enlace simbólico en /proc/sys/kernel/hotplug, de tal forma que al ser invocado, se ejecutará con permisos de root.

 

 

Análisis dinámico

El ícono de la aplicación maliciosa ya instalada se puede observar en la siguiente captura de pantalla:

 

Cuando se ejecuta por primera vez se muestran las instrucciones del juego en inglés. Después, el juego de cartas inicia.

          

 

Tráfico de Red

Después de ejecutar la muestra comienzan en segundo plano las acciones maliciosas. Este tráfico de red está relacionado con la parte de adware de la muestra que, como se mencionó anteriormente, obtiene información del dispositivo para enviarla a un servidor remoto.

Primero se observan las siguientes peticiones GET relacionadas con Adsmogo:

 

·         cfg.adsmogo.com – 115.182.30.82

GET /GetInfo.ashx?appid=b2609a99a69045269897d92cc685d4b3&appver=275&v=1.0.3&client=2&pn=com.gp.solitaire&userver=461.0&adtype=2&country=us&nt=1&mno=310260&uuid=e8a1112658fdeb899033567722ef3e8c&os=2.2&dn=sdk&size=1280*768&cc=1&cm=418.61&ram=841176kb

 

·         req.adsmogo.com – 115.182.30.67

GET /exrequest.ashx?appid=b2609a99a69045269897d92cc685d4b3&nid=0bb038b07ad24026b5841d29805fbc35&type=33&uuid=e8a1112658fdeb899033567722ef3e8c&client=2&adtype=1&country=us

Los datos que recopila se explican a continuación:

 

cfg.adsmogo.com	req.adsmogo.com
appid = Identificador de la aplicación	appid = Identificador de la aplicación
appver = Versión de la aplicación	nid = Parámetro de AdsMOGO
v = Versión SDK de AdsMOGO	type = Parámetro de AdsMOGO
client = Parámetro de AdsMOGO	uuid = Identificador Universal Único del dispositivo
pn = Nombre de la aplicación	client = Parámetro de AdsMOGO
userver = Parámetro de AdsMOGO	adtype = Tipo de publicidad
adtype = Tipo de publicidad	country = País
country = País
nt = Tipo de red (1 móvil, 2 wifi)
mno = Operador de telefonía
uuid = Identificador Universal Único del dispositivo
os = Versión de Android
dn = Nombre del dispositivo
size = Tamaño de la pantalla
cc = procesador
BogoMips (medida relativa del desempeño del procesador)
ram = Memoria RAM

 

 

·         r2.adwo.com 42.62.76.8

Posteriormente realiza una petición POST donde se envían los datos del dispositivo en este orden:

         - “v” y “2” de propósito desconocido

         - Identificador del anuncio publicitario

         - IMEI, en este caso es 000000000000000 debido a que se usó un emulador

         - Modelo del dispositivo: unknown

         - Nombre del dispositivo: sdk

         - Número de celular: 15555215554

         - Nombre de paquete con la aplicación no maliciosa usada por el troyano: com.gp.solitaire

 

 

  

  

·         Otros dominios

También se observaron peticiones a appsrv1.madserving.cn/cr/394aff6985646490 (dirección IP 117.121.22.228), search.gongfu-android.com, search.best188.com y search.best188.net; sin embargo, esta parte del análisis ya no pudo continuar debido a que los dominios habían sido dados de baja. A partir de otros reportes sobre la familia de malware de la muestra, es posible deducir que los últimos tres dominios estaban relacionados con un C&C.

Por otro lado, también se encontraron otras URLs en las cadenas de la aplicación, como se puede observar en la siguiente imagen:

 

 

Otros enlaces recomendados                                                                          

Android/DroidKungFu uses AES encryption

Security Alert: New DroidKungFu Variant -- AGAIN! -- Found in Alternative Android Markets