Mobile malware authors have updated their threats to handle Android’s latest permission-granting model, which was introduced in version 6.0 Marshmallow. The model was designed to let users grant permissions only when apps require them, rather than accepting them all on installation. However, dangerous threats such as Android.Bankosy and Android.Cepsohord have adapted to this method in an attempt to gain the permissions they need to carry out their malicious activities.
Requesting permissions at runtime
On Android 6.0 Marshmallow devices, apps request permissions that could pose a privacy risk at runtime, as and when they’re needed, instead of asking for all of them at installation time.
The exception to this rule is if the app’s “target_sdk” attribute is set to less than 23. For example, if the author of an app deliberately sets the “target_sdk” attribute to 22 to avoid requesting permissions at runtime, a user could grant all of the requested permissions during the app’s installation. It should be noted, however, that users can manually revoke permissions from any app at any time, irrespective of the “target_sdk” values on devices running Marshmallow.
Even though Marshmallow was released last year, malware authors continued to use the older permission model. This is because the old model makes it easier for attackers to get authorization for all permissions at once during installation, instead of asking the user to authorize each permission whenever the app is about to use a function.
Now, Marshmallow’s marketshare is increasing and more users are learning how to manually revoke permissions. To account for this, authors of certain malware families, such as Android.Bankosy and Android.Cepsohord, have started migrating their code to handle the runtime permission model.
How Bankosy and Cepsohord handle Marshmallow’s new permission model
Financial Trojan Android.Bankosy partially works with the new model by checking whether a permission is in a non-revoked state before executing malicious code. As we discussed in an earlier blog, the Bankosy malware calls a special service code (*21*[DESTINATION NUMBER]#) to enable unconditional call forwarding on the compromised device. The attacker needs this functionality to help it conduct fraudulent transactions using the target’s information.
Recently, Bankosy’s authors updated the malware’s code to check whether the permission to call this number has been granted. They do this by using Marshmallow’s checkSelfPermission API.
Figure 1. Bankosy code was updated to check whether a permission is granted through Marshmallow’s checkSelfPermission API
Click-fraud malware Cepsohord goes one step further—it fully handles the new permission model. This threat not only checks the permission’s authorization state, but also asks the user to authorize the permission in case it is in a revoked state.
Figure 2. Cepsohord asks user to authorize permission in case it’s revoked
What could be next?
Malware authors work fast whenever their creations hit a roadblock. We have previously seen Android threats update themselves so that they can survive new security measures on Google’s mobile operating system. These threats usually do this through powerful social engineering, taking advantage of users’ lack of privacy awareness.
Symantec recommends users to follow these best practices to stay protected from mobile threats
- Keep your software up to date
- Refrain from downloading apps from unfamiliar sites and only install apps from trusted sources
- Pay close attention to the permissions that apps request
- Install a suitable mobile security app, such as Norton, to protect your device and data
- Make frequent backups of important data
Symantec and Norton products detect the threats discussed in this blog as: