Android DroidDream Uses Two Vulnerabilities

Document Sample
Android DroidDream Uses Two Vulnerabilities Powered By Docstoc
					We are pretty busy these days with malicious samples on Android. You probably haven’t missed
DroidDream (Android/DrdDream.A!tr) which trojaned several applications on the Android Market and
several blog posts on the matter:

Lookout explains how the malware was discovered, which applications it targets and whether you
should be concerned or not. By the way, we thank them for sharing samples with us.

AndroidPolice explains the malware uses the rageagainstthecage root exploit, and that malicious
applications have been pulled out of the market

Kaspersky reminds the dark sides of the Android Market and iPhone jailbreaking

AegisLab explains the malware uses JNI and collects /proc information (the sample they analyze is
slightly different from the one we refer to in this post).

But there are still a few additional questions – that I intend to cover in this blog post.

DroidDream does not use ONE vulnerability but TWO

In the sample we analyzed, those files are located in the asset directory of the package:

$ ls -al

-rw-r--r-- 1 axelle users 15295 Jan 14 11:04 exploid

-rw-r--r-- 1 axelle users 3868 Jan 14 11:04 profile

-rw-r--r-- 1 axelle users 5392 Jan 14 11:04 rageagainstthecage

-rw-r--r-- 1 axelle users 14076 Feb 15 14:59 sqlite.db

drwxr-xr-x 4 axelle users 4096 Mar 2 11:04 www

exploid corresponds to this local root exploit, and it is tried in case rageagainstthecage does not work.
The idea behind rageagainstthecage create many processes, reach the maximum limit of user processes,
so that the next time the adbd process is run it cannot surrender its root permissions. Both files are local
root privilege escalation exploits. Below, the logs show exploid was called but failed on my android

W/System.err( 246): Error running exec().

Commands: [/data/data/com.droiddream.bowlingtime/files/exploid,

/dev/block/mtdblock1, yaffs2] Working Directory: null Environment: null

D/AudioSink( 31): bufferCount (4) is too small and increased to 12

W/MediaPlayer( 240): info/warning (1, 44)
W/System.err( 246):     at java.lang.ProcessManager.exec(

W/System.err( 246):     at java.lang.Runtime.exec(

W/System.err( 246):     at java.lang.Runtime.exec(

W/System.err( 246):     at java.lang.Runtime.exec(

W/System.err( 246):     at

W/System.err( 246):     at

W/System.err( 246):     at

profile is a shell – we will talk about this one later. sqlite.db actually isn’t a SQLite database but an
Android package named the malware will install on the
infected device. Finally the www directory contains the real assets (images) used by the real foreground
application (e.g bowling game).

DroidDream posts the victim’s IMEI, IMSI etc – but no need to root a phone to do that

One of the first things the malware does is post the phone’s IMEI, IMSI, Android version to a remote
website whose URL is XOR encrypted. The key is hard-coded in another class, named Setting.class. A
little bit of Java decompiling and copy/paste in a quick n’ dirty standalone program, and we decrypt the
The information is posted (HTTP POST) using the XML format:

<?xml version="1.0" encoding="UTF-8"?>








 <Modle>YOUR DEVICE SDK</Modle>



Posting the IMEI, IMSI etc is not the real goal of the malware, since you do not need to root the phone
for that, but only the READ_PHONE_STATE permission.

A r00t shell – that’s awesome (from a malware author’s perspective! )

It seems that what the malware author really wanted to install is the profile binary (see above, in the
assets directory). Once the phone is rooted, the malware copies profile to /system/bin/profile and sets
root permissions to the file:

chown 0.0 /system/bin/profile

chown root.root /system/bin/profile

chmod 6755 /system/bin/profile

Actually, the /system/bin/profile file also acts as an r00ted indicator: if the file exists, the phone has
been rooted, if not, the malware tries to root the phone. So, as a quick hack, some developers suggest
to create a dummy /system/bin/profile on your phone and be immune to the malware (more exactly the
malware won’t be able to operate).

A quick analysis of profile with a disassembler shows this executable merely does a setgid, then a setuid,
and finally executes (excv) a shell. The malware author installed a root shell on the infected device. But
so far, this shell is not used remotely.
To me, it looks more like the work of a (dark) hacker than what cyber-criminals usually do. Unless the
next step is to download a malware upgrade (via the downloads manager package) and monetize this
root shel.

Shared By: