My next class:

Mobile phone trojans

Published: 2009-07-01. Last Updated: 2009-07-01 13:16:40 UTC
by Bojan Zdrnja (Version: 2)
0 comment(s)

Couple of days ago one of our readers, Frank Wolff, sent a screenshot of an unsolicited message he received through ICQ. The message was full of garbled characters but included a link to a .JAR (Java ARchive).

The JAR file contained a malicious MIDlet, which is a Java program using the application framework for MIDP (Mobile Information Device Profile). This framework is normally used on mobile phones supporting Java (almost all phones today support Java).

As JAR files are actually just ZIP archives, it's trivial to unpack them. After unpacking a JAR archive, besides class files, the most important information is in the MANIFEST.MF file, in the META-INF directory. This file defines which class gets executed first and some other information. Below is the content of the extracted MANIFEST.MF file:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 1.5.0_09-b03 (Sun Microsystems Inc.)
MIDlet-1: foto,/icon.png,Midlet
MIDlet-Vendor: Sun Microsystems, Inc.
MIDlet-Version: 1.0
MIDlet-Name: foto
MicroEdition-Configuration: CLDC-1.0
MicroEdition-Profile: MIDP-1.0

The class called "Midlet" is the main class so that's where the analysis should start. Since Java uses bytecode, it is possible to decompile the class files into source files – these source files are not exactly what the developer wrote, but are close enough to allow us to analyze what's going on.

After starting, this particular Trojan created a thread which sent some SMS messages. The content and the numbers were obfuscated and stored in another file embedded in the JAR archive. The obfuscation algorithm was relatively simple (just logical AND with couple of other tricks). Finally, after all deobfuscation steps, the following text came out:

7122 vin 10199|*132 vis=10199|8.55 vis ,0199|83(5 vis 1-199|713/ vis 10,99|8355=vis 101$9|

The messages are separated with the "|" character, however it appears that the deobfuscation algorithm (or obfuscated data) had some errors. In any case, the Trojan tries to send 6 SMS messages as above.

However, after doing all this work, there are couple of questions that I still could not answer. First, I would be interested to hear from our readers if someone can confirm whether Trojans like this can send SMS messages from the mobile phone without any user interaction. If they can, then the overall risk is indeed higher.

If you can recognize numbers and/or messages above please let us know what the purpose of the Trojan is (probably make some money for the attacker).

As the Trojan was distributed as a link through ICQ messages, it's clear that another malware was used for this, since the Trojan analyzed here has no spreading capabilities. Does this imply that a lot of ICQ users use their mobile phones? Or the attackers are just blindly shooting.

Finally, AV detection was less than good with only 14 AV (out of 41) products detecting the JAR file successfully (VirusTotal). That being said, it's clear that the time when we will have to run AV programs on our phones is quickly coming.

UPDATE

We received quite a bit interesting submissions about this -- thanks to everyone who contributed.

It appears that the majority of mobile phones will allow an application (or an applet) to send SMS messages without the user controlling this process. Even if there are some controls around, the user is usually asked only first time when the application starts. This is indeed worrying since such malicious applications use a lot of social engineering to fool the victim. Karim wrote in to confirm this on un-managed BlackBerry phones as well -- while BB's require the code to be signed it appears that it is relatively easy to obtain code signing keys from RIM.

--
Bojan


 

Keywords: java mobile trojan
0 comment(s)
My next class:

Comments


Diary Archives