Android Application Security

Android based devices are exploding onto our consumer products scene. By my recent count at the wikipedia list of Android devices (http://en.wikipedia.org/wiki/List_of_Android_devices), there are 97 devices shipping today, and another 57 in the delivery pipeline.

On the volume side, Android devices are also showing rampaging growth. Gartner numbers show Android smart phones at 1.8% market share in Q209, rising to an astounding 17.2% share in Q210. While I don't have "smart devices (not phones)" figures, I'd expect even larger percentages for Android. (Who are the big losers of smart phone share you wonder? No surprises there: Windows Mobile and Symbian.).

Yet the Android model is fundamentally suspect at the level of 3rd party applications. Why? Simple: the bulk of these applications are from "boutique" developers or development shops, and there is absolutely no vetting of what exactly these applications do. The potential for malware in these applications is enormous.

Android does have a mechanism that requires applications "request" capabilities at installation time. However, it appears few pay much attention to that. A few million downloads of wallpaper applications that requested sufficient capabilities to send phone specific information (SIM ID, phone #'s, etc.) to a server in China certainly proved that point (why would you grant your wallpaper application internet access? Because it asks for it and you want the wallpaper, so..."yes" you click!). A security researcher, Jon Oberheide, demonstrated the potentially malicious application "Rootstrap", which bootstrapped a rootkit on an Android device. The app, (a preview of the popular movie Twilight Eclipse) routinely polled a server to see if new Android exploit code was available, and if so would download it into the application and execute it. About 200 people installed this app, and while in this case the compromised app didn't inject malware, it's a sober reminder of how you really have no clue what you are getting when dealing with Android applications.

Is the iPhone model better? From a security perspective, absolutely. Apple is doing something with apps to vet them. What exactly they do in this vetting process they don't share (and I like many others would like them to be much more transparent about this), but personally I'm reasonably comfortable loading an iPhone app onto my phone, but would hesitate long and hard before loading any application written by any unknown publisher onto my Android device.

Don't get me wrong, I do like the broader openness that Android devices offer. After all, it's my device is it not? I should have the right to load any software I want, in my opinion. At the same time, the marketplace needs to provide me with options for ensuring or identifying problems with the security of my choices. Those options don't exist today.

This leads different parties involved with the Android device phenomena to different (sometimes overlapped) sets of requirements.

First, for the consumer, there's an enormous need for Android application vetting, some high quality "seal of goodness" that is arrived at through a reasonably thorough review of the actual code in the app and what it is doing.

For the enterprise IT professional, there's a need for the same vetting service, and of course some device management services. Corporate phones should not be allowed to be loaded with arbitrary applications; all apps should be required to come from a secure enterprise location that holds only vetted (and dare I say business appropriate?) applications, or alternatively, a vetting service can offer a means for particular enterprise phones to only download applications marked as appropriate by that same enterprise's IT organization.

For the application developer, whether a small shop or an enterprise, there is another critical need. While Android applications are signed, they are self-signed. It is not difficult to take (as an example) a well known bank's application, insert into it high value malware, re-sign it, and publish it in way that gives an illusion that it is still from or works with the original bank. Applications need protection from this kind of malware insertion. Additionally there is the usual piracy problem. Recently Google initiated an attempted solution to this, with a licensing service. However, that led to immediately demonstrated trivial cracks allowing applications to run without licensing. In response, Google has said "oh, you need to obfuscate your application code". Why, thank you Google! What have I been prattling on about in this blog for the last year? Guard your application software folks, because if you don't, others will open it and have a field day stealing and modifying it to serve their own economic agendas.

Did I mention that Arxan is announcing support for guarding of native code in Android applications yet? Yes indeed: watch for our announcement this week.