Mobile phones have become an indispensable part of our daily life. We use mobile phones to communicate with our loved ones, for quick access to information through the Internet, to make transactions through mobile banking apps or to relax reading a good book.
In a way, a big part of our private life has moved into the digital environment. Mobile phones seem to be a pocket-sized treasure of secrets and information, hiding our most valuable photos, mails, contacts and even banking information. There’s no wonder why we need mobile phones to have bullet-proof security.
Android is the most common operating system for mobile devices and is particularly interesting from the security point of view. It is very permissive, allowing its users to customize about anything, administrative privileges (a.k.a. rooting) can be unlocked on most phones, it has a very fuzzy system for the permissions required by applications and it features different ways for one application to interact with other applications.
In this blog post, we are going to focus on how Android apps can interact with each other and how the security of those interactions can be tested.
How apps can interact with each other
The main methods for inter-app communications are:
- One application can send an intent in order to start an activity exported by another application;
- One application can access content provided by another application, using content:// URIs;
- One application can broadcast an event across applications in order to interact with a broadcast receiver implemented in another application;
- One application can access a service exported by another application.
As you can see, there are a many interactions. Testing in a old-fashioned way (by creating an app for every test you have in mind, installing it on your device and running the test-app) is very time consuming, so it’s not really a solution. Here is where Drozer comes into play.
Drozer is an ambitious project developed by MWR InfoSecurity. Although it is a Swiss army knife kind of tool, I will focus on how it can be used in order to start with an exported activity.
First of all, you need to install Drozer. You can do so by going to the official page and follow the instructions, or you can download Appie – a set of tools created for mobile penetration testing, it contains a portable version of Drozer.
Second of all, you need to install Drozer Agent on your mobile device. The mobile device does not need to be rooted. Drozer Agent is an Android application that requires minimum privileges (internet access only) and acts as a bridge between the Drozer install from your computer and your mobile device. You can download it from the same sources as mentioned above, keeping in mind that the Drozer version and Drozer Agent version should match.
The third step is to install on your mobile device the application that you want to test. For testing and training, you can use one of the following applications:
- sieve – a damn-vulnerable application developed by MWR InfoSecurity;
- FourGoats – a vulnerable application included in OWASP’s GoatDroid project;
- Herd Financial – another vulnerable application included in OWASP’s GoatDroid project;
- a real-world application, I’ll use for this demo Firefox for Android – installed from Google Play.
Connecting Drozer to the mobile device
In order to connect Drozer to the mobile device, we need to follow the next steps:
- Connect your mobile device to your computer using a USB cable;
- Open Drozer Agent application on your mobile device and click the ON button from the bottom-right;
- Use adb.exe to open a TCP socket between your computer and the server embedded in Drozer Agent: adb.exe forward tcp:31415 tcp:31415
- Go to the folder where you installed Drozer and connect to the mobile device: drozer.bat console connect
Starting an activity from another package
Ok, now we have an interactive Drozer console. What can we do? Let’s start an activity, command by command:
- list, will display a list of commands available in Drozer
- run app.package.list -f firefox to find a list of packages that contain the string “firefox”; we found org.mozilla.firefox.
- run app.package.attacksurface org.mozilla.firefox to identify the attack surface for our application; we found 113 exported activities, 12 exported broadcast receivers, 8 exported content providers and 1 exported service; this is a good example of a big attack surface.
- run app.package.manifest org.mozilla.firefox to extract the AndroidManifest.xml file for our package (to find details about the exported activities).
- run app.activity.info -a org.mozilla.firefox to list the exported activities; we can see that there is an exported activity named org.mozilla.firefox.App that does not require any permission to be started.
By analyzing the AndroidManifest.xml file that we previously retrieved, we can see that org.mozilla.firefox.App is defined as an alias for web.mozilla.gecko.BrowserApp activity and that it has multiple intent filters (an intent must comply with at least one filter in order to start the activity).
- run app.activity.start –component org.mozilla.firefox org.mozilla.firefox.App –action android.intent.action.VIEW –category android.intent.category.DEFAULT –data-uri http://securitycafe.ro to start an activity.
As a result, Firefox opened a new tab on the mobile device and navigated to a really cool website.
So, what happened? The short story is that Drozer Agent, an application without special permissions installed on our mobile device, can start activities that were exported by other apps. And this is just the tip of the iceberg.
It is important to understand that any other application out there can initiate an Intent like this, not only Drozer. If you want to test by yourself and create a simple Android application that starts an intent, here is the equivalent code for the Drozer syntax used above:
What if the activity requires special permissions to be started?
If the activity is protected from one of the permissions listed here, then we can build our own Drozer Agent with extended permissions. It is not impossible for malware apps to get installed with extended permissions, most users will accept any permission request without reading them.
As a short detour, I consider Android’s permission system to be broken. Here is an example (permissions required by one of the most used Flashlight apps from Play Store):
Should a lantern be able to take pictures and videos with my camera? No. Should a lantern be able to download data from the Internet? No. Should I allow a lantern to have full network access? No. Should I allow a lantern to modify my system settings? Of course not.
That is just an example, but it illustrates really well how you can’t tell if an app is harmless or not, judging only by the permissions it requires. So, if a Flashlight app gets installed on more than 100.000.000 devices with extended permissions, then it’s safe to assume that malware will get installed on victim’s device with some permissions; it would look suspicious if the malware app wouldn’t require any permission at all.
Back to our goal, we can build a Drozer Agent with specific permissions using the Drozer instance from our computer: drozer.bat agent build –permission “android.permission.SOMETHING”
If we install the newly built Drozer Agent on our mobile device, we will notice that it requires the added permissions.
After installing the new Drozer Agent, we can follow the same steps, described in this article, to start an activity that requires specific permissions.
In the end, I’d like to point out that Android features a complex security model and, sometimes, complexity is the worst enemy of security. Having in mind all the interactions that are possible between apps, we should test in depth the security of the apps that we build. It’s better to be safe than sorry!