Android’s permissions system is meant to give users an informed choice about what apps can do with their device’s resources and data. In reality, a combination of user fatigue and information overload means malware creators can get unsuitable permissions to carry out their rogue activities. In this post we’ll detail the ten permissions that you should never grant unless you trust an app.

 

How The Permissions System Works In Theory

In principle, Android permissions give the user control over how apps access their device. Almost anything an app can do on a device is covered by one of 300+ categories, known as permissions. A few are granted to apps by default because they are relatively safe, but for everything else the user must actively grant the permission.

Until Android version 6, this meant an all-or-nothing choice when installing the app. The user had to approve an entire list of requested permissions. Since Android 6, permissions work individually so a user can grant one permission while refusing another. A common setup among developers is to only request a permission when it’s actually needed. For example, a food delivery app might not request access to the phone’s location until the user is about to place their first order.

In some cases, app developers want to add a completely new permission to the app. To do this, they need to issue an update. The notes accompanying the update will tell the user about the new permission, so installing the update automatically grants the permission.

 

What Really Happens

The way permissions work in practice is open to abuse.

Many legitimate developers still ask users to grant all the permissions at once during installation. Often they’ll ask for unnecessary permissions to in case they need them later on, for example after changing the app’s functions.

Many users find themselves confronted with lengthy lists of permission requests to the point they can’t be bothered to check through them all. Just as happens with epic End User License Agreements, users simply tap to accept everything without reading it. You can argue whether it’s the system or the user at fault in this case, but it doesn’t really matter: the fact is, it happens. The same happens when apps require manual approval for updates and users don’t read through details of the newly requested permissions.

Malware creators take advantage by intentionally overwhelming users with requests for permissions that aren’t necessary for the app’s advertised purpose. Instead the permissions let the malware wreak havoc.

 

 

The Troublesome Ten

There’s no telling if and when the Android permissions system will change to prevent this abuse. In the meantime, it would be wonderful if every user carefully checked every permission request. As that’s probably not going to happen, here are the ten permissions that every user needs to treat as a red flag.

It’s perfectly possible apps will use any of these permissions for a legitimate purpose, but users should never grant these permissions unless they are confident that everything is above board.

 SYSTEM_ALERT_WINDOW

This lets an app display a window “on top” of other apps without telling the user what’s happening. To understand how serious this could be, imagine a rogue app that displays a fake log-in window on top of the real log-in screen of a banking app.

 INSTALL_PACKAGES

This lets one app install other apps on a device without having to tell or ask the user. In security terms, it’s not unlike giving somebody the key to your front door.

 AUTHENTICATE ACCOUNTS

This lets the app check your phone to see if you have an account on services such as Google or Facebook, then asks to access and uses the account. The big problem is that once you let it use the account, it can continue doing so later on in ways you wouldn’t want.

 READ SENSITIVE LOG DATA

This can include information such as keystrokes or typed passwords. Remember that if you give this permission, you’re not only trusting that app developers will use the data responsible. You’re also trusting that they’ll store it securely on their own system and not be hacked.

 READ AND MODIFY CONTACTS

This gives the app both access and control to the stored contacts on your device. The “Read” element should be an obvious security risk, but the “Modify” element could also be a serious problem. Imagine if all the stored numbers in your contact list were changed to premium-rate phone lines.

 SMS AND MMS-RELATED PERMISSIONS

Again, this isn’t just a security risk but a financial one as well. Most phone networks support premium messaging services where messages attract a charge. This is added to your phone bill or taken off your pre-paid credit balance. Scammers could set up their own message “service” and force your phone to send unwanted messages, putting your money in their pockets.

 CALL-RELATED PERMISSIONS

Any app can automatically “fill in” a phone number in the dialler, but this permission lets the app place the call without you having to press the call button. Again, that’s a jackpot for fraudsters who set up a premium rate line and force hijacked phones to call it.

 PHONE STATUS AND IDENTITY

The problem is how vague and broad this category is, covering anything from knowing when there’s an incoming call to getting the device’s IMEI number. That could make identity theft easier.

 STORAGE

If you’re running newer versions of Android, this should let the app write data to storage but only read data where strictly necessary. With older versions, there’s less restraint on exactly what data the app can read. In both cases, take note that references to accessing an “SD card” can actually cover some data stored on the phone itself rather than the removable card.

 FULL NETWORK ACCESS

This lets the app send and receive data over the internet. It’s fine if the app is doing this for the advertised purpose. It’s not fine at all if it’s doing it for another reason such as delivering unwanted ads. Remember also that this will use up your data allowance.

 

The Risks Remain

Looking out for these 10 permissions will reduce the most serious risks, but it’s not a guarantee of complete safety. You should always think twice about whether the requested permissions are relevant to the app’s stated purpose.

It’s also worth noting that some rogue apps can take advantage of a loophole in the app permissions. An app can use what’s called an “intent” to carry out a function via another app, taking advantage of that app’s permissions.

This can be perfectly legitimate, such as a train timetable app opening up a browser to access the booking page for the relevant train company. However, it’s also open to abuse if, for example, a rogue app accesses personal data then uses the browser connection to send the data to a remote server.

Because of this loophole, you should still always be wary of any app and make sure it’s from a trusted source, even if the permissions look reasonable.