Malware RootSmart para Android

Análisis de malware

Malware RootSmart para Android

10 de febrero de por Quequero

Resumen

La creciente popularidad de Android, combinada con la posibilidad de crear mercados alternativos, hace de esta plataforma un terreno fértil para los autores de malware. Si bien la mayoría de estas aplicaciones simplemente aprovechan la inexperiencia del usuario promedio que busca software gratuito, otras son bastante inteligentes y utilizan técnicas más sofisticadas para tomar y mantener el control de los dispositivos infectados.

Últimamente me llamó la atención que un nuevo malware estaba aprovechando el famoso exploit GingerBreak para obtener privilegios de root en teléfonos infectados. RootSmart, el nombre que le dieron al malware las personas que lo identificaron primero, es la segunda aplicación encontrada en la naturaleza que utiliza un exploit (la primera fue GingerMaster detectada en agosto de).

¡Conviértete en un ingeniero inverso certificado!

Obtenga capacitación práctica en vivo sobre análisis de malware desde cualquier lugar y conviértase en un analista certificado de ingeniería inversa. Comienza a aprender

¡Conviértete en un ingeniero inverso certificado!

Obtenga capacitación práctica en vivo sobre análisis de malware desde cualquier lugar y conviértase en un analista certificado de ingeniería inversa. Comienza a aprender

RootSmart es en realidad, bueno… inteligente, más o menos. El exploit no está integrado en el paquete, probablemente en un intento de parecer menos sospechoso para los sistemas antivirus, sino que se descarga desde un servidor web remoto junto con otros paquetes maliciosos. Además, se utiliza un poco de criptografía para disuadir al analista de realizar ingeniería inversa en la aplicación.

Vamos a profundizar en.

Información de la aplicación

La muestra que pude recuperar tiene los siguientes parámetros:

Al momento de escribir este artículo, la tasa de detección en VirusTotal es 8/43 (identificada como Android.RootSmart o Android.BMaster).

Análisis manifiesto

Android necesita recopilar información esencial de cada aplicación antes de que el sistema operativo subyacente pueda ejecutarlas. Esta información se almacena en el archivo de manifiesto y ahí es donde comenzaremos nuestro viaje.

En primer lugar, tendremos que descomprimir el .apk y transformar el manifiesto de XML binario a una versión legible. Para hacerlo usaremos una herramienta realmente útil llamada android-apktool ( http://code.google.com/p/android-apktool/ ).

Escriba el siguiente comando:

[código fuente]java –jar apktool.jar d .nombre de apk directorio de destino
[/código fuente]

Después del procesamiento, encontraremos nuestro archivo de manifiesto en el directorio de destino, junto con un desmontaje completo de todo el archivo .dex . Nos ocuparemos de eso en un momento, por ahora centrémonos en el manifiesto:

Vemos que la aplicación requiere muchos permisos; esto ya debería alertar al usuario de que algo anda mal. Algunos de ellos son requeridos por cualquier proveedor de sincronización (WRITE_SYNC_SETTINGS, GET_ACCOUNTS, etc.), pero otros son más interesantes.

Este paquete quiere acceder a Internet, aparentemente incluso activando el Wi-Fi directamente (CHANGE_WIFI_STATE). También está interesado en nuestra posición exacta (ACCESS_FINE_LOCATION), pero lo que debería llamar nuestra atención inmediata son dos permisos: MOUNT_UNMOUNT_FILESYSTEMS y READ_LOGS. La aplicación grita: “¡Oye, quiero ejecutar GingerBreak!” El exploit necesita acceso al archivo de registro para poder recuperar la dirección donde vold falló; esta misma dirección se usará más adelante para sobrescribir el GOT. Además vemos que se requiere el permiso RECEIVE_BOOT_COMPLETED, esto realmente suena como un servicio de arranque listo para ejecutarse cada vez que encendemos nuestro teléfono.

Aún no hemos terminado. Una parte importante del análisis es identificar los oyentes asociados a cada intención; del manifiesto entendemos que:

Hemos podido identificar al menos los datos que le interesan al malware y dónde se gestiona. Con una imagen más clara ahora estamos listos para proceder con el análisis de la aplicación.

Instalación

Enciende tu emulador e instala la aplicación. Existen principalmente dos formas de proceder, la primera es con una instalación directa a través de ADB:

[código fuente]adb instalar sospechoso.apk[/código fuente]

La segunda es descargando e instalando el paquete como lo harías con cualquier otra aplicación. En este caso también podremos comprobar directamente los permisos requeridos:

Esto ya debería sonarte: se requiere más o menos permiso. Tenga en cuenta también que utiliza el mismo icono de “Configuración” que viene con la aplicación original. La principal diferencia es que su nombre estará en chino. No tiene nada de malo; sin embargo, este malware está dirigido específicamente al mercado chino.

Al intentar abrir la aplicación, aparecerá la siguiente ventana de la aplicación original:

El programa principal es claramente legítimo, reempaquetado con un servicio de arranque malicioso. Sabemos que no existe una forma “oficial” de ejecutar un servicio de arranque inmediatamente después de la instalación del servicio, por lo que el programa tiene que “conectarse” a algún evento para poder iniciarse. El primero será BOOT_COMPLETED. Podemos ver en el manifiesto que esta intención se administra desde la clase com.google.android.smart.BcbootReceivecr . En este punto tenemos suficientes elementos para poder comenzar nuestro análisis de código.

Análisis de código

Necesitamos desmontar la aplicación para poder analizar el código. Para esta tarea usaremos tres útiles herramientas: dex2jar, JD-GUI y Baksmali . La primera herramienta se utiliza para convertir el archivo .dex en un paquete .jar , la segunda es un descompilador, utilizado para reconstruir el código fuente de Java, la tercera es un desensamblador que puede convertir el archivo .dex en un archivo legible por humanos ( algo así) código Dalvik. Si se pregunta por qué deberíamos usar un desensamblador cuando tenemos un descompilador con todas las funciones, aquí está la respuesta: JD-GUIEs realmente útil, pero desafortunadamente aún está en desarrollo. Por este motivo sigue siendo fácil de engañar (a propósito o por casualidad) y no podremos utilizarlo para un análisis completo y completo.

Primer paso: convertir el .apk a un paquete .jar :

[código fuente]dex2jar sospechoso.apk
[/código fuente]

Segundo paso: ábrelo usando JD-GUI :

Ahora es obvio que estamos tratando con tres paquetes: el malware com.google.android.smart , la aplicación legítima com.bwx.bequick (se llama QuickSettings en el Android Market original) y otro paquete simplemente llamado ( lo más probable es que sea una biblioteca importada utilizada para gestionar solicitudes SOAP ).

Examinemos la clase que trata con la intención BOOT_COMPLETED. Afortunadamente para nosotros, esta parte ha sido descompilada correctamente:

El paquete comprueba si la aplicación está en estado de “hibernación”. Si no es así, inicia el servicio desde McbainServicce.class , vigila setAction() y luego pasa a la clase que gestiona la creación y destrucción del servicio:

¿Que esta pasando aqui?

En orden:

Las preferencias se almacenan en dos archivos XML: mms_localinfo.xml y mms_settings.xml . Todos ellos están en texto claro y se pueden recuperar fácilmente. La acción enviada a la clase “administrador de acciones” ejecuta el siguiente código:

Los nombres están confusos, pero no es malo. Después de todo, los nombres sin sentido son mejores que los nombres engañosos. Entonces el código nos dice que está configurada una alarma de 1 minuto. Después de 1 minuto se transmitirá una nueva acción “action.check_live”. Esta función, adivina qué… hace algo interesante:

Entre otras cosas, se compara la versión del sistema operativo con “2.3.4” y luego se verifica la existencia de un archivo llamado shells . ¿Para qué? Aparentemente se ejecuta un exploit, al menos a juzgar por el nombre dejado en el código. La clase llamada f establece los permisos correctos en el archivo, lo ejecuta a través de McbainServicce.class Boolean a(String) y luego realiza una limpieza:

Eso es inteligente. De esta manera, el malware puede instalar su propio shell en el sistema y luego puede usar el acceso raíz para instalar silenciosamente otros paquetes. Hasta el momento no tenemos rastros de un exploit integrado en el paquete, por lo que concluimos que el exploit se descarga desde algún servidor.

¿Donde exactamente? Sólo necesitamos regresar donde la aplicación verifica la existencia del archivo “shells”. Si no se encuentra este archivo , se llama al método i.(this.a).a() , pero no es posible explorar esta función usando JD-GUI porque no fue capaz de descompilarlo.

Eso no nos detendrá: simplemente desmontemos el paquete usando Baksmali . Abra el paquete .apk con cualquier compresor de archivos y extraiga el archivo Classes.dex , luego:

[código fuente]java –jar –a 8 clases.dex –o baksmalied
[/código fuente]

Ahora podemos abrir el archivo i.smalli para comprender qué hace el método a() . Esta es una versión simplificada del desmontaje original:

Se traduce aproximadamente como: verifique la existencia de “shells”, si no puede encontrarlos, cree la URL de esta manera:

[código fuente]Cadena url = “/androidService/” + “resources/commons/shells.zip”
[/código fuente]

En realidad no es una URL. Nos falta la dirección ¿verdad? La dirección se extrapola del siguiente recurso sin formato: res/raw/ data_3 . El contenido binario es el siguiente:

ED04FB6CD722B63EF117E92215337BC7358FB64F4166F4EC40C40D21E92F9036

Claramente no es una URL de texto plano, y de hecho tenemos razón, se trata de un texto cifrado que se descifra dentro del método String sa().

A todos nos encantan los códigos de operación de Dalvik, ¿verdad? En realidad no, pero esta vez no tenemos excusas, JD-GUI no nos está ayudando y, a menos que tengamos un motor criptográfico completo integrado en nuestro cerebro, tendremos que hacer algo de descompilación a la vieja usanza. El código de bytes original se ve así (se muestra solo en parte):

Después de analizar cada línea cuidadosamente, podemos reconstruir el código fuente original, que es exactamente:

Después de reescribir el código, es posible ejecutarlo para recuperar la URL original.

Vale la pena dedicar un par de palabras a esta parte del código: tenemos que recuperar el exploit de un servidor web, pero la URL no está clara. Hay un archivo de recursos cifrado. La clave de cifrado no está codificada, pero se genera en tiempo de ejecución… ¿Cómo? Un generador de números pseudoaleatorios basado en SHA1 se inicializa utilizando una semilla almacenada en el manifiesto. Puedes verlo a continuación:

Del desmontaje encontramos que se recupera el parámetro “package_id” y se utiliza para alimentar el PRNG. El resultado se utiliza para inicializar la clave de 128 bits utilizada por un cifrado AES y, en última instancia, se utiliza para descifrar la URL que resulta ser: go.docrui.com. Nuestro camino final es:

http://go.docrui.com/androidService/resources/commons/shells.zip

Este fue un movimiento inteligente por parte de los autores. Hicieron un poco más difícil la ingeniería inversa de la aplicación usando este truco. Después de recuperar el archivo usando la clase v que maneja todas las solicitudes HTTP estándar, su hash MD5 se verifica dentro de ia():

cadena constante v3, “6bb75a2ec3e547cc5d2848dad213f6d3”

Después de recuperar el archivo y verificarlo, este mismo paquete se descomprime del método sa(String, String) y los archivos resultantes se usan en consecuencia. El paquete contiene tres archivos:

Si bien GingerBreak es bien conocido y está documentado, es interesante echar un vistazo a los guiones. Empezamos desde la instalación :

El script se utiliza para volver a montar el sistema de archivos en modo lectura-escritura y luego se crea un nuevo directorio: /system/xbin/smart . Dentro del nuevo directorio se crea un shell raíz. Luego, el sistema de archivos se vuelve a montar en modo de solo lectura. El script de instalación de la aplicación se ve así:

En este caso tenemos un script auxiliar que puede escribir un archivo en cualquier lugar otorgándole el modo +s. Este mismo proceso se lleva a cabo no sólo cuando el teléfono se está iniciando, sino incluso después de realizar una llamada telefónica. El malware utiliza esta técnica para tener otra oportunidad de iniciarse antes de que el usuario reinicie el teléfono.

Cadena de acciones

RootSmart es capaz de manejar una variedad de acciones, todas ellas enviadas vía web desde el servidor CC. ¿Cuáles son sus capacidades? Hagamos un resumen rápido de todos los comandos disponibles:

Cada acción se gestiona desde la clase principal McbainServicce y a partir de cada acción recibida se inicia un nuevo hilo. ¿Qué pasa con los otros receptores que hemos extraído del manifiesto? Revisémoslos rápidamente:

Por supuesto, algunas clases más se utilizan para gestionar solicitudes de servidor web o instalación de paquetes. Si estás interesado en los detalles técnicos, te daré algunos consejos:

Tráfico de red

Ahora es el momento de dejar que el malware se ejecute, por supuesto, mientras se registran las solicitudes de tráfico realizadas por la aplicación. Podemos optar por reiniciar el teléfono o iniciar una nueva llamada telefónica; En cualquier caso, notaremos que lo primero que se envía por Internet es una solicitud SOAP que contiene algunos datos interesantes:

Aunque a nadie le gusta SOAP, tendremos que lidiar con ello. La primera solicitud es una especie de paquete de identificación, que envía al servidor remoto los siguientes datos: IMEI, IMSI, versión del sistema operativo, CID, LAC, MNC (información de la torre celular), estado de enraizamiento y cierta información sobre el malware en sí, incluso su propia versión. , lo que podría indicar que el paquete podría actualizarse de forma remota. Toda esta información es adquirida por la clase g() :

Una nota curiosa: verifique el User-Agent utilizado para enviar las solicitudes…

La respuesta del servidor es:

At this point the backdoor will connect back to the server, at regular intervals, to receive commands.

From the capabilities found during the analysis we know that the application is able to download and install additional malware packages. If you’re willing to, you can keep monitoring the traffic, until some action is sent from the server.

From what I’ve seen, DroidLive is downloaded, but this is subject to change and it all depends on the settings set by the CC server owners. One hint: try to connect using a Chinese proxy. Foreign phones don’t seem to gain a lot of attention from the server guys. And it makes sense if the malware downloaded after the first run does premium-SMS sending to Chinese numbers.

Conclusions

The code is similar to Android DroidLive malware in many parts, except for the fact that a lot of features are not present. Most likely this application is a stripped-down DroidLive with exploiting capabilities used as a first stage infector to open the gate to other malware. Currently the botnet behind RootSmart seems to be quite large. According to Symantec (http://www.symantec.com/connect/blogs/androidbmaster-million-dollar-mobile-botnet) between 10.000 and 30.000 devices seem to be active.

So my advice is, of course, to pay attention to what you download, always use an official market (even though official doesn’t always equal secure), be careful with required permissions and, if possible, keep your phone up to date and… Unrooted ;-).

Agregue un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *