Android’s Most Sophisticated Malware Ever! What Does it Mean to Me?

Android malware seems to be in the news a lot of late. So, I was intrigued when Malware researcher Roman Unuchek recently posted a blog article on securelist.com, Kasperskly Lab’s research blog on newly discovered Android Trojan Backdoor.AndroidOS.Obad.a also know as Obad.a.

I obtained sample of  Obad.a malware from Contagio. Thanks a ton to Mila Parkour for providing us with the access to the repository!  I  did some analysis on how this compares to ones I have analyzed in the past for our book on Android Security.  From preliminary analysis this seems to be more sophisticated than ones I have seen in the past. May be all the hype is correct – advanced malware that has come to Android.

This is a high level analysis of the malware for general public, IT admins and executives. It is not a discussion of code analysis or deep dive into malware functionality per se targeted at sophisticated users or malware researchers.

I followed methodology outlined in our book to analyze this malware.

Step 1: Review source/functionality of the application

In this case, we obtained malware through unofficial sources, which for a typical user would be a big no-no unless they explicitly trust the source. Once we obtained the sample, we decided to try it out. We will analyze functionality of the application a bit later in the article.

Figure 1 and 2 show permissions requested (from the end-user) during the install process. Figure 3 shows application installing on the device.  After application install process is complete, you should see ‘System’ in the application menu (Figure 4-7).

This slideshow requires JavaScript.

Step 2: Review permissions used by application

Second step in our methodology is to analyze permissions requested by application(from Manifest as well as package files on the device). Figure 8  shows permissions used by the application in the pacakges.xml file and figure 9 shows screenshot of AndroidManifest.xml file with requested permissions. As you can see, permissions requested are pretty exhaustive and should raise a red flag. Permissions requested range from sending/receiving SMS messages, Bluetooth administration, and access to personal data.

Figure 8 – Permissions used by application as listed in packages.xml file

Figure 9 – Permissions used by the application from AndroidManifest.xml file

Table below shows permission used by the application and their description:

Permission Name	Description
android.permission.SEND_SMS	Send SMS messages
android.permission.WRITE_EXTERNAL_STORAGE	Write to SDCard
android.permission.PROCESS_OUTGOING_CALLS	Monitor, modify or abort outgoing calls
android.permission.READ_LOGS	Access to log files
android.permission.WRITE_SMS	Write SMS messages
android.permission.ACCESS_WIFI_STATE	Get information on Wifi State
android.permission.RECEIVE_SMS	Get SMS messages
android.permission.CALL_PHONE	Place phone call without dialer interface
android.permission.READ_CONTACTS	Get contact information
android.permission.READ_PHONE_STATE	Access to phone state information
android.permission.READ_SMS	Read SMS messages
android.permission.RECEIVE_BOOT_COMPLETED	Receive ACTION_BOOT_COMPLETED
android.permission.BLUETOOTH	Connect to paired devices
android.permission.INTERNET	Connect to internet
android.permission.WRITE_SETTINGS	Read/write system settings
android.permission.CHANGE_WIFI_STATE	Change WiFI connections
android.permission.CHANGE_NETWORK_STATE	Change network connectivity state
android.permission.ACCESS_NETWORK_STATE	Access network connectivity state
android.permission.WAKE_LOCK	Keep processor from sleeping or screen from dimming

Step 3: Review Interprocess Communication (IPC) mechanisms used by the application

Third step in our methodology is to analyze IPC mechanisms used by the application. Let’s review Manifest.xml file for the malware application. Using apktool, we obtained manifest.xml file (see figure 10 and 11 below)

This slideshow requires JavaScript.

The application requests ‘BIND_DEVICE_ADMIN’ and defines intent-filter ‘DEVICE_ADMIN_ENABLED’ (see figure 12 and 13 below)

Figure 12 – Contents of AndroidManifest.xml file

Figure 13 – AndroidManifest.xml – DEVICE_ADMIN_ENABLED’ Intent Filter

Starting from Android 2.2, there is support for enterprise applications through Android Device Administration API. This API provides administration features at the system level. Application using this API can wipe out devices (remotely), enforce password policies and so on.  Use of Device Administration API requires Android’s Manifest file to include a subclass of DeviceAdminReceiver that includes BIND_DEVICE_ADMIN permission and responds to ACTION_DEVICE_ADMIN_ENABLED intents (by including it as an intent filter).

Thus we can conclude that the malware in this case tries to obtain device administration features on the device.

Step 4: Analyze code to review open ports, data shared/transmitted, socket connections, and so forth

In my book, I talk about importance of code obfuscation for developers since jar files can be decompiled. Jar file is collection of classes that can be decompiled to get source code and if not properly obfuscated, one can get a pretty decent idea of code/functionality.

Using dex2jar utility, I converted classes.dex (obtained by unzipping apk file) to classes.jar file. Figure 14 shows screenshot of different classes within the application using JD-GUI. As you can see, developers have done a great job at obfuscating the code and functionality. Simple de-compiling does not provide much help to understand malware under-pinnings and thus delaying analysis/response from security professionals once they discover the malware.

Figure 14 – Decompiling classes.dex file to obtain code

Conclusion 

1. This malware is available from non-official sources and hopes to propagate through non-trusted installations. It does not seem to be available on GooglePlay basically meaning that developers intended to propagate through other sources/secondary markets
2. Permissions requested by it are very broad (see the list above). Any application that requests such breadth of permissions should raise a red flag and be analyzed very carefully. It would be highly recommended for end-users not to install such applications unless they are sure of its functionality and source.
3. IT attempts to gain device administrator access – and access personal information resulting in basically complete ownership over the device.
4. Developers of this malware obfuscate code and thus preventing quicker turn around from security professionals hoping to reverse engineer it like other malware in the past.

---