Dangerous Permissions
How mobile malware abuses user consent and what Corrata is doing to help
Working as I do in mobile security, whenever I install a new mobile app I diligently review the permissions requested. If only this statement were true. In reality like everyone else, aside from a little more awareness and caution, I generally click through the requests for permissions to access my contacts, track my location or integrate with my calendar. We all have an appreciation that perhaps we should be a bit more diligent about reviewing these consents but I also think that most users view the risk of not doing this as very low. Perhaps I do give away too much and maybe I’m subjecting myself to more tracking than is ideal but sure it’s not something I should be too concerned about.
It turns out that this lazy assumption is the most serious security vulnerability that most Android users will ever expose themselves to. Key to all the high-profile recent Android malware attacks (for example Flubot, Hydra, Autolycos) has been a success in getting users to grant consent to the use of powerful operating system capabilities. Just two weeks ago Meta disclosed details of newly discovered Android spyware ‘Dracarys,’ which successfully exploited user willingness to grant access to functions such as location, camera and microphone. But it’s not just with such obviously sensitive functions that caution is advised. To understand why let’s take a deeper dive into the world of Android permissions and user consent.
Android Permissions and Consents
The first step is to recognize the distinction between what is enforced by Android (the operating system) and what is enforced by the Google Play Store (the app store through which the vast majority of apps are distributed). Android’s rules are enforced by the operating system. This means that bar your phone running an unsafely modified version of the operating system, an app can’t bypass these rules. In contrast, rules imposed by the Google Play Store are not enforced by the technology. Instead, they are policed by Google through their app store approval process. This is inherently a tough job and can’t deliver 100% compliance. What’s more, apps that are sideloaded (downloaded from somewhere other than the Google Play Store) don’t have to abide by Play Store rules at all. In short: you can rely 100% on apps complying with the Android rules but no such assurance can be given with regard to the Play Store rules. So to understand stand permissions and consent focusing on the Android rules is key.
In what feels like a willful attempt to confuse the layperson Android calls API’s which an app can use to interact with the operating system “Permissions”. What makes this confusing is that many Permissions don’t actually require user consent. The entity giving permission is the operating system, not the user. User consent is only required for a subset of Permissions: those which Android categorizes as “Dangerous”
While Android has a range of subcategories for Permissions we can usefully split them into those that require user consent (Dangerous) and those that don’t (known in Android speak as “install time permissions” but we’ll refer to them as Standard). An obvious question is why don’t these Standard Permissions require consent. The answer is that they give an app ‘limited access to restricted data’, and allow an app ‘to perform restricted actions that minimally affect the system or other apps.’ Examples include giving an app the ability to send and receive data, download files, access bluetooth settings (but not connect to a bluetooth device), and run in the foreground. One advantage of not requiring user consent for these benign permissions is that it ensures that requests for ‘dangerous’ permissions are more likely given due consideration.
Example of Standard Permissions used by the BBC Sport app
So which Permissions require user consent before Android will allow an app to use them? First up are those that access the phone (to make or receive calls), SMS (to read and send SMS messages), the camera (for photos and videos), or the microphone (to listen or record audio). Next, we have sensors: location, physical activity (for example step counts), or body sensors (if your device can monitor, for example, heart rate). Then we have those that access content on the phone: calendar, contacts, files, and media or call logs. Permissions that allow automatic connection to nearby devices via Bluetooth or Wifi also require user consent. Finally Android requires user consent if an app wishes to use Accessibility Services.
Abuse
It will be obvious from the above list why giving access to these functions and content is classified as Dangerous. No one wants to have their calls recorded, their camera used, their SMS messages read, their photos shared or their heart rate monitored without their explicit consent. In contrast, it’s not as obvious why giving an app access to “Accessibility Services” should be a cause for concern. Accessibility Services was designed, as the name suggests, to make it easier for those with various disabilities to use their phones. Apps are enabled to do a range of things including monitoring the content of the phone screen and overlaying an alternative user interface. Unfortunately, these capabilities are routinely abused by bad actors. Once the Accessibility permission is granted, an app has the ability to monitor any action a user takes on their phone. So the app can read the content of your messages, capture your keystrokes and record anything that appears on your screen. What’s more is that it can take over your screen and replace whatever is displayed with content it generates. Malware uses these capabilities to capture sensitive data such as passwords and usernames, to create fake login pages and to keep itself hidden.
The permission to read, write and send SMS is another which is often exploited by cyber criminals. Often we see this being used for billing fraud: a user is subscribed to a premium service without their knowledge and the notification message from their operator is intercepted and suppressed. A more dangerous use case is where SMS is used to send a one-time passcode for two-factor authentication. Used in conjunction with abuse of the Accessibility permission this can allow malware to first steal credentials and then intercept the one-time passcode used for 2FA.
How to protect against these abuses?
The obvious thing is to encourage your colleagues to be vigilant and to take care when granting consent. And to remind them never to sideload apps. But in our experience these steps are relatively ineffective. Desktops and laptops still have the aura of a work machine about them and are used with a degree of care. In contrast, phones are stitched into our daily lives and used in an entirely informal manner. Furthermore, consumer apps have trained, rewarded and encouraged us to mindlessly grant consent to whatever is requested.
To address this reality Corrata recently released a new version of our mobile threat defense solution specifically designed to address this issue. Any device running an app which requests permissions that have limited legitimate uses and which are routinely abused in cyber attacks is flagged. IT security staff now have the capability to set rules which automatically prevent a device running such an app from accessing sensitive data until the app is removed or the permission revoked. This precaution will ensure that the risk of device compromise through abuse of user consent will be greatly reduced. So even when a colleague has inadvertently granted permission to an app, Corrata can now effectively withdraw that consent as a precaution.
The openness, innovation and capability of the Android ecosystem has undoubtedly brought wonderful experiences, new capabilities and better lives to literally billions of people. Notwithstanding that, its very flexibility can present challenges to those of us who work to keep our societies safe from cyber threats. At Corrata we continue to innovate to make mobile a robust and secure environment for business operations. By addressing the challenge of dangerous permissions and user consent we believe we’ve made a significant contribution to making mobile a better place.
