We decided to write this post for many different reasons. First, we want to set the facts straight. The interactions involving this method and the security issues that result from it are complex. Understandably, some published articles contain technically inaccuracies. Second, we have been doing more testing and think that some of the test results are interesting. Finally, we want to make some recommendations to various parties within the ecosystem and document open questions in and future directions for our research.
NOTE: This post ballooned significantly. As such, we will be working to publish more details in the future.
In this section, you will learn about the different technologies and paradigms that come together to create the issues that are the topic of this post. This includes introductions to software handling on Android, the vulnerable API, and important properties of these vulnerabilities.
Software on Android
Software on Android devices consists of firmware and applications. Each type of software are versioned, distributed, and updated using different mechanisms.
The firmware for a particular device is built by the party responsible for maintaining the device. The firmware is put onto the device by that party and later updates (via OTA usually) must go through that party as well. In addition to the Android version, OEMs and carriers have their own versioning schemes. This part of the Android software update process is discussed in depth elsewhere, so we won’t elaborate further.
Applications are either distributed as part of the firmware or via Google Play. In both cases, the applications can be updated directly by the vendor via Google Play. Applications are versioned by their respective vendors.
In addition to the Android version, Google uses a versioning mechanism to indicate the precise availability and behavior of objects and methods. These objects and methods comprise the developer API, and hence this version is called the API level. As the API levels have increased, many changes have been made. The developer documentation contains lots of notes about changes throughout the evolution of Android.
Application developers choose which API level they use for their application at compile time. When a new API level is released, developers don’t have to do anything unless they want to take advantage of functionality from the new API. That is, app developers are free to select an older API level when they build their application. Google has tried to dissuade this practice in newer versions of the SDK by printing warnings at compile time. Also, Google created Google Play Services to ease some of the pain caused by API evolution. However, no technical barrier prevents using older API levels. In fact, some developers do this intentionally as a way to maximize device compatibility. Once an application is built against a particular API level, it cannot be changed without recompiling and redeploying.
In Android, many browsers web-based mobile applications rely on the WebView component. The documentation for this component is pretty good, so check it out if you want to fully understand it’s purpose and usage. Suffice to say that it’s a part of the Android Framework that provides a working, embeddable Web browser. On versions prior to Android KitKat (4.4) it’s based on the WebKit engine. With KitKat and later, it’s based on Chromium. It doesn’t include the UI portion which is also referred to as “the chrome” (not to be confused with the Chrome browser).
In all cases, exploiting vulnerable apps gives an attacker the privileges of the app itself. However, wide public availability of privilege escalation exploits for Android devices can lead to a full device compromise.
- URL-based attack vectors such as sending a URL via email, IM, SMS, etc.
- Malicious advertisements (aka Malvertising)
- Injecting an exploit into a compromised trusted site (e.g. a watering hole attack)
- Man in the Middle attacks (MitM) such as DNS hijacking, rogue AP/BTS, etc.
The most severe issues can be exploited in all scenarios while slightly less severe can only be exploited via a subset.
The decision to open source jduck’s exploit module at the end of January 2014 set in motion the sequence of events leading to this post. Though MWR Labs published an exploit in December 2013, their Drozer tool simply doesn’t have as large of user base as Metasploit does. The original goal stood and so the module was released publicly.
Starting in early February, the Metasploit engineers took jduck’s work and started looking to integrate it into their penetration testing framework. Some of their efforts are documented in the pull request initiated to merge it. As seen in description of the pull request, Rapid7’s Joe Vennix discovered that after minor modifications jduck’s exploit module was able to remotely execute arbitrary code on older versions of the stock Android Browser app. This was news to us, as it hadn’t previously been reported publicly by anyone (including Google!).
Further testing by Tim Wright showed that the exploit also works on the current version of Google Glass (XE12 as of this writing). Even worse, an exploited Google Glass browser yields camera permissions. That’s right. This exploit allows an attacker to see whatever someone who is wearing Google Glass sees. On top of that, several publicly available exploits are capable of gaining root privileges on a Google Glass device. These facts combined should cause quite a concern for early adopters of this exorbitantly priced gadget.
Following these events, another media blitz ensued with many articles claiming that 70% of Android devices are vulnerable to this particular exploit. A lengthy discussion on a post to the /r/Android sub-reddit had us defending our research against vehement opponents. Truth be told, the 70% number came from an assumption that all devices prior to Android 4.2 were affected. We had tested against only a handful of devices at that point and thus decided to do some more thorough testing against the stock browser of various devices.
First, jduck set out to create a simple and safe test page that would detect whether or not the WebView in which it was loaded was vulnerable. The Rapid7/Metasploit team assisted in organizing some crowd-sourced testing on Twitter while he tested against the droidsec droid army. Each of jduck’s devices run stock firmware (in most cases the latest available), so the tests are a decent sampling of the over all device pool. Further, Joe Vennix ran some tests against one of the public testing services to see how their devices fared. The results of this round of testing were quite interesting and several new facts were uncovered.
Through our testing, we have discovered several important facts worth discussing. The key findings are:
Some devices using versions of Android within the affected range (4.0 < x < 4.2) were not vulnerable. This indicates that OEMs/carriers back-ported the patch to their firmware somewhere along the way. It’s possible (maybe even likely) that Google notified these partners of the issue to spur movement without notifying the general public. Determining the entirety of vulnerable device + firmware combinations remains an open problem (and one that we are actively seeking to address).
An additional insecurely exposed object was found within certain HTC device firmware versions. In particular, testing against the One V and One X+ on Android 4.0.3 and 4.1.1 showed that an object called HTMLOUT was exposed. Interestingly, this is the exact name of an object that was discussed in a blog by Aleksander Kmetec in 2009. (NOTE: A quick search while writing this post turned up this advisory on WooYun. We don’t believe a CVE has been assigned yet.)
Certain versions of third-party browsers are also vulnerable. In particular, certain versions of the Dolphin Browser tested vulnerable. Unfortunately, the exact version and list of exposed objects are not available.
Despite the fact that these issues have existed for years, several of these findings have only come to light in the last month. These issues are important and need more attention. The next section provides some suggestions about what various parties in the Android ecosystem can do to help.
These issues have not been holistically addressed. Thankfully, there are a number of things that various groups within the Android ecosystem can do to improve the situation. Without intervention or assistance from Android vendors, we are largely left to our own device to protect ourselves and our users.
That leads to the first, and most important, recommendation for everyone in the ecosystem. Communication is key. We as a community need to spread the word about what brings these issues about, how to avoid them, how to locate and fix instances of them, and so on. Please do your part to help make the Android ecosystem a more secure place.
Google - You took a positive step when you made that security enhancement in Android 4.2. However, the original “fix” and messaging surrounding it leave much to be desired.
On the “fix” side, a more aggressive approach would be far more effective. Had you taken such an approach, you might not be reading this post. Because of the approach you chose, developers can still build, and are still building, vulnerable apps today. These apps can even be exploited on the most up-to-date devices. These are serious vulnerabilities and they should be given the respect and urgency that they deserve. We plead with you to take more aggressive actions to remedy this blight.
OEMs and Carriers - Some of you have done a good thing by back-porting the fix to older firmwares. That’s great for the devices that did get updated, but that leaves users of older devices exposed. We dream of a day when you don’t leave anyone behind. The time from a security fix to it being on users’ devices really should be on the order of days, not months or weeks. We implore you to find ways to continue to improve this process.
Users - The security and privacy of your device is ultimately in your hands. Keep your eyes and ears open for information about vulnerable apps. Don’t connect to potentially malicious Wi-Fi access points. Remove vulnerable apps from your device until they can be updated. Give 1-star ratings to vulnerable apps. As a precaution, play ad-supported games in airplane mode. Pay for your apps so that advertising network code is never activated.
Future Work / Open Questions
While putting together this research we have identified a number of gaps and outstanding questions. We have additional details that we plan to publish in the coming days and weeks. Ideas for future work include:
More testing - Our test results are fairly limited. We’d like to solicit more high quality test results from the community at large. We’re thinking of the best way to enable this testing, but for now following the directions on the test page would help.
More devices - Our test bed is fairly small. We’d love to add more devices, and have added a plea for devices to our donation page.
More research - Our tests looking into whether or not compiling a library for Android apps causes apps that use that library to be vulnerable were inconclusive. Do they build against a particular API level? Can they use a different API level than the app they are included in? These are questions we’d like to answer.
There’s more than enough for us to do. We would love your help!
The perilous situation of more than 51% of the Android device pool running woefully outdated software remains. As mentioned previously, many of the tested devices are fully updated to their latest stock firmware. In our testing of 44 devices, 13 were running browsers in the vulnerable version range. Of those, 6 had a vulnerable stock browser. Extrapolating these numbers out accurately is impossible without the exact numbers of each device/firmware combination, but a fair estimation is something like 25 percent (46% of 51%). This is much less than the 70% quoted in many articles, but also doesn’t take into account the other issues surrounding this method (which are much larger issues).
In closing, there is much to do before this saga will end. We’ve provided some recommendations for various parties in the ecosystem and hope that they will not fall on deaf ears. That said, we’re not naive. We recognize that there are many challenges on the road ahead of us. Through our initiatives we hope to overcome these issues and usher Android security into a new era.
Be safe out there!