|Jul / 20 / 2017|
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.
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.
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.
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.