Portals of the Undead on Android

Today, news and research about new malicious programs for the Android mobile operating system will surprise no one. But Google is taking certain steps to improve platform security (by the way, due to the accepted OS security model and the large fragmentation of OS versions, this is very difficult to do). And this, in turn, forces virus writers to take new steps to spread their creations.
In this article, I will look at the existing and already used malware distribution vectors for the Android OS. If interested, then I ask under the cat.

Introduction

At first, the Android malware simply abused the functionality available to them: they received unique device identifiers, geolocation coordinates, received the highest priority SMS messages, etc. And then they sent all this to their creator.
But today's latest news represents the entire RAT system (Remote Administration Tool), and some of them are already using the bootkit technology to hide it . These programs no longer exist under the Android security model, and they are elevating their privileges in the system through various vulnerabilities. After that, they are free to read / change data from other applications on the device, as well as system files - just like their fellow PCs. It can be said that evolution follows the exact same route.
')
The natural step was the emergence of antivirus software right in the app distribution stores. The logic of this step is clear - do not let users download malware. So, in 2012 Google Bouncer appeared on Google Play, and Yandex.Store, for example, has its own . Another problem of the Android OS is the abundance of various app stores , through which both simply stolen apps and malicious functionality can be distributed. The approach to the pre-moderation of all applications is different, and only two stores are well known that use automated scanning tools for malicious functionality. But they, as you know, are bypassed if desired.

About mobile antivirus

You need to understand that mobile antiviruses work on devices also within the framework of the Android security model - they do not receive any individual privileges. They work in their sandbox and can do with other applications and the system only what is provided for by the system and was allowed to them when they first started. In such conditions, it is difficult to fight malware, but antivirus can help with epidemics.

Verify apps

A new feature " Verify apps " appeared in Android 4.2. It is primarily useful for applications that are not installed from Google Play. So, with the option turned on, the system will warn you even before installation, if the application, in its opinion, has malicious functionality (perhaps this is behind the Google-bought service VirusTotal).

Portals

So let's move on to the malware distribution vectors. I must say, this is my personal view on the current picture of events. And if you have something to add here, then write in the comments.



1) From the store.

From the point of view of security, each Android store can be viewed according to two criteria:
• The presence of built-in antivirus in the store;
o However, do not take antivirus as a panacea.
• Is it a “trusted” source for your device:
o If the store is provided in the firmware as trusted, then any other store for the firmware will be an “untrusted” source and requires the installation of a special tick in the settings. As a rule, everyone wants to be the only app store on the device.

1.1) The virus writer has posted his malware to the store, and the user has installed it.

The most common scenario. The attacker either simply spreads his application with malicious functionality, or embeds it in someone else’s and also uploads - naturally, after disguising his bad functionality with obfuscation, time delays, etc. Then the user himself agrees, accepts the conditions and installs the application. Game over.

1.2) The virus writer laid out the application, which then, over time, downloads the malicious code.

You can even put in the store a good, non-malicious application, gain an audience, and then one day roll up the update and turn your users into an army of bots. Game over.
In this direction, I really liked the latest discovery by researcher Daniel Divricean. He found that the application with only 3 permissions:
• android.permission.INTERNET - allows an application to open network sockets;
• android.permission.GET_ACCOUNTS - gives access to the list of accounts in the Accounts Service;
• android.permission.USE_CREDENTIALS - allows an application to request authtokens from AccountManager, -
it is capable, without your knowledge, to install any applications, with any permissions (you can directly with everyone), on all devices linked to your account! Game over.

1.3) The virus writer bought / hacked a good application that already stands on millions of devices, and added malicious functionality to it with the update.

This is not a fantasy of a madman, but a sad reality . I think that with time this vector will become more and more popular. In this connection, the number of hacking / theft of developer accounts will increase. Game over.

2) From unknown sources.

To install the application from an unknown source in the Android OS, a user simply needs to put one checkmark in the settings menu.



2.1) The user himself put the application from somewhere.

Why does the user do this? Maybe 1000 and 1 reason, and consider them all stupid. The attackers themselves, often with the help of social engineering, are forced to put their application supposedly for safe work with RBS or for free Internet access in cafes, etc. In general, this vector is limited only by the imagination of the attacker and the stupidity / ignorance of his victim. Game over.

2.2) Computer infected with a virus that puts mobile malware on the device.

This vector is also real and quite original. True, of course, it has several conditions: permission to install from untrusted sources and permission to debug by ADB. But at the same time, everything happens transparently for the victim. Game over.

3) Through vulnerability.

No matter how surprising it looks, but Android leaves the possibility of the executable code getting from the side into your application and its execution there.
If in iOS (without jailbreak) only Apple-signed code can be executed (ad-hoc applications are a separate story), then in Android you can receive code from your servers and execute it in the context of your application, while there is no default code signature.
And it is often used:
• Various advertising networks;
• When updating the application (for example, when adding a new level to the game);
• In the process of testing the application.

3.1) Through code loading.

To implement this scenario, the attacker needs a vulnerability leading to RCE and the possibility of conducting a MiTM attack.
If with MiTM everything is quite clear and ordinary (data transfer in the open form or incorrect work with SSL), then we’ll stop on Android RCE in Android. This can be, for example, achieved in the following ways:
• JavaScript Interface:
o We have already discussed this in detail here ;
• Class loaders:
o The attacker's code falls into DexClassLoader ();
• Package context:
o A vulnerable application can download and execute code from another application (owned by an attacker). In this scenario, MiTM is not needed - the main thing is that our application should already have our application on the victim's device, which will help us to get into the context of the vulnerable without elevation of privileges.

For example, this kind of unclosed (at the time of this writing) vulnerability in PayPal .
For a deeper understanding of the nature of the problem and its scope, I advise you to refer to the study " Execute This! Analyzing Unsafe and Malicious Dynamic Code Loading in Android Applications ". Game over.

3.2) Through the vulnerability of another application.

Do not forget that in Android a very extensive set of mechanisms for IPC, which can lead to very interesting vulnerabilities. Android OS itself has vulnerabilities that can be, for example, used by attackers for the hidden distribution of the zoos of their monsters.

4) Backdoor.
Sadly, but true: in your device already with the purchase can be such a "gift". How he got there (specifically / accidentally), by whom and for what it will be used, at the level of the built-in application, or OS, or firmware, is a separate story.
Last bright example with Samsung . Game over.

Thanks for attention!

PS: For those who want to study mobile malware, I advise you to pay attention to these archives: 1 , 2 .