We have spent some time in custom sample development, based on methods seen in the wild. During the countless hours of sitting in front of Android Studio, a feeling grew in us regarding how easy it is to actually develop applications for Android – and malware, for that matter. The analysis of Android based malware families lead us to the conclusion that despite all efforts from Google, Android will remain the go-to platform for threat actors motivated by financial gain. The OS vendor, and many other players in the AV field focus their efforts on detecting individual pieces of malware and identifying threat actors behind them, but despite all work, the number of Android malware samples is still on the rise.
In this blog post, we attempt to identify some contributing factors that are rooted in the philosophy and the overall design of the Android ecosystem. Based on the development history of Android and the philosophy of Google, these elements are not expected to change anytime soon, therefore their effects can not be ignored.
Flexibility as an overall platform philosophy
Android has been designed as a free platform, providing freedom to developers and end-users alike. At the time of the roots of Android (Eclair, Froyo, do they ring a bell?), the smartphone market in the US was dominated by the notoriously closed Blackberry, even US President Barack Obama was proud to have one. Apple at the time was only working on their iPhone prototypes. The designers of Android, based on the open source linux, chose to follow a different path: they opted for an approach, which limits the restrictions posed on both application developers and end users. Back in 2005, the flexibility and upgradeability marketed by Google, was one of the key selling points for mobile handset manufacturers and mobile service providers.
API woes
From a developer’s point of view, to develop their very first Android application, the free-to-download SDK is needed only, which already includes an emulator module. Up until the point of distributing their application through the official Market (now Google Play) platform, developers do not have to pay any fee or enroll to the vendor’s developer program. Furthermore, developers are free to use their distribution platform of choice, the official Market is merely one of the alternatives. As a result, it is quite easy to develop a piece of malware, as there is literally no cost from the threat actor’s point of view to generate a new developer key.
The Android platform gives access to powerful features for developers. For instance, it is quite easy to obtain device administrator privileges, which provides to the requesting application quite deep access to the OS security settings. A similar example is the Accessibility API, both widely abused by malware to steal user passwords, banking details and other sensitive data.
Practically, once a piece of malware has been installed on an Android instance and has been launched for the first time, it is quite trivial for the malware to force to user to grant any privilege it needs through forced re-launching of the Device Administration API or the Accessibility enabler sections of the Settings application.
Once the user finally gave in, the piece of malware has a position of being extra hard to remove from the system – in most cases, at least some kind of factory reset is needed, which obviously removes all user data from the device. And even in that case, we know families, which root the OS and embed themselves in the system partition. In this case, a system upgrade is necessary from a clean source.
User errors
From a user perspective, Android provides a lot of flexibility. First of all, users are allowed to install applications from whichever sources they wish, a quite convenient feature for markets, which are rather price sensitive when it comes to applications. On the other hand, Android gives a whole lot of security options for the user (two-factor authentication, full disk encryption, biometric authentication etc.) but at the end of the day, it is up to the user to enable those features. Depending on the user’s choices, the very same piece of hardware running the same version of Android can provide full disk encryption with a complex password with strict boot chain verification and each of these features can also be turned off, resulting in minimal or no security. As a result, security consciousness of the end user is a key element in an Android device’s overall security posture.
As stated earlier, users play a critical role in the Android security landscape. This is a serious task – tweaking with settings that can be detrimental for the security level of the operating system. However, most Android users have no idea what effects the individual settings have and what they mean in practice. In order to get around this, OS designers do their best to inform users about potential consequences, whenever they choose to disable an important security feature. As an example, consider for instance the “device administrator” screen, which is the last step before a permanent infection for the most part.
However, in order to understand the text displayed on the screen, a certain level of literacy is required. Even though most people in the EU and US go through some form of education, functional illiteracy is still a thing even in economically developed regions (according to studies in Italy for instance, a staggering 47% of people between 16-65 can read written text but they fail to understand its meaning.) Understanding a technical warning displayed on the screen might cause a problem for many users – which most 3rd party app stores providing pirated and backdoored copies of legitimate applications make use of.
Furthermore, some IT related background is required to see through what the potential consequences of the individual settings mean and most users do not have the background. Blatant it might seem, but this is a crucial point, as the OS GUI designers tend to create interfaces, which require significantly less mental activity and knowledge to fruitfully utilise. As a result, users can just as easily disable security features as they can use other modules of the OS (for instance, when a piece of malware displays the “allow 3rd party applications” section of the Settings app, most users do not have a clue that in the worst case scenario, they are only one tap away from giving away every data what is on their device).
Conclusions
We summarised some of the factors that contribute to the prevalence of Android malware, which with all the efforts of Google, is likely to stay. As Android progresses with newer and newer API versions emerging, many glaring loopholes are fixed (for instance, in 8.0 Oreo the “show the device administrator screen over and over again until the user gives in” approach has a limited potential, compared to earlier versions) but the root cause of issues lie in the foundation and the philosophy of Android. As long as those factors stay unchanged, we do not expect the Android malware market to shrink anytime soon.