Promiscuous Permissions: Catching Your Android Apps in the Act
Smartphones have become an integral part of our life, and to facilitate our day-to-day tasks we install a lot of android applications and end up giving them permissions which may or may not be needed. This can easily lead to our devices and personal data getting compromised. So, we will be talking about some of the permissions in this blog, which malware are exploiting in the wild.
To give some brief idea of the categorization of permissions in Android, there are two broad groups -
- Run Time Permissions — Requested by apps during the runtime and a user must explicitly grant them. These are the ones which users are usually familiar with as they appear as a popup which looks like the following:
- Install Time permissions — These are usually automatically given when installing the application without the knowledge of the user. This is again of two types:
- Normal permissions: These don’t pose any threat to user’s privacy or data hence given without any verification, like ‘android.permission.INTERNET’ which lets the app access the internet.
- Signature permissions: These require the app requesting permission to be signed with the same certificate as the one defining it. So usually, only system apps or OEM apps get these permissions automatically.
We will mostly be talking about the Signature permissions in this blog. One question which might arise is how are signature permissions dangerous if only authorized apps get them? That’s true, malware doesn’t get them automatically, but nothing stops them from tricking a user into explicitly giving those permissions.
One tactic that is used widely is when the malware makes a user believe that it needs the permission to “function properly”. For example, the following image is an example of a ransomware malware posing as a COVID Tracker App which claims to detect COVID persons nearby and for that it needs those permissions. Now a user who isn’t familiar with the danger of giving these permissions might give them and that lets the device getting compromised.
Another question is, how actively are these permissions exploited by malware? We did a survey on a randomly picked set of 480 malware samples and performed manifest analysis plotting the number of malware exploiting the signature permissions whose results are below.
NOTE: There were a lot of signature permissions, and we removed some which have a lower count for better visibility.
We can see 5 different Android Permissions to be pre-dominantly used:
- android.permission.BIND_JOB_SERVICE — JobScheduler
- android.permission.BIND_NOTIFICATION_LISTENER_SERVICE — Notification Listener
- android.permission.BIND_ACCESSIBILITY_SERVICE — Accessibility Service
- android.permission.BIND_DEVICE_ADMIN — Device Admin
- android.permission.BROADCAST_SMS — Broadcast SMS
For the sake of brevity, we will only be looking into Notification Listener, Device Admin and Accessibility Service in this blog. Keep a lookout for future blogs on this topic where we will be covering other permissions more in depth.
Notification Listener
This service grants the app/malware requesting this, intercept all the notifications received by the system. This means the malware can read all notifications, modify them before sending to the user or even reply to them if needed. One might easily confuse this permission with the runtime notification posting permission which only allows an app to display notifications which looks like the following -
On the other hand, the Notification Listener looks like the following -
What kind of malware would exploit this? Malware looking to bypass 2FA exploits this permission by intercepting notifications. To see how malware exploit this permission in the real world we will look into SharkBot, an infostealer malware —
SHA256: fa7947933a3561b7174f1d94472dcf8633a03749c14342ce65dafe94db361140
Every permission an app might request needs to be declared in the Android manifest file. To look at it, we can decompile the APK with Apktool -
Looking at the contents of AndroidManifest.xml, we can see the malware declaring this permission.
If we track down the class ‘com.ltdevelopergroups.litecleaner.m.service.NotificationListener’ mentioned in the XML and look at the same by decompiling the classes.dex back to source code with a tool like JADX, we see the method ‘onNotificationPosted’, which is triggered when a new notification is posted. The method is overridden by the malware to do its thing, and we can see the notification information being fetched.
Device Admin
This was a feature introduced primarily to be used by enterprise apps to have control over the employee mobile devices. For example, it’s used to install/uninstall apps, encrypt the company data, and format the devices. So naturally this permission would mean a huge deal of control over the device. If a malware gets this permission, it can run any code, install additional malware, steal data and much more. The policies it will enforce will vary app to app and is shown when requesting the permissions. The following image shows some of the capabilities that this permission grants to the malware:
Two of the listed capabilities which makes this perfect for ransomware to exploit are storage encryption and data erasure.
We can take a look at the covid tracker malware shown earlier, which exploits this permission.
SHA256: c844992d3f4eecb5369533ff96d7de6a05b19fe5f5809ceb1546a3f801654890
Looking at the manifest, we can see it exposes the permission and this time we have a configuration file with it ‘@xml/device_admin_sample’ which shows the capabilities that the malware will get .
Once the malware is given the permissions it needed, we try to open the file system of the app, and it shows the classic ransomware message which says all the files are encrypted.
Taking a quick look at the code, the malware isn’t that sophisticated, even though it has the permission to encrypt the files, it doesn’t do it (lazy threat actors) and just shows a new fake screen when trying to open the file app. Usually if a malware gets this permission, removing it can get very difficult based on the complexity of the permissions it abuses.
Accessibility Service
This service was introduced to help people with disabilities or who may temporarily be unable to interact with the device. This permission can help them by reading out the contents of the screen, navigating the UI automatically. Therefore, it grants certain control on the device which malware would want to leverage.
With this permission a malware can control the screen, do clicks, read what is displayed, read keyboard input and all this information can be sent back to the remote C2 server. As a result, this is used quite a lot in credential stealer malware to steal login creds, 2FA codes etc.
If we look at the Banbra malware sample (family name as per Virus total)
SHA256: be3d8500df167b9aaf21c5f76df61c466808b8fdf60e4a7da8d6057d476282b6
Upon looking at the config XML of this service, we can estimate the capabilities it will gain, like ‘accessibilityEventTypes’, which makes the malware receive all types of event changes, ‘canRetrieveWindowContent’, and ‘canPerformGestures’, which lets the malware fetch whatever is shown on the screen and perform gestures for navigation.
We can see when we install the sample, it immediately removes its launcher and directs the user to the accessibility screen (there is a delay in the GIF wait for it!)
If we look at its source code and search for AccessibilityNodeInfo, which is used to fetch current screen XML, we get a few hits and among them Acessibilidade_Click.java sticks out. Since an android layout/screen is in the form of an XML, we can see the malware parsing the nodes of XML:
Another reason this permission is dangerous is it can initiate clicks, so once this malware gets the accessibility permission, it just grants itself the admin permission as well in the following GIF.
Key Takeaways
- Installing apps directly from the app store doesn’t guarantee an app’s intent since malware have repeatedly managed to sneak into them. So, general users need to be careful about what permission they are giving to an app. A quick way to know the various permissions an app might ask before downloading is to look in play store (This might not cover all permissions):
- For security vendors, keeping a hash database for malware detection is not an option anymore as attackers can easily generate variations (polymorphic versions) of them. More info on this topic can be found in this blog. Both static and dynamic analysis is required, and this kind of dangerous permission detection can be detected by doing manifest analysis as shown in the blog. You can also subscribe to Keysight products to stay protected.
Leverage subscription service to stay ahead of attacks
Keysight’s Application and Threat Intelligence (ATI) Subscription provides Daily, Monthly malware and bi-weekly updates of the latest application protocols and vulnerabilities for use with Keysight test platforms. We have also recently started delivering polymorphic versions of Android Malware where we cover the top Android malware of the month as part of the ATI subscription, more info here. The ATI Research Centre continuously checks threats in terms of vulnerabilities and the latest malware used by Threat actors and integrates as part of the ATI subscription, to help keep your network secure. More information is present here.
Originally published at https://blogs.keysight.com.