Years-old security flaw gives attacker full remote control of Android devices
Shows flaw laid out in detail at Defcon 18 months ago still offers back door to hackers
A security researcher has discovered an Android security flaw revealed in detail 18 months ago still exists and still offers an easy way for attackers to take root control of even updated Android devices without getting permission or passwords from the owner.
The flaw is a weakness in the assumptions Android developers made in creating the permissions-based security model on which Android devices depend, according to Thomas Cannon, R&D director at digital security company viaForensics, who posted a demonstration of his exploit yesterday.
Rather than having to install a virus or rootkit, attackers could build or adapt a legitimate app that, when installed, tells Android it is responsible for executing all code starting with a specific prefix – app://, for example.
When the app runs, it calls a particular web site that forwards the request to a second URL that begins with the prefix the malicious app already registered.
Android allows the code to download and allows the malicious app to execute the code because both have already registered with Android security as legitimate.
The prefix on files or messages accessible via the Internet creates the potential for two-way communication between the malicious app and a controller that gives the controller the ability to execute any Android command, access functions of many apps running on the Android device and run almost any code the controller decides to download, according to Cannon's demo.
The security hole is built in to Android's security framework, which allows apps being installed to register their own permissions using an XML file that tells Android what permissions it needs in order to operate and what permissions other apps need to call on its own functions.
Malicious apps can install with few or no permissions, but accomplish anything they want by calling either Android or other apps to provide them, according to a presentation on the security flaw made at the Defcon18 security conference in July, 2010 by Lookout Security's Anthony Lineberry, David Luke Richardson and Tim Wyatt.
If the installed app doesn't have permission to access the Internet, it can launch a browser, which does. It can be set to launch the browser only when the screen is off and the phone is otherwise inactive, to keep activity covert.
It can also load its own URI receiver, which would allow it to communicate back and forth with a web site without having to launch a separate browser, the presentation said (PDF of slides, m4v video).
It can also make itself far more unkillable with the "Circle of Death" takeover tactic, in which the application runs as an Activity with a rejuvenation feature built into its shutdown process.
If the user kills the malicious Activity, on the way down it launches a Service that relaunches the original Activity, according to the Lookout presentation.
The No-permissions Reverse Shell – the app Cannon wrote to exploit the weakness – doesn't do anything wrong from the point of view of Android's security.
"We’ve exploited the Android Web Browser, although we are not exploiting a vulnerability due to bad coding, but rather using the functionality it legitimately offers to other applications," Cannon wrote.
The exploit is not malware or a virus. It wouldn't be caught by the kind of malware screen Apple gives iPhone apps in its App Store.
The exploit takes advantage of the assumption that apps will be honest in the requests they make for permission, that users will double-check what permissions they want and that none of the apps will do anything beyond the strict boundaries of the user's own expectations.
In a smartphone market in which even the carriers install high-functioning spyware to keep an eye on end users, that approach is painfully naïve.
Cannon wasn't trying to criticize Android security, or to crack it.
He was trying to prompt more discussion about how to structure permissions for Android apps and get users to pay attention.
That's a lost cause. Users won't pay attention. They can't or won't be responsible for their own security.
Most of the basic security has to be done for them, and has to be built into either the devices or the operating system.
Cannon's little demo is another example of why Android's current security scheme needs a major overhaul, not a few minor tweaks.
Trust is a good thing, in general, especially in conjunction with verification. It's fine for Android to trust the security information applications give it, but only if it continues to keep track of what those apps do to make sure their main purpose is to provide a useful function, not to cross all the permission barriers Android can set up and hand off control to a stranger.
That shows a little too much trust.
Read more of Kevin Fogarty's CoreIT blog and follow the latest IT news at ITworld. Follow Kevin on Twitter at @KevinFogarty. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.