Google has announced the official release of Android 6.0, also known as Marshmallow. The latest update to Android provides an opportunity to look at some of the behavioral changes in the higher level layers of the operating system. Specifically, the changes beginning in Android 3.0 (Honeycomb) and continuing through Marshmallow have created a significant impact on the threat landscape from the perspective of non-rooted devices.
Premium SMS policy enforcement
Android 4.2 (Jelly Bean), which was released in October 2012, introduced the premium short messaging service (SMS) policy enforcement feature to undermine the operations of premium SMS Trojans rampant during that time.
The core idea of the feature is to monitor every outgoing SMS and heuristically determine whether the destination number is a premium short code, which could cost the user. If the destination is considered a premium short code, the system displays a pop-up alert message to inform the user that a particular app is trying to send SMS to a premium short code and ask the user if they wish to authorize the operation or not.
The feature works because Android introduced a regular expression (regex)-based decision-making module to check the destination number of every outgoing SMS. The regex-based engine makes decisions about the destination based on the country code of the subscriber identity module (SIM) card service provider and loads a pattern-matching engine specific for the country. For example, a four-digit number is not considered a premium short code for a US-based SIM card, but it would be considered a premium short code for a Russian-based SIM card.
Figure 1 shows how a silent premium SMS Trojan running on Android 4.2 and above is dealt with. The system detects the premium cost number, alerts the user, and asks them to authorize the message before sending it.
Figure 1. Android 4.2 and above blocks a premium SMS Trojan from sending an SMS silently
This feature has proved quite effective in thwarting silent premium SMS Trojans. For the sake of convenience, the system even provides a way to remember the decision for particular apps the user trusts. The decision is stored in an Atomic XML file. Irrespective of weaknesses in this approach, there have been no cases of this feature being subverted in the wild.
Blocking silent auto-start through broadcast receivers
Initially released in February 2011, Android 3.1 (Honeycomb) introduced a feature to block silent auto-start capabilities through broadcast receivers. This is intended to prevent Trojans from taking advantage of the ability to silently and automatically start without any front-end activities. By default, all applications are in a stopped state when they have been installed, but not yet launched.
Many Trojans have used silent auto-start methods in the past. Attackers attempted to get them installed on devices with social-engineering tricks, and once installed, the threats would not display any launch icons or front-end activity. Instead they would register broadcast receivers for notifications and start themselves based on the receivers registered such as on device boot, on receiving an SMS, or a network change, etc.
This feature has only been somewhat effective as malware authors have adapted to make sure their social-engineering tricks run the app once and then hide the launch icon from the device using the "setComponentEnabledSetting()" API.
SMS interruption disallowed
SMS modification was not allowed—only interception was allowed—starting with Android 4.4 (KitKat), which was released in October 2013. The main purpose of this feature is to undermine the operations of one-time password (OTP) mobile Transaction Authorization Number (mobile TAN or mTAN) stealers and spyware.
Starting with KitKat, any attempt by an app to abort the “SMS_RECEIVED_ACTION” broadcast is ignored by the system. That is, the malware cannot use the “abortBroadcast()” API inside an SMSReceiver component.
There have been many malware families in the past that relied on the ability to silently intercept an incoming SMS (typically an OTP or mTAN) and prevent it from reaching the inbox through an “abortBroadcast” call.
Figure 2. Registering an SMS broadcast receiver
Figure 3. Intercepting the incoming SMS and interrupting through abortBroadcast
As illustrated in Figures 2 and 3, this has been a common practice among many variants of OTP stealers and SMS-sniffing Trojans. These old malware samples, when executed on a device running Android KitKat and above, would fail to stop the incoming SMS from reaching the default SMS app.
Malware authors have quickly adapted to this change. They have changed their code to mute the incoming SMS alert notification sound and to delete the SMS from the inbox programmatically using a content resolver.
Limiting ‘getRunningTasks’ API for third-party apps
As of Android 5.0 (Lollipop), unveiled in June 2014, the “getRunningTasks()” API is no longer available to third-party apps. Although this move’s main purpose is to prevent privacy leakage, it also affected a group of password-stealing malware families.
Starting from Lollipop, the “getRunningTasks()” API only returns a small subset of its original data, such as the calling app’s own tasks and some generic tasks. In previous versions, it provided information about all the tasks that were running on the device.
Typically, certain password-stealing malware relied on the output of this API to get the list of currently running tasks. Also, when a particular app of interest was running (a banking app, for example), the malware would display an overlaying window on top of it to trick the victims into disclosing passwords and other sensitive information.
This feature has been very effective in making things difficult for such password stealers. However, in other scenarios involving ransomware variants, the malware has actually been using the output of this API for “not equals” to start a recursive device admin permission request window. Hence, ransomware variants are not affected by this feature.
'Dangerous' and 'above dangerous' permissions
Starting from Marshmallow, certain permissions are categorized into “above dangerous”, “dangerous” and “normal” permissions. Last week, we posted a detailed blog on how this new change could potentially have an impact on the Android ransomware ecosystem.
Placing the “SYSTEM_ALERT_WINDOW” permission in the “above dangerous” category has great potential to undermine ransomware variants. However, it is not mandatory for the apps to adopt the new permission models. The apps can still target older software development kits (SDKs) and run using an older permission model.
It is therefore very important to keep Android devices updated with the latest available version of the software as this ensures that the device is protected with well thought-out new features and patched against known vulnerabilities.
Protection
Symantec recommends users to follow these best practices to stay protected from mobile ransomware:
- 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, in order to protect your device and data
- Keep your software up to date
- Make frequent backups of important data