Fortinet Blog | News and Threat Research

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