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 emulator:

W/System.err(  246): java.io.IOException: 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(ProcessManager.java:196)

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

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

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

W/System.err( 246): at com.android.root.udevRoot.runExploid(udevRoot.java:134)

W/System.err( 246): at com.android.root.udevRoot.go4root(udevRoot.java:230)

W/System.err( 246): at com.android.root.Setting.onCreate(Setting.java:265)

profile is a shell – we will talk about this one later.

sqlite.db actually isn’t a SQLite database but an Android package named

com.android.providers.downloadsmanager 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 URL:

The information is posted (HTTP POST) using the XML format:

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

<Request>

<Protocol>1.0</Protocol>

<Command>0</Command>

<ClientInfo>

<Partner>502</Partner>

<ProductId>10011</ProductId>

<IMEI>YOUR IMEI</IMEI>

<IMSI>YOUR IMSI</IMSI>

<Modle>YOUR DEVICE SDK</Modle>

</ClientInfo>

</Request>

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 shell…

Thanks to David Maciejak for his help on Android vulnerabilities.

– the Crypto Girl

Author bio:

Axelle Apvrille's initial field of expertise is cryptology, security

protocols and OS. She is a senior antivirus analyst and researcher for

Fortinet, where she more specifically looks into mobile malware.

Ελπίζω ότι θα το βρείτε ιδιαίτερα χρήσιμο.