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.

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!

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 rage-against-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 :D

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 ;-)

[SmartPhone] Chinese H6 (4 de 4)

El 10 lo recibo, el 14 ya me lo he cargado. Como se dice técnicamente, “lo he brickeado”.

- What The Fuck!

Resulta que estuve recopilando herramientas, roms, recoveries, recompile la 2.2.1 (froyo) del repositorio generico, mire como se dividia el sistema de imagenes interno, cogi root del  terminal, hice backups, y bueno, me decidi a reempacketar el `recovery.img´ y `boot.img´.

Iba a empezar por el recovery, pero no se porque, leí que si añadías una imagen `.rle´ como `initlogo.rle´ al boot.img, descompilando y recompilandolo, pues tenias tu imagen en el bootloader. (Más tarde recapacitaría y vería que esta se encuentra en una partición aparte, llamada “logo”, jeje.)

Este proceso de repacking, me dio algunos problemas con las tools del `Android Kitchen´, pero pude hacerlo manualmente con un editor hexadecimal y tenía buena pinta. Debía haber ya intuido algo malo, pero fui muy inocente.

- Entonces, ¿has intentado recuperarlo?

Sí, durante muchas horas, desde ayer, estoy intentándolo recuperar. Lo primero que intente es ir a través del recovery, (tecla volumen + mientras se enciende). Resulta que sólo hay una rom que parece que funcione, todas las demás abortan al instante. Esta que digo que parece, mueve un poco la barra de progreso (supongo que lo unico que hace es descomprimir el zip) y aborta también. Sin mensajes de error. Sin poder acceder al modo Factory (tecla volumen – mientras se enciende). Sin poder acceder al adb.

La solución que hay, y por eso los chinos la hablan tanto, es a través del cable USB-Serie. El manual ya lo colgué anteriormente, ahora dejadme pasaros el thread más interesante de los rusos que comenta como flashear desde 0 (¡¡son tan bestias que se han montado el cable a mano!! ¡olé por ellos!): http://forum.china-iphone.ru/viewtopic.php?f=31&t=10523

Esto me ha dado a descubrir algún nuevo foro que hablan de temas de electrónica (de MediaTek y sus circuitos, etc), y hasta un thread en XDA-Developers: http://forum.xda-developers.com/showthread.php?t=888884

¿Y porque no funcionan los recovery?

Tiene que ver mucho con la firma de los `update.zip´ que puedes pasarle al recovery, pero he intentado de mil maneras y no es posible.

Por lo visto, he escuchado que hay gente que hizo el “resetear a valores de fabrica” y se han quedado con el firmware corrupto o sin poderlo encender. Esto significa que el móvil, no esta pensado para “recuperarse desde casa”, y a cualquier mínima acción, peta.

La gente en XDA esta teniendo problemas también con el `recovery.img´.

¿Conclusiones?

Dado que a todo peta, hacer cosas a nivel de developer, esta muy jodido. Si hace nada os decia que este móvil era idioneo para gente que queria trastear, lo retiro, a excepción, de tener el clave PL-2303<>Jack (el usb-serie raro, llamado “universal manufacturer brush cable” o algo así) -> http://item.taobao.com/item.htm?id=8601529550

Pobre…

:-( . Seguramente intente pillarme alguna ganga decente por ebay para el día a día, y de mientras intentar conseguir este cable. De ser así, podre cargarmelo sin más preocupaciones (bueno, he leído que es posible que petes el móvil si le cambias la radio con esto).

—Para cualquier duda, ya sabéis donde contactar!—

Y eso es todo amigos. Después de prepararme una máquina virtual con todo lo referente a Android, me quedo en ascuas, jeje (rio por no llorar). ¡Pero tranquilos, ya habrá más temas guapos!

[Original -> March 15, 2011]

[SmartPhone] Chinese H6 (3 de 4)

Resulta que si escribimos el código: *#*#3646633#*#* en vez de un número de telefono, el terminal entra a la aplicación EngineerMode. Esta app esta creada por los de MediaTek y te permite configurar cosas extra del teléfono. Seguramente después de analizar todos los APKs del sistema encuentre más cosas ;)

[Original -> March 14, 2011]

Follow

Get every new post delivered to your Inbox.