Security Anti-Pattern - Mobile Castles on Sand (or why app wrapping is not a security model)

April 11, 2013
Security SE Android MAM

#Mobile Application Management (MAM)

Mobile Device Management (MDM) was all the hotness just a few years ago. It gave IT departments the ability to manage both corporate owned devices and devices owned by employees (BYOD) but it was dissatisfying. As BYOD became more prevalent and corporate owned devices less it made users feel like they were giving up all control of their device to their employer, mainly because they were. Most users at this point probably know the feeling of adding their corporate credentials into their phone and seeing the dreaded ‘you are giving administrators the ability to wipe your phone, install apps, remove apps, and locate your phone’ screen.

Then there was the issue of having multiple administrators that wanted to do different things with your device.

Even for the administrators, the solution was incomplete. It did not give them the ability to manage app configuration, app storage, app authentication, etc.

That is where MAM comes in. For the administrators it means they can package apps with configuration, version it, push it out and wipe only corporate app data when an employee leaves. The nicer systems add single sign-on so that a user can authenticate once and get access to all corporate apps. They also store corporate data encrypted and can report usage statistics back to corporate IT. For users it means that they don’t have to give up full control of their device.

Sounds great, right?

##How does it work?

Well, mobile devices don’t typically have this kind of granular control built in. Further, off-the-shelf applications generally don’t come configured or support single sign-on. The solution that MDM vendors started peddling is called app wrapping. Basically it means that the IT department takes the apps they want to manage (whether they are internally developed or 3rd party) and runs a tool from the MAM vendor that packages the app within another app, the wrapper (or the castle).

Apps in a castle

The outside package interacts with the real device, including storing data to disk encrypted, verifying credentials with corporate authentication servers, etc. The fancier ones even prevent apps from running outside of specific physical locations (geofencing), and will attempt to detect a rooted device (though that is impossible in practice).

So, this still sounds great. From a functionality point of view this is a superior experience for both the user and IT, so what is the problem?

Userspace containerization (or building castles)

Lets start with the obvious one first. The inside (wrapped) app is modified to not be able to interact with the real device, but to interact with the wrapper instead. Two standard ways this is done is by providing an SDK that corporate apps can be written with and the other is called app wrapping. It should be noted that while using the SDK is the safer option, it will likely lock you in to a single MAM vendor.

App wrapping on Android involves modifying the Dalvik bytecode ahead of time to add all of the functional additions as well as changing functions that would normally interact directly with the system (think filesystem operations, intents, binder calls, etc) to use analogous calls in the wrapper instead. The effect here is that the wrapper can 1) ensure filesystem writes only go to allowed locations and are encrypted and 2) to prevent IPC with apps outside of the “container”.

Well, that is the thought, anyway.

No one in their right mind would believe that they can write a libc wrapper that intercepts open() calls to make security decisions and think that it buys them anything, but that is fundamentally what is happening here. App wrappers cannot contain numerous, supported features on Android such as jni to native libraries and java reflection. A particularly crafty app might even have a scripting language interpreter or its own java class loader that would be nearly impossible for the wrapper to understand and secure.

There is no chance that an MAM implementation could keep an app that wanted to exfiltrate corporate data from doing so. That is an easy problem to solve though, you only wrap trusted apps, because they are either corporate or known 3rd party apps, right? Well, hopefully, for your sake, those apps don’t have vulnerabilities that a spear phisher can take advantage of to gain access to corporate data (spoiler: they do).

In the scheme of things this is a relatively low threat, though, so lets move onto the real issue.

The insecure platform (or the sand)

People have tried building secure on top of insecure as long as personal computers have been around. The appeal is that there is always an insecure platform, be it Windows, Linux, iOS, or Android and there is always a need to access secure data is always there.

I’ll take this opportunity to suggest that, if you haven’t already, you should read: The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments

The fact is that if the system below your application isn’t secure no amount of anything will make your application (or wrapper) secure. Detecting rooted devices is not enough. Most detection is heuristic, such as checking for the existence of /system/xbin/su. Suppose the device is not rooted by the user such that su exists but by an adversary? Root access gained for the intention of stealing corporate data would not likely be detected by an MAM solution and therefore malicious applications running on the device would be able to affect the corporate apps in various ways, from communicating with them, bypassing the wrapper, all the way to scanning their memory and extracting corporate data.

Most snake oil vendors will claim encryption solves this problem. Encryption may be a suitable solution to data-at-rest, data not currently being accessed that is sitting on disk, but when your corporate email app is running the emails are in memory, not encrypted. Even if an industrious app writer did extra work to keep them encrypted in memory the decryption key must also be in memory, and is vulnerable.

So, this is the real threat. If your app has data I want and it runs on a standard Android or iOS phone, I’ll be able to get it, no matter what your MAM vendor is telling you.

As a non-security related aside, you probably don’t have permission to download 3rd party apps from the app store and wrap them, which would constitute unlicensed distribution, you’d have to get permission from the app owner. An interesting ramification of this is that GPL apps can’t be legally wrapped since the GPL license of the app would have to apply to the wrapper as well.

The solution

Just like in standard computing the solution isn’t hard, but is rarely used.

You must have a secure host platform if you want your applications to be secure. Unfortunately not many options exist for this but fortunately there are options that are freely available. The one that I favor is, of course, SELinux. I’ve been involved in building SELinux systems to secure even the most important data for nearly a decade now and it has proven true.

Anecdotally, I have security researcher friends who work on the offensive side of the fence that have told me when they encounter an SELinux machine they bail and look for an easier target. It is important to note that we aren’t talking about out-of-the-box Fedora installs, though, but systems intentionally and knowingly hardened against this type of adversary.

Which brings us back to Android. The Security Enhanced Android (SE Android) project has been picking up more and more steam. Much of it is already merged into AOSP which allows all Android vendors to use it and recently Samsung has announced a device that will have it included by default. This is definitely a step in the right direction but a far cry from what it will take to feel confident allowing important corporate data to be accessed on non-corporate owned devices.

With a secure platform you can enjoy the functionality benefits of an MAM solution and be confident that security provided by the platform will keep their castles secure, both from the inside and the outside.

Unfortunately, none of this is a solution you can use today. Technology must, as usual, catch up to market demands. The demand must be there, though. Demand secure platforms. There is no excuse for Android vendors to not include SE Android in future offerings, all the hard work has already been done by early adopters.

Update: My next entry has validation for this post, seen in the wild.

Algorithmic passwords - Memorable, high entropy, and unique

July 17, 2018
Security Authentication

SE for Android on the GS4 Google Play Edition

July 8, 2013
Security SE Android MAC exploit

SE for Android GS4 howto and exploit demo

June 28, 2013
Security SE Android MAC exploit