Buscando malware en aplicaciones Android

Después de la estupenda charla de ayer de AppInBilling en el GTUG-Barcelona, me motive a hacer el pequeño experimento narrado a continuación . No tenía muy claro que esperaba conseguir, pero quería probar un vector de testing bastante interesante.

La idea consiste en automatizar un mismo proceso sobre muchos elementos diferentes, obteniendo así mucha información en la que poder grepear y llevarte sorpresas. En este escenario, los elementos son las aplicaciones APK y el proceso es la herramienta apktool.

Etapa 1. Descargando aplicaciones

El sitio más usual para descargar APKs sería el propio Market oficial, pero también hay sitios como http://www.malwaredump.com/ que pueden resultar muy interesantes para este experimento.

Yo encontré freewarelovers.com con Google, y aún sin saber muy bien que tipo de aplicaciones me encontraría, decidí apostar por él. Saqué el patrón para descargar todas sus aplicaciones automáticamente y, aunque hay que hacer 3 peticiones por aplicación, la base de datos son sólo unas 1.670 aplicaciones. El script os lo dejo a continuación:

<?php

ini_set('max_execution_time', 60*60 ); // 1 hora

mkdir('apk');

$pid = pcntl_fork();

if ($pid == -1)
{
die('could not fork');
}
else if ($pid)                        // padre
{
pcntl_wait($status);             //Protect against Zombie children
}
else                                 // hijo
{
$ch = curl_init();
$dl = strtolower(implode('|', glob("apk/*")));

$defaults = array(
CURLOPT_HEADER            => FALSE,
CURLOPT_NOBODY            => FALSE,
CURLOPT_RETURNTRANSFER    => TRUE,
CURLOPT_AUTOREFERER        => TRUE,
CURLOPT_USERAGENT        => 'Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20100101 Firefox/6.0.1',
CURLOPT_FOLLOWLOCATION    => TRUE,
CURLOPT_MAXREDIRS        =>  5,
CURLOPT_CONNECTTIMEOUT    => 30,
CURLOPT_TIMEOUT            => 30,
CURLOPT_SSL_VERIFYPEER    => FALSE,
CURLOPT_SSL_VERIFYHOST    => FALSE,
CURLOPT_COOKIEJAR        => tmpfile(),
CURLOPT_VERBOSE            => FALSE,
CURLOPT_CUSTOMREQUEST    => 'GET',
);

$cats = array(
'/communications',
'/entertainment',
'/finance',
'/games',
'/health',
'/multimedia',
'/news',
'/productivity',
'/reference',
'/shopping',
'/sports',
'/system',
'/travel' );

foreach($cats as $cat) {

// descargar lista unica de aplicaciones por categoria
$defaults[CURLOPT_URL] = 'http://www.freewarelovers.com/android/category'.$cat;
curl_setopt_array($ch, $defaults);
$body = curl_exec($ch);

preg_match_all('|"/android/app/([\w\|-]+)"|', $body, $matches);

$apps = array_unique($matches[1]);

foreach($apps as $app) {

if (trim($app)=='') continue;
if (strpos($dl, strtolower($app))) continue;

// consultar el enlace de descripcion de la aplicacion
$defaults[CURLOPT_URL] = 'http://www.freewarelovers.com/android/app/'.$app;
curl_setopt_array($ch, $defaults);
$body = curl_exec($ch);

preg_match_all('|"/android/download/temp/(.*).apk"|', $body, $matches);
$nameApp = substr($matches[1][0],11);
if (trim($nameApp)=='') continue;
if (file_exists('apk/'.$nameApp.'.apk')) continue;

// conseguir el enlace directo a la aplicacion (no-hot-link)
$defaults[CURLOPT_URL] = 'http://www.freewarelovers.com/android/download/temp/'.$matches[1][0].'.apk';
curl_setopt_array($ch, $defaults);
$body = curl_exec($ch);

preg_match_all('|http://www.freewarelovers.com/hotlinkmenot/(.*)\.apk|', $body, $matches);
if (trim($matches[0][0])=='') continue;

// descargar la aplicacion
$defaults[CURLOPT_URL] = $matches[0][0];
curl_setopt_array($ch, $defaults);
$body = curl_exec($ch);

file_put_contents('apk/'.$nameApp.'.apk', $body);
}
}
}
?>

Etapa 2. Decompilar aplicaciones

Una vez todas descargadas, fue cuestión de pasar otro script que las decompilara. Se puede sustituir por cualquier otro proceso como, por ejemplo, “unzip”, “dex2jar”, “jad” y “understand”. Yo decidí hacerlo facilito y usar directamente la herramienta “apktool”.

#!/bin/bash

cd apk2

for f in $( ls ../apk ); do
if [ ! -d "../apk2/${f//.apk}/" ]
then
java -jar ../apktool.jar decode "../apk/$f"
fi
done

Etapa 3. Buscando sorpresas

La parte costosa ya ha terminado, obteniendo así tantos directorios como aplicaciones procesadas. Ahora es momento de buscar patrones “curiosos”, “delicados” y “repetitivos”, como, por ejemplo, aquellas aplicaciones que tienen admob u otra librería.

Centrándonos en “malware”, he realizado la siguiente búsqueda:

grep 'const-string v[0-9], "http[s]*://.*"' * -r

Muchos webservices… muchos dominios rusos… muchos logins… os dejo un dump de la consulta anterior para que os recreéis.

http://dl.dropbox.com/u/7186726/dumpGrep.txt

Etapa 4. AndroidRisk

Visto que hay miga en esto, decidí terminar el experimento con la aplicación AndroidRisk del paquete AndroidGuard. Esta aplicación permite buscar en un directorio de ficheros APKs aquellos que potencialmente se parecen mucho a uno de los últimos virus/troyanos detectados para Android (por ejemplo, DroidDream).

Es lanzar el siguiente comando:

./androrisk.py -d ../apk/

Os dejo el dump también.

http://dl.dropbox.com/u/7186726/dumpRisk.txt

No sé hasta que punto fiarme de los resultados, pero todo apunta a que muchas de estas aplicaciones “tienen sorpresita”. (A más alto el número, más afinidad de ser maligno.)

Etapa 5. Fuzzing

¿Y sí cogemos todas las direcciones que se han extraido y se lanza una herramienta automatizada de intrusión web MUY básica? (Sql Injections, Path Traversal, Remote File Inclusion, Local File Inclusion, … ) Se puede montar una bonita botnet con la tontería… y no sólo eso… sino que cada webservice debe llevar asociada una base de datos de usuarios.

Despedida

Y esto sólo con ~1500 aplicaciones … 🙂

Sed buenos y cualquier duda ya sabéis donde estoy.

Buscando malware en aplicaciones Android

Your entire SDcard in my webhost ~ Proof Of Concept

Note: I do not care if you want to share or translate the document, but please, quote me ;) . Thanks!

Brief

I have developed a Application for Android which stoles the File List of the SD-Card of the victim.

I do not use any kind of special trick. That is the real problem.

What does the exploit need?

It only needs “Internet” permission, so it is very easy to use in malicious apps (and persuade the user to get into the trap).

How it works…

You can read by DEFAULT the files in the SD-Card, so you only have to read them and send into Internet. I have deployed a webservice in a webhost that I can manage to do this PoC.

Download it here: (pname:poc.SDCard)Proof of Concept - Stealing SD-Card with an Android application

Why am I doing it?

Because I care about your security. I want you that you will experiment HOW EASILY it is. And then…

1) Think twice what kind of information you have in your SDCard

2) Think twice what apps you allow 🙂 The 90% of apps use the “Internet” permission.

Where is the real problem?

The problem is that the Google Developers have say: “Do not store sensitive information into your SDCard! only shared data!” … but the application developers (like Dropbox, whatapps, your camera, …) does not care a bit and they save your files there.

First, the application developers SHOULD care about you. And second, you should care about YOURSELF. If they do not care about you, do not use them.

Can you show us the source-code?

Main function: (yeah… too easy)


private void getFiles(File F) {
 for (File t : F.listFiles()) {
  DATA.add(t.getAbsolutePath()+"\n");
  if (t.canRead() && t.isDirectory()) {
   getFiles(t);
  }
 }
}

Are you storing my data with this App??

Calm. I am only sending your File List (it is a slow app… I know… I did not use Threads) to my webhost. I do not want your data (I could have send it too :P). I promise you that I am going to remove all the uploaded files of the webhost… BUT…. you can delete it too. Just click the button that appears in the app.

Argg!! It goes really slow…

Yes, I know. It gets the list of files, it is put in a string, it is sent to the webhost, and then it shows you the screen…

I promise it works… so start deleting all your data of the SDcard right now ;-).

Special Note: Do you use CyanogenMod or another custom Rom? They save by default a backup of your data as *.img files. Do you know that they contain ALL YOUR DATA OF YOUR ACCOUNTS? It is overLOL!…(this image was taken when I was coding the app…)

cyanogen-mod backups in *.img files

Conclusion

Any application that you have stored could do it. I hope you will learn something about it. Use a sniffer to know what the fuck your apps are sending… (yeah… they could send the data by a SSL channel).

Greets!

and if you have any question, contact me, of course!!

Note: If you see any spell mistakes, you can say me it. I would appreciate it ;) . Thanks!

Your entire SDcard in my webhost ~ Proof Of Concept

Infectando aplicaciones Android

Note: I do not care if you want to share or translate the document, but please, quote me ;) . Thanks!

Resumen

Es posible infectar cualquier aplicación del sistema operativo Android hasta el próximo reboot del smartphone. Esto requiere de  una aplicación maliciosa con un exploit que de permisos root, es decir, se restringe a todo lo inferior a la Gingerbread (<2.3.x) que son más del 90% de dispositivos. Es la misma técnica que se utilizo con el DroidDream, pero en vez de crear nuevas aplicaciones e instalarlas, se aprovechan aplicaciones ya existentes.

DroidDream

El virus DroidDream ha sido el primero en cuestionar la seguridad en Android. Los pasos que hace son los siguientes:

  1. Se instala a través de varias aplicaciones de varios usuarios (unas 30 apps entre 3 usuarios).
  2. Estas apps, ejecutan 2 exploits: exploid y/o rageagainst-the-cage, obteniendo root.
  3. Aún si no se obtiene, se envia el IMEI, ISMI, version de Android, etc. a un webservice del atacante.
  4. Instala una nueva aplicación, la cual se encarga de robar más datos.

Se puede obtener mucha más información en esta dirección (y los enlaces a los que apunta): http://blog.fortinet.com/android-droiddream-uses-two-vulnerabilities/

Lo que interesa es preguntarse: ¿Porque instala una nueva aplicación?

Seguridad by Google y sistema de firmas

Google es capaz de borrar remotamente aplicaciones del móvil (por nuestra seguridad…). Dado que todas las aplicaciones tienen una firma única, Google puede dirigirse a cada una de ellas inequívocamente. Así que la razón por la que instalaron los atacantes una nueva aplicación externa fue justamente para que Google no conociera su firma y no pudiera borrarla.

Poco después, la comunidad XDA-Developers descubrió un parche, tan simple como crear el fichero “/system/bin/profile” a través de la shell. Más información en http://forum.xda-developers.com/showthread.php?t=977154

Volviendo atrás, cuando un programador crea una aplicación, utiliza una clave privada que certifica que esa aplicación es suya y no es modificable por nadie más. Es muy importante guardar bien esa clave privada fuera del alcance de malas manos, sino se puede refirmar una aplicación como si fuera original. Aún así, el sistema Android permite ejecutar cualquier aplicación firmada (hasta modo debug), donde firmada significa que el contenido de “/META-INF/*” que se encuentra en el interior del APK lleva todas las firmas de todos los ficheros incluidos en el APK y se corresponden los hashes SHA1-DIGEST. Un ejemplo:

ejemplo_metaInfEl sistema operativo comprueba en 2 ocasiones que los paquetes esten firmados:

  1. Cuando se INSTALAN del Market o de cualquier otro sitio (consola)
  2. Cuando se reinicia el sistema operativo comprueba que son validos, sino los desactiva

Entonces, ¿y si se mueve directamente a la carpeta de “/data/app/*.apk”? ¡Zas!

Reemplazando aplicaciones existentes

Para hacerlo divertido, vamos a hacer un ejemplo. (En esta ocasión, no explicaré como se hace reversing a aplicaciones Android, pero con apktool, dex2jar y el DDMS de Eclipse hay de sobras.)

Lo primero, escogemos una victima. La aplicación será la Esdeveniments, una cutre aplicación del PSC que sólo tiene un WebView.

  1. La instalamos en el smartphone
  2. La enviamos al pc a través del ASTRO Manager o del DDMS (obtened root en la shell con el OneClick)
  3. Renombramos el APK a ZIP
  4. Abrimos el ZIP, y reemplazamos los icon por calaveras y el main.xml lo editamos (ojo que tendréis que pasar de raw a ascii).
  5. Se vuelve a renombrar como APK, y con el DDMS, se hace push del fichero a /data/app/nombre_original.apk

El resultado es que, aunque el icono del escritorio no cambia (a excepción de volverlo a arrastrar y recrearlo), cuando se abre la aplicación:

Hay que acordarse que para hacer esto, se necesitan permisos root (hacer igual que DroidDream y ejecutar nativamente el exploit), pero se puede automatizar el proceso de forma muy sencilla para hacerse en TODAS las aplicaciones instaladas en el movil. Es muy facil desde una aplicación programar que abra un APK, lo examine, modifique el main.xml, un archivo *.so (si se trabaja con NDK), o cualquier otro recurso, y lo vuelva a empaquetar. Imaginad que hace esto que digo de infectaros todas las aplicaciones… y reiniciáis el móvil :D. Adiós a todas vuestras aplicaciones. (un geek podría volvérselas a poner, o usar el recovery, pero ¿¿acaso no llegarían quejas a los proveedores de móviles??)

Entonces, ¿qué?

La seguridad de Android reside EXCLUSIVAMENTE en no ser vulnerable a un exploit. Aunque aquí se haya mostrado que se puede infectar otras apps, también se puede reprogramar el sistema entero, instalando rootkits que no sois capaces de imaginar. Os animo a pedir a vuestros proveedores (movistar, vodafone, etc) que os ofrezcan las últimas actualizaciones del sistema operativo (GingerBread, 2.3.3), o sino, quien sabe si la próxima vez que abráis la aplicación de Gmail o Facebook sale mi cara 😀

Fe de erratas

Sin querer, aprete al botón de enviar mientras hacia pruebas.Lo siento…

…pude descubrir otra forma de debugging: provocando los errores a posta 😉

Infectando aplicaciones Android