Three Steps to a Cracked Android Device

Monday Jul 26th 2010 by Paul Rubens

Researchers at Hack in the Box Security Conference 2010 demonstrated how to hijack an Android device using a malicious app, some social engineering, and Google's laissez faire management of the Android Market.

In the first piece in this series we looked at an iPhone vulnerability which makes it easy for a hacker to hijack an iPhone's data connection, and the serious security implications this could have for your network.

But the iPhone is by no means unique in being susceptible to data hijacking -- weaknesses in Android's UI and in its permissions granting mechanism mean that phones running Google's open source mobile OS can have their data connections hijacked just as easily. If the data connection is rerouted through a proxy under a hacker's control then they can browse the data and gather confidential information such as user names and passwords, which could then be used to compromise an entire corporate network. Android data hijacking was demonstrated by Roberto Gassira and Roberto Piccirillo, two researchers at Mobile Security Lab, at the Hack In The Box Security Conference 2010 in Amsterdam in July.

Hijacking an Android device's data connection is done using a malicious application, and involves three steps:

  • Creating an application that can change the default APN configuration for the device the application is running on so that all data runs though a proxy controlled by the hacker.
  • Distributing the application through the Android Market (or elsewhere.)
  • Ensuring that the application’s ability to change APN settings is not obvious to the victim when they install the application.

Creating an Application

The most obvious question to ask is what sort of application the hacker should create, and the answer is that it actually doesn't matter. That's because it's only important to describe the application in such a way that the victim is tempted into downloading it. If the app doesn't do what the victim expects, they may uninstall the app; but again, this doesn't matter because by then the application will have changed the default APN settings on the victim's device so that data runs through the hacker's proxy.

Writing an application that is capable of changing a device's default APN configuration is straightforward because the Android SDK allows developers to build applications that change a number of device settings, including the APN settings. To do this a developer has to use Android's permissions granting mechanism, and during the install process the user will then be asked to grant the various permissions that the application requires.

A hacker writing a malicious application that modifies APN settings must therefore declare that the application requires permission to do this in its AndroidManifest.xml file, using the "uses-permission" tag:

The Android APIs allows APN settings to be changed using a "content provider," which provides an interface for reading or modifying data from applications and which is identified by an URI that begins with "content://". The specific content provider for APNs is identified by content://telephony/carriers and the default profile is listed in content://telephony/carriers/preferapn

The evil application modifies the default profile by adding an IP address for a malicious proxy and its associated port number. The proxy itself would be based on Apache with mod-proxy, Moxy Marlinspike's sslstripand mod_security, as described in the first article in this series.

Distributing the Evil App Through Android Market

Distributing the app through the Android Market doesn't present any problems, because Google does not monitor the apps published there. This is spelled out in section 7.2 of the Google Apps Marketplace Developer Distribution Agreement : "Google Takedowns. While Google does not intend, and does not undertake, to monitor the Products or Professional Services or their content..."

There are obviously a large number of applications available in Android Market, but if a hacker has a particular target in mind then it might well be possible to persuade this victim to download the app using social engineering techniques, and even tailoring the description of the app to match the victim's know interests.

Granting Permissions by Stealth

When a user installs an Android app, they'll be prompted to grant the application various permissions (which are listed in the AndroidMinifest.xml file) by a dialog box like this:

As you can see from this screenshot, only the first few permissions are visible on this list - the user has to scroll down to see any remaining ones. The key thing here is that the hacker can select the sequence of the permissions displayed in this list.

That means they can make sure that the first four or five on display are more innocuous permissions that a user might expect to grant for the type of application being downloaded, and can "hide" the one that allows APN settings to be changed at the very bottom. This won't be seen by the victim, unless they take the time to scroll down the list right to the very bottom:

Most unsophisticated users will simply click the install button and run the application - and their Android device's data connection will be completely visible to the hacker.

Protecting Users Against This Kind of Attack

This attack takes advantage of the poor way that Android GUI displays permissions requests and takes advantage of the fact that Google does not attempt to vet apps before they appear on the Android Market (and allows them to be distributed elsewhere as well.) The best way to mitigate against it is to educate users of the importance of examining and understanding all permissions requests that an app presents, and warning them that some permission requests may not be visible without scrolling down list, before deciding whether to install the app or not. In particular, users should probably be advised not to install any application that asks for permission to change APN settings.

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved