Android Market XSS Bug Allowed Code Execution on Mobile Devices

2011-03-07T13:58:15
ID THREATPOST:074125AB28AB70A0D19727D8AC3FA88B
Type threatpost
Reporter Dennis Fisher
Modified 2013-04-17T16:35:00

Description

XSSA simple, trivially exploitable persistent cross-site scripting bug on the Google Android Web Market allowed anyone to upload an app that could be used to later run arbitrary code on the user’s Android device. The vulnerability, which Google has patched, enabled an attacker to silently install his malicious app and then get any and all permissions on the device.

Security researcher Jon Oberheide discovered the vulnerability recently and developed an exploitation scenario in which an attacker who could entice a user into clicking on a URL in the Web Market could force the user to install his malicious app. The attacker could then use one of a couple of methods to gain arbitrary code execution with the malicious app on the Android device. By inserting a small bit of HTML code in the field that developers use to describe their apps when their publishing them, an attacker can trigger the XSS vulnerability on a user’s browser when he clicks on the link the Web Market to install an app.

The Android Web Market includes functionality that enables users who are browsing the Market on a desktop machine to automatically install apps on their devices simply by clicking on a link in the Market. The Android OS doesn’t give users a prompt on the device to confirm an app install, which makes the attack scenario simpler.

“Since there is no on-device prompt or confirmation for these INSTALL_ASSET requests pushed to your phone, an attacker can silently trigger an malicious app install simply by tricking a victim into clicking a link while logged in to their Google account on their desktop or on their phone. The malicious app delivered to the victim’s phone can use any and all Android permissions, allowing for all sorts of evil behavior,” Oberheide said. “Simply installing the app does not result in code execution since apps do not auto-start upon install on
Android. However, we can easily emulate this functionality effectively to auto-start our app and gain code execution.”

There are two methods that an attacker could use to gain code execution once his app is installed. The first scenario involves having the app register for the PACKAGE_ADDED broadcast intent in Android. One that’s done, the malicious app will run anytime another app is installed on the device, and because the attacker can control the user’s browser via the XSS bug, he can force another app install and then use this method. The second way to gain code execution uses the mobile browser.

“Alternately, if our XSS is taking place within the browser of the mobile device itself, we can simply insert a hidden IFRAME in our XSS payload, continually set the src of the IFRAME to something like ‘trigger://blah’, and then have our installed malicious app register an intent filter on the ‘trigger://’ URI scheme,” Oberheide said. “This will cause our malicious app to be triggered and gain code execution as soon as it is finished installing.”

The vulnerability that Oberheide discovered, which Google has now patched, was present since the Android Web Market launched in February. It is just the latest issue to affect the security of the Android Market and comes just a week after researchers discovered that more than 50 apps had been uploaded to the Market that were infected with the DroidDream Trojan. That malware was designed to steal data about the infected phone and then download further malicious code.

Google removed the apps from the Market and is using its remote-wipe capability to delete them from infected Android devices as well. The company said over the weekend that it was pushing a fix for the Android vulnerability that the DroidDream attack leveraged and also is adding some unspecified new security measures to the Android Market to prevent future attacks like this.