[Editor's Note: Mobile devices, their associated infrastructures, and their juicy juicy apps are a fascinating arena that we pen testers are increasingly called upon to evaluate in target environments. In this article, Chris Crowley zooms in on a particularly important part of Android permissions known as "intents", which help control interprocess communication. Chris describes their features and outlines a process and some tools penetration testers can use to analyze them. -Ed.]
By Chris Crowley
Great pen testers strive to move through target environments seamlessly, transitioning from one platform to another. With more organizations adopting a "bring your own device" approach to mobile platforms without careful enforcement of security, attackers have new avenues for undermining organizations. Even in those organizations that officially forbid personally owned mobile devices, employees still sometimes connect their own devices to their networks surreptitiously. Or, they use authorized mobile devices which don't have property security measures in place. As pen testers, we need to inspect risk presented by these now ubiquitous devices. The good news: mobile devices provide plenty of avenues for adventurous pen testers to explore!
Some of the dominant concerns posed by mobile devices are data disclosure from an application inadequately protecting the data it contains, and the mobile device performing some action that costs the user or company money. Pen testers are increasingly called upon to find these issues and contain or help fix them before they cause a problem. (Convincing users and organizations to demand and pay for devices and applications to protect their data would be good, too. But, let's tackle that problem another day.)
When a user first installs an app on an Android device, they are typically presented with a laundry list of permissions that the app requests: create accounts, call phone numbers, identify the geographic location, modify the contents of local storage... and much, much more.
But this big list of app permissions doesn't tell the user what parts of those permissions that app is willing to do on behalf of other applications. Did you know that that app could receive requests from other applications to perform an action? In some cases, the action would happen without your approval or interaction, as your little "trusted" app does things on behalf of truly evil apps. Interprocess communication (IPC) is available on Android to make the user's experience more seamless. In this article, we'll take a quick look at the functionality and a couple of ways pen testers can inspect applications on Android for unintentional flaws.
Here's a simple example. You're browsing a web page on a mobile device. You searched for the best espresso drinks in the area. The web page of an interesting-looking cafe displays an address and phone number. You intend to stay up late working, so you call to make sure they're still open at 10:00 PM. You click the phone number. Note that your web browser doesn't make the phone call; instead, it passes that phone number to the telephone application to make the call for you. This is intentional, but not evil... yet.
To make this work, the android platform uses an inter-process communication capability called "intents", which allow communication between the parts of one application or between different applications. An application's intent capabilities are enumerated in the manifest of that application. That's the AndroidManifest.xml file within the Android package file. The package file typically has an apk extension.
You can see the declared permissions and intents in an Android .apk file in a few steps:
- Download the .apk file, or recover it from the Android device itself, if you've rooted the device.
- Unzip the .apk into a folder using 7-zip or another unzip utility. There's a manifest file called AndroidManifest.xml that will be among the unzipped files and directories.
- Use AXMLPrinter2.jar to read the encoded contents of the XML file:
$ java -jar AXMLPrinter2.jar AndroidManifest.xml
You can review the XML file which includes declarations of permissions and intents. Here's an example activity with an intent-filter.
Figure 1. Example intent-filter for the LoginActivity
We trust the web browser on our Android devices not to access other apps inappropriately. But this technique allows applications to interact with one another. It is of interest because a seemingly legitimate application could leverage this inter-process communication to access resources in the applications we've installed, or the applications that come bundled with the phone when it is purchased.
A proof of concept piece of malware was discussed recently on the Bugtraq mailing list for a subsequently updated version of the Facebook for Android application (http://seclists.org/bugtraq/2013/Jan/27). The vulnerable version of the application allowed an attacker to exfiltrate app data from the mobile device, if the user was logged into Facebook at the time of the attack, and had installed the attacker's malware.
Now, that is some intentional evil. A piece of code that has the best intentions, but not the best intents. The flaw exists because the intent action doesn't adequately assess the action requested, and would result in data disclosure from the application's data store, including contacts, and performing actions as the logged on user.
So, as penetration testers, we need to figure out what our installed applications offer to perform on behalf of other apps, in an effort to better understand the security risk of the application and the overall device itself. We could extract all of the AndroidManifest.xml files. But, the manifest only declares the intent and its associated permissions. Then, we would need to review the code to figure out the details of the intents offered, a pretty huge undertaking to do manually.
Fortunately, MWR InfoSecurity has released a wonderful tool called Mercury. It's a client-server framework, with an agent (the client) installed on the Android device (physical or emulated). The server runs on your Linux or Windows system, providing a bi-directional communication channel for you to enumerate the components of other applications that are available to the agent. IPCs available to explore via Mercury are services, receivers, activities, and content providers, all of which are various aspects of applications that you can analyze, evaluate, and possibly attack. Activities, for example, are user interface screens for directing action. Once you have Mercury on a device to inspect, you can snoop around to see what intents are available to your Mercury agent. You can also craft action messages to determine if the applications are exposing excessive privilege.
Figure 2. Example of attack surface and intent enumeration
The next step would be to enumerate the expected data for each of the intents and then attempt to craft messages that would request the application to perform an action which might be undesirable, such as accessing data within the application, or having the application send a message. In the application inspected above (a little ditty called "Facebook" for Android 1.8.1), the com.facebook.katana.LoginActivity was the vulnerable intent which allowed the exfiltration of data.
Josh Wright recently released an update to SANS Security 575: Mobile Device Security and Ethical Hacking that includes a new section on Android intents. In the class, we explore the detailed plumbing of the mechanism using the Mercury framework. Mercury provides an insertion point to explore the running android device as an unprivileged application, letting us model the environment where a piece of malware would find itself.
Using the Mercury framework and manual inspection of source code, we can look for intents that accept requests from apps and use this ability to attempt to access data within the application's data storage or to perform an action under the authority and permission of the application, such as silently sending an SMS message. The exposure of application data via a content provider intent would be a valuable finding in a mobile device pen test. Furthermore, silently sending SMS messages is a common vector of information leakage and outright theft from within Android based malware.
If you want to have a look for intentional evil yourself, you can download an Android emulator to run on Windows and install Mercury on it. Or, you can install Mercury directly on your Android device itself. Thankfully, Mercury doesn't even require a rooted Android. You can also take a look at the OWASP GoatDroid project, which provides FourGoats (a social media app) and Herd Financial (a banking app) for your inspection and analysis.