Archive for the ‘Android’ Category

Our Android Malware Summary for the Year 2013

Friday, February 21st, 2014

In 2013 our Mobile-Sandbox analyzed over 150,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 a bunch of malicious and unwanted applications belonging to 44 different and newly discovered malware families.

Most of these malicious applications had been downloaded from Third-Party markets, but we also found 4 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:

Characteristics Share in 2013 Difference to 2012
Families that steal personal information 61,4 % + 10,1 %
Families with characteristics of a Botnet 25,0 % + 1,5 %
Families that send premium rated SMS messages 18,2 % - 11,9 %
Families that install additional applications 11,4 % + 1,0 %
Families downloaded from the Google-Play Market 9,1 % - 2,2 %
Families that contain Root-Exploits 9,1 % - 9,2 %
Families that steal location related data 9,1 % + 0,4 %
Potentially unwanted applications 9,1 % + 1,3 %
Online-Banking Trojans 6,8 % + 3,3 %
Families which are able to infect a connected Windows PC 4,5 % + 4,5 %
Commercial Trojans or Spy-Kits 2,3 % + 2,3 %

More than 60% 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. This kind of threat has increased by more than 10% as compared to 2012.

Last year´s second most common threat -- sending premium rated SMS messages -- has lost nearly half of its share within newly discovered malware families. We assume that it has to do with the security features of Android 4.x as well as the awareness of telephony and service providers.

The most dangerous malicious samples are those 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 9 % of the 44 new malware families (which is also half as common as compared to 2012).

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. In 2013 it went up to 6,8 % of newly analyzed malware families. This kind of malicious Android apps are extremely dangerous: If the computer and the smartphone of an online banking user are infected with this kind of malware, the attacker can modify each transaction without the knowledge of the infected user.

There were two newly discovered kinds of malware in 2013: Commercial trojans/spy-kits (which are -- more or less -- legally sold on the Internet) and trojans that are able to infect a connected Windows PC. Both kinds of malware were distributed very seldomly with only 2 - 5 %.

With Android.Chuli we have also seen the first publicly known targeted attack where Android smartphones were involved as main entity in the attack.

ContrOWL: A new security app based on crowed intelligence

Thursday, February 7th, 2013

ContrOWL

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!

Get it on Google Play

Our Android Malware Summary for the Year 2012

Wednesday, January 2nd, 2013

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.

[UPDATE] Current Android Malware

Saturday, December 8th, 2012

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.

Comparison of Dalvik and Java Bytecode

Monday, August 27th, 2012

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.