RSS

Monthly Archives: June 2013

Finally a real Android Virus has been written (Backdoor.AndroidOS.Obad.a)

Ok….the title may sound abit far fetched but come on….a real Virus…a real android virus has been written. Not some bloated over hyped android mallware..A virus,a Russian Virus called Backdoor.AndroidOS.Obad.a. (Thats the package name really,not the icon launcher name or anything) This is going to be a technical post so lets get to it.

Backdoor.AndroidOS.Obad.a. is a multi-functional Trojan, capable of the following: sending SMS to premium-rate numbers; downloading other malware programs, installing them on the infected device and/or sending them further via Bluetooth; and remotely performing commands in the console. Reading more from both kaspersky and Avast as well as the IRC chats we have as android devs, I found out that it can also:
1.Send text messages. Parameters contain number and text. Replies are deleted.
2.PING specific IP pools
3 Receive account balance via USSD. and In fact manage to run STK apps (MPESA kwisha)
4. Act as proxy (send specified data to specified address, and communicate the response).
5. Connect to specified address (clicker).
6. Download a file from the server and install it.
7. Send a list of applications installed on the smartphone to the server.
8.Send information about an installed application specified by the C&C server.
9. Send the user’s contact data to the server.
10.Remote Shell. Executes commands in the console, as specified by the cyber-criminal.
11.Send a file to all detected Bluetooth devices.

The first thing with such an app is to off course see how the code is written, so you just extract the classes.dex file with any extract software (I use WinRar) the use the all famous DEX2JAR software to convert it to .jar that you can then use JD GUI to read the code. The creators of Backdoor.AndroidOS.Obad.a found an error in DEX2JAR ,this vulnerability spotted by the cybercriminals disrupts the conversion of Dalvik bytecode into Java bytecode, which eventually complicates the statistical analysis of the Trojan.
Backdoor.AndroidOS.Obad.a found an error in the Android operating system which relates to the processing of the AndroidManifest.xml file. This file exists in every Android application and is used to describe the application’s structure, define its launch parameters,permissions etc. The malware modifies AndroidManifest.xml in such a way that it does not comply with Google standards, but is still correctly processed on a smartphone thanks to the exploitation of the identified vulnerability.(Damn you Russians)

Backdoor.AndroidOS.Obad.a also used yet another previously unknown error in the Android operating system. By exploiting this vulnerability, malicious applications can enjoy extended Device Administrator privileges without appearing on the list of applications which have such privileges. As a result of this, it is impossible to delete the malicious program from the smartphone after it gains extended privileges.All the while Backdoor.AndroidOS.Obad.a does not have an interface and works in background mode.

The Virus Algorithm
1.Obtaining Privilages -Immediately after it starts, the application attempts to obtain Device Administrator privileges. Not to say privilages are bad,some of my apps do this also (In a good way) The malicious application cannot be deleted once it has gained administrator privileges: by exploiting a previously unknown Android vulnerability, the malicious application enjoys extended privileges, but is not listed as an application with Device Administrator privileges.


With the extended Device Administrator Privileges, the Trojan can block the device’s screen for up to 10 seconds. This typically happens after the device is connected to a free Wi-Fi network or Bluetooth is activated; with a connection established, the Trojan can copy itself and other malicious applications to other devices located nearby. This is how Backdoor.AndroidOS.Obad.a tries to prevent the user from discovering its malicious activity.It then attempts to obtain root privileges by performing the command “su id”

2.Communicating with the hacker
Once it has done this it waits for network and tells a remote server what it has done (If it has root and administrator privileges). If its running as root +admin privilages the remote commands can be sent to your device. (I have tried this and I can attest that it works)
The server then tells it iko sawa…Mission can go on..and it does the following send the following back to it as a JSON object (encrypted) to some scripts at http://androfox.com/:
1.MAC address of the Bluetooth device
2.Name of operator
3.Telephone number
4.IMEI
5.Phone user’s account balance (based on the operator I guess)
6.Whether or not Device Administrator privileges have been obtained
7.Local time

This information is sent to the current server every time a connection is established. In addition the malicious program reports its current status to its owner: it sends the current table of premium numbers and prefixes to which to send text messages (the “aos” parameter), the task list (“task”), and the list of servers. During the first C&C communication session, it sends a blank table and a list of addresses that were decrypted as described above. During the communication session, the Virus may receive an updated table of premium numbers and a new list of addresses.
In response, the server sends another JSON object which might look like this after decryption:

{“nextTime”:1,”conf”:{“key_con”:”oKzDAglGINy”,”key_url”:”3ylOp9UQwk”,
“key_die”:”ar8aW9YTX45TBeY”,”key_cip”:”lRo6JfLq9CRNd6F7IsZTyDKKg8UGE5EICh4xjzk”}}

NextTime is the next connection to a C&C server
conf are configuration strings.

Configuration strings can contain instructions to connect to new servers, tables of numbers with prefixes and keys with destinations for text messages, and new tasks with parameters. Besides, keys for traffic encryption (key_cip) may be sent to conf.

Backdoor.AndroidOS.Obad.a can also use text messages to control the Trojan. Configuration strings may also contain key strings (key_con, key_url, key_die) that the Trojan will look for in incoming text messages, and perform certain actions accordingly.

Each incoming text message is analyzed for the presence of any of these keys. If a key is found, the appropriate action is performed:

key_con: immediately establish a server connection;

key_die: delete tasks from the database;

key_url: connect to a new server. This instruction must be followed by the new C&C address. This way Backdoor.AndroidOS.Obad.a can create a new C&C server and send its address to infected devices in text messages containing this key. This will make all infected devices reconnect to the new server.

If a “send text message” instruction key is found in conf, the Trojan sends a message to the numbers provided by C&C Server. Thus, the infected devices do not even need to have an Internet connection to receive an instruction to send charged text messages.

C&C instructions

Backdoor.AndroidOS.Obad.a receives instructions from the C&C and records them in the sqlite database. Each instruction recorded in this database contains the instruction’s sequence number; the time when it must be executed, as ordered by C&C; and parameters.

The Code
All external methods are called via reflection. All strings are encrypted, including the names of classes and methods. Anyone who has Tried Reflection In Android will tell you its not easy. I should Know.

Each class has a local descriptor method which obtains the string required for encryption from the locally updated byte array. All strings are “hidden” in this array.

The most important strings containing the C&C address undergo an additional stage of decryption. For this, the Trojan first checks if Internet access is available, then downloads the page facebook.com. It extracts a certain element of that page, and uses it as decryption key. Thus, Backdoor.AndroidOS.Obad.a can only decrypt C&C addresses when Internet access is available. This feature further complicates the analysis of this piece of malware.
Some strings are additionally encrypted. The local decryptor receives a coded string in Base64 and decodes it. The decoded string is first decrypted with XOR operation with the MD5 of the key, then additionally decrypted with the MD5 of the string “UnsupportedEncodingException”. To obtain the MD5 of the key, the same local decryptor decrypts yet another string, which is then used as an argument for MD5. In this way, key strings, such as the name of the function SendTextMessage, are protected.

The strings one decrypted reslut in the following:

Advertisements
 
15 Comments

Posted by on June 18, 2013 in Uncategorized