Recently, MRG Effitas have been involved in a test of Android based AV products. Having completed the test process, we realised that the general approach of malware on Windows cannot be applied to mobile based samples, as the general considerations fundamentally differ. Furthermore, most Android based AV vendors started their work offering desktop AV solutions to customers, and many times the same approach is applied on both fields – which, we’ll see, often leads to controversial consequences.
AV is “just another app”
Most of the issues we found fundamentally originate from the fact that the AV is usually just another application, installed on an Android OS. Even if it is provided with a wide range of permissions, there are restrictions, which permit a deep enough access to the OS itself, as seen on Windows. As a result, most AVs cannot detect in-memory threats on a general basis.
In versions of Android since 2.2 Froyo, an application can ask for the Device Administrator privilege, which allows a wider range of controls over the device itself. This feature allows an application to enforce security settings on the device (PIN complexity, encryption, installation or removal of applications etc.), however, not even a Device Administrator application can access system process memory, which limits the potential of a successful detection.
This limits the overall potential of an Android AV.
Leak of potentially sensitive data as a BAU operation
Back in the goodol’ days, in the Nokia 3310-era, the distinction between software and malware was blur but we had a clear indicator that there was something nasty going on: a piece of software attempted to perform some action, which seemed not to be in alignment with the users’ guessable intentions. When it came to mobile applications, the scenario fundamentally changed.
With the dawn of ad-sponsored applications (which provide the same features as the the paid-for version but in addition, they continuously display ads on the screen), the distinction is even harder to make. Namely, freemium and most ad propelled apps utilise some kind of ad framework, which assigns a unique identifier to the device and this allows ad providers to target users with customised ads. As a result, most of the ad propelled applications leak potentially sensitive user information (e.g. IMEI), or (on their own) non-sensitive identifiers which allow the marketers to assign identifiers from different apps, based on data analysis to identify the user.
This behaviour has been long considered malicious on desktops, for a recent example recall the infamous Ask Toolbar flame war (https://betanews.com/2013/07/23/the-ask-toolbar-is-another-reason-to-avoid-java/). However, when talking about free Android apps, displaying ads in exchange for the ‘missed’ payment is widely accepted as a fair trade. As a result, many respectable developer companies use ads to improve their revenue and most users consider ads all right – despite the fact that potentially sensitive data is leaked by the ad frameworks. As a result, most AVs do not consider ad propelled apps malicious, even if a standalone application requesting INTERNET and READ_PHONE_STATE permissions and leaking IMEI is generally considered a Potentially Unwanted Application (PUA).
Furthermore, the issue is made even worse by the fact that many ad service providers have ready-to-use code snippets, which do the weight lifting in the background, making it easy for developers to integrate ads in their apps. As a result of this architecture, the ‘alien’ ad modules share permissions with the application, which allows an ad framework to leak even more data, when integrated into apps with more permissions.
This poses a significant challenge for AV vendors, as a typical lifecycle scenario for a malicious ad distributor is as follows.
- The advertisement module is bundled into several applications. They are uploaded to the Play Store and other app stores.
- The apps are uploaded to VirusTotal and checked by AV vendors. Being normal ad propelled apps lacking any suspicious activity, they do not pose a risk in themselves, therefore they are not flagged as malicious.
- After some time, the advertiser changes the ad content to display an ‘AV-like’ screen that tricks the user into installing a fake AV engine or some other malicious application.
This mode of operation makes it really hard for an AV engine to detect valid threats, as most of the time, the very same client side module is responsible for both.
The root of all evil
Testing revealed that most AVs do not warn the user when being run on a rooted device. Rooting means that the Android OS is provided with the su binary and most of the time, a GUI application that allows users to control which apps are allowed to use it, e.g. SuperSU. In case a process runs with root privileges, it is either except from security measures or it is able to disable them.
Having root access to an Android based OS essentially means that all OS security measures are to be considered void. For instance, consider the following traits of insecurity on a rooted device.
- All application sandboxes can be read and written. Normally, Android applies a strict policy for file management. All apps use a different linux user, and the file system level access controls prevent one application from accessing another app’s sandbox or to access any system related files. With root privileges, this is obviously bypassed.
- All application binaries can be read and written. Application binaries are usually stored on the /system partition, which is mounted as read-only. With root privileges though, it is possible to replace the binaries.
- Intent filters are void. When an Android applications communicate with another apps, they use the Inter-Process Communication (IPC) services of the OS. Actual communication happens passing Intent JAVA objects. As a security measure, an application can filter the set of apps that are allowed to send an Intent to its Receivers or to restrict the circumstances when it accepts Intents from other apps. With root privileges, this can be bypassed.
- Non-exported activities can be invoked. An Activity is a module of an Android app, which serves as a GUI entry point into the application. (For example, consider a VoIP messenger app, where an Activity is responsible for the splash screen and another one for listing contacts). Normally, only exported activities can be started by another application (a usual design pattern is to have an exported Activity for login and a non-exported one for performing tasks, which require prior authentication). Having root access to the device, this can also be bypassed.
- Using dynamic hooking techniques, functionality of existing applications can be arbitrarily altered run-time. JAVA provides reflection, which allows developers to dynamically adapt their code run-time. As a side effect, a technique called dynamic hooking allows an application to ‘overwrite’ objects and methods of other application in the memory, without touching the binary.
As a result, a rooted Android device with an obvious installation of the Xposed dynamic hooking framework (http://repo.xposed.info/module/de.robv.android.xposed.installer) is an environment, which prevents an AV to fulfill its purpose. As the framework makes it possible for malware authors to bypass detection mechanisms of any AV, hide files, change signatures, intervene into network communication etc., a well suited AV should notify the user that a “clean” result of a scan means essentially nothing. Having performed the test, none of our test subjects warned the users, even though the Xposed installer application has been even scanned by the AV.
As the purpose of the AVs is to provide protection to the users against malware, it is very important to notify the user that the device OS itself has been compromised. Consider the following scenario.
- The victim’s device, rooted and lacking AV protection, gets infected with a piece of malware, which utilises dynamic hooking techniques to hide its presence.
- The victim realises that there is something nasty going on, and opts for an Android based AV to check what’s going on.
- The AV is initialised and set up, and detects presence of a rooted device and the Xposed framework, but the scan reveals no threats. (Under the hood, the piece of malware affected the actions of the AV).
It should be noted that root detection is a problem, which cannot be solved algorithmically (it is equivalent to solving the halting problem). However, most rooted devices can be detected, as there are typical residual artifacts of the rooting process and most in-the-wild rooting tools do not attempt to hide their activity. Nevertheless, the RootCloak application can be used to attempt to make the device seem to be intact – even in this case, developers can detect dynamic hooking.
Nevertheless, it is needless to say that presence of a dynamic hooking framework also influences the overall stability of the OS, and we have seen examples when AVs just crashed when trying to instrumentalise them using dynamic hooking. When an AV process is changed using dynamic hooking, that is an obvious and tell-tale sign of malicious activity – none our tested AVs attempted to notify the user in any way in such cases.
AV products aim to provide protection for the end users’ privacy and the data stored on their devices. However, the design of the Android OS and the altered user habits make the task of malware protection a particularly challenging one. There are several Android AVs on the market, however, the protection level, expected on for instance a Windows workstation, requires a different approach.
We tested four popular Android AV applications, and we found issues in all four. We notified all the vendors about the issues. We will disclose here the links for all the details regarding this disclosure once the issues are fixed and verified.