How to Test The App Permissions?
Every installed application on the Android is assigned with the distinct system identity which is most of the times Linux user ID and group ID. Did you know that each of the Android’s apps operates in the process sandbox? In that case, they may explicitly request the access to the resources. The same goes for the data which are based outside of their sandbox. How do they request such an access? It can be done because they are actually declaring the permission which they will use for the certain data and also the features. It also depends on how sensitive the data is or how critical the feature might be. So, in that case, the Android’s system itself will decide whether its important to grant the permission or in the other case, it will automatically approve the requests.
We will now show you how are the Android permissions classified. They are sorted in the four categories. Those are actually based on the protection level which it offers.
The first one would be normal. A permission which is giving the app such an access that is isolated with the app-level features. It also has the minimal risk to the other apps, and also the system and the user. Besides that, while you are installing the application, it is granted. So, let’s say that there is no protection level that is specified. What then? Normal would be the default. The example may be android.permission.INTERNET.
Dangerous. Such a permission which most of the times gives the app the control over the user data of the other device which also impacts the user. It is the type of the permission that sometimes may not be granted once you want to install the app. It is left to the user to decide will he/she allow it. Its example is the android.permission.RECORD_AUDIO.
The Signature. This one is only granted if the app requesting was signed with the totally same certificate as it was the app which is asking for this permission. So, it’s easy to understand-if those certificates matches, such a permission can be automatically granted. Take a look at the example-android.permission.ACCESS_MOCK_LOCATION.
And the last one-SystemOrSignature. This one is granted only if the same certificate was signed between the embedded app and the system image. The example would be android.permission.ACCESS_DOWNLOAD_MAGANER.
If you are interested in the more permissions, you can check the full list in the Android developer documentation easily.
What about the custom permissions? Android is also allowing its apps to expose their components or services to the other apps. Here, the custom permissions are ones that are required for a purpose to restrict which app actually can have access to exposed components. They can be defined (example) like this: AndroidManifest.xml. The permission tag is created here with the two mandatory attributes, and those are android: name and android:protectionLevel. I would like you to remember that it is a must to create the custom permission which adhere to the Principle of Least Privilege. It should be defined very explicitly for its actual purpose with the meaningful and of course, accurate label and description.
Let’s say that you have defined your permission, what happens then? It can be easily enforced on the component. It is done by specifying it in the app’s manifest. We will show it on the example for your better understanding. START_MAIN_ACTIVITY permission is created (the new one). Now, the applications can request it. It can be done by using the uses-permission tag. It is located in the AndroidManifest.xml file. Now, any app can easily launch the TEST_ACTIVITY. Also, it can be possible only if it is granted with the custom permission which is START_MAIN_ACTIVITY.
The Android’s Permission
All of the permissions need to be checked with a purpose to realize whether they are really needed within the App. If not, they will be removed. Let’s say that the Activity needs or wants to load a web page into a WebView. If such an action wants to be successfully completed, then it must be INTERNET permission in the Android Manifest file.
Besides that, I would recommend you that you need to run through the permissions with the developer together. What will bring you such an action? You will, together, easily identify the intention of the every permission set. Also, you will remove the ones which aren’t needed.
We talked about the custom permissions earlier. What else you need to know about them is that they can be checked too programmatically, not only by enforcing it through the app manifest file. But, you need to remember one thing. Such an action is not recommended because it will leave you more vulnerable and often it causes so many errors.
In the static analysis, the Android Asset Packaging tool that is used for examing the permissions.
$ appt d permissions com.owasp.mstg.myapp
user-permission: android.persmission.WRITE_CONTACTS
user-permission: android.permission.CHANGE_CONFIGURATION
user-permission: android.permission.SYSTEM_ALERT_WINDOW
user-permission: android.permission.INTERNAL_SYSTEM_WINDOW.
And about the dynamic analysis, if you want to make a custom permission, it can look like this:
dz> run app.package.info -a com.android.mms.service
Package: com.android.mms.service.
Application Label: MmsService
Process Name: com.android.phone
Version: 6.0.1.
Data Directory: /data/user/0/com.android.mms.service
APK Path: /system/priv-app/MmsService/MmsService.apk
UID: 1001
GID: (2001, 3002, 3003, 3001)
Shared Libraries: null
-android.permission.RECIEVE_BOOT_COMPLETED
-android.permission.READ_SMS
-android.permission.WRITE_SMS
-android.permission.BROADCAST_WAP_PUSH
-android.permission.BIND_CARRIER_SERVICES
-android.permission.BIND_CARRIER_MESSAGING_SERVICE
-android.permission.INTERACT_ACROSS_USERS
Defined permissions:
-none.
How to Test The Custom URL Schemes?
You probably know already that the Android and iOS allow the inter-application communicating. It can be done through the usage of the custom URL schemes. What can they offer? They basically allow some other apps to perform some specific actions within the app’s hosting and the custom URL scheme. You will easily recognize them because they don’t always start with the https://. They can be shown with any scheme prefix. Let’s say a victim clicked on such a link. Once that happens, the app which is vulnerable will send the SMS to the mobile device. It will contain the maliciously crafted content. Where could that leave the user? Of course, to some financial loss or to disclosing its phone number.
So, once that the URL scheme has been defined, there are the multiple apps which can be registered for any scheme which is available. It also needs to be enumerated and the actions need to be tested.
They can be also used for the deep linking. It is a widespread and also a convenient method when launching a native mobile app.
Sensitive Functionality Exposure Through The IPC Testing
Imagine the process of developing the mobile app. In such an action, there are some of the traditional techniques that may be applied for the IPC. For example, it may be the usage of some shared files or also the network sockets. These mechanisms need to be applied because the mobile app platform implements its own system functionality. Always remember that if you are going to use some IPC mechanisms which have no security, you will leave your sensitive information and data more vulnerable.
We provided you a list of the Android’s IPC Mechanisms which may expose the sensitive data. Those are Services, Binders, AIDL, Bound Services, Intents and the Content Providers.
AndroidManifest
A place where all of the activities made, services and also the content providers which are included in the source code itself need to be declared. What might happen if they are not declared? Then, the system would not be able to recognize them and of course, they won’t run.
Okay, let’s say that you have verified your IPC mechanisms. What now? Review the source code. In that case, only you will be able to detect if they leak some sensitive data when used. Sometimes, it may happen that the content providers can be used to the access database information. Services may be probed to see if they can return the data. Besides that all, there are also the broadcast receivers which can also leak some sensitive information if sniffed or probed.
BroadCastReceivers definitely need to use the android: permission. If not, any other app can invoke them if it wants. Also, you can set the explicit app package name which will limit the components Intent will resolve to. If you leave it to the default value of the null, all of the components in the app will be considered. What if non-null? In that case, the Intent will match itself only with the components that are actually given in the app’s package.
I am pretty sure that you haven’t forgotten which are the places that hold the most sensitive data. Passwords, right? The keys? Those are the prime suspects when it comes to sensitive information leaks. What I want you to remember is that it would be the best advice to simply query those from the provider!
Once such an activity was created, later it will be called directly and the login from the password manager will be bypassed. Also, the data which was contained within the password manager can be accessed now. So, if you want to communicate with a service, first of all, you will need to use first the static analysis with a purpose to identify the inputs which are required. After that, once when the service is exported, you will be able to use the module app.service.send. Then, you will easily communicate with the service and also you will be able to change the password which is stored in the target app.
Hope that you have learned a lot from us! The more awaits you!