28 Aug. 2017
Recently, we performed an in-depth analysis of multiple Android AV engines. We checked how they perform in scenarios where the users’ device has not yet been infected. As an afterthought, we performed testing in scenarios where the handheld has already been infected with a piece of malware – a rather realistic scenario assuming that a user realizes that there is something nasty going on and decides to install a free AV to sort things out.
For testing, we installed a fresh sample of Trojan-Banker.AndroidOS.Svpeng.ae on several versions of Android (5.1.1 and 7.1.1) This piece of malware has been throughly analysed by several malware labs (https://securelist.com/a-new-era-in-mobile-banking-trojans/79198/), we only highlight the combination of features that makes it a real threat for Android user and point out the ramifications that apply to Android AV scanners in general.
A video of a successful infection can be found in the following video.
This piece of malware performs a plethora of malicious actions.
- Upon infection, it obtains a wide range of preferences, which allows for reading and writing SMS messages, read the browsing history, grab the screen in order to steal banking credentials, credit card data and other related information.
- It claims to implement accessibility services, and abuses the OS features to grab the screen contents, read texts on the GUI etc. In order to have access to such services, it needs user approval to use Accessibility services and the user is tricked into this action by being shown a fake Google EULA.
- Abusing accessibility services, it automatically obtains Device Administrator privileges and as a device administrator, it subscribes to events when another app attempts to obtain this level of access or any application is installed or uninstalled from the system. Essentially, this piece of malware makes it next to impossible to remove from and Android device.
Having device administrator privileges, the piece of malware actively prevents being uninstalled – in our hypothetical scenario, this is the point where the user realizes that some malware is present and decides to install an AV to get rid of the threat.
As testing revealed, none of the Android AVs were able to remove the threat at this point. As it turned out, they merely start the ‘Uninstall the app’ activity provided by the OS, but actual uninstallation cannot take place as the app is a Device Administrator and is notified whenever the permissions are about to be revoked. As a result, users are usually left with a piece of malware on their device that cannot be removed or turned off – at least, not without a factory reset (in case the malware author takes an extra step and roots the device in the background, planting a backdoor on the /system partition, a factory reset is also useless. In such cases, a trusted ROM needs to be installed from a reliable source).
This behavior highlights an obvious consequence of Google’s ‘the AV is just another app’-approach. On Windows, AVs have traditionally a close cooperation with Microsoft that allows their products to have more effect on the OS than most GUI allows users to. As a result, a job of an AV on a desktop OS is a matter of detection and once a threat is detected, actual removal rarely poses a challenge. On Android however, we stuck up with a situation that virtually every single AV detected malware but none of them was able to do anything about it. When trying to remove the threat, most AVs got into an ‘overlay war’ with the malware, each one attempting to put an overlay on the other one’s overlay and after a couple of attempts, they gave up on the task of cleaning the device.
For illustration, the following videos show the futile attempts of two AV engines.
The moral of the story is that Android AV developers are in a somewhat strange situtation, when it comes to actual removal of malware. On Windows, AV vendors are provided with a plethora of options to mitigate the issue of running malware: they usually have the privilege to access to terminate processes, revoke privileges of other applications etc. On Android, AV engines are prohibited from performing such actions. Based on Google’s approach, this situation is not likely to change.