Last updated at Wed, 07 Apr 2021 18:36:15 GMT

This post is the ninth in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements and events in the Metasploit Framework over the course of 2014.

It has been a busy year for Android exploitation here at Metasploit. As the makers of the greatest pentesting toolkit on the planet, vulnerabilities that affect over 1 billion active devices greatly interest us, not to mention the amazing independent researchers out in the world, such as Rafay Baloch and long-time contributors Joshua Drake and Tim Wright.  Earlier this year I began researching exploitation vectors into Android that could affect the average user, not expecting to find much. I was in for a surprise…

In early February, I was testing a module that Joshua @jduck Drake wrote for exploiting a known vulnerability in the WebView implementation on devices before 4.2 (this represented about 70% of active devices at the time). The issue affected apps that called addJavascriptInterface to inject a Java object into the Javascipt environment. This feature was commonly used by apps with ad components to render their HTML ads. By abusing Java's reflection APIs the Javascript code in the ad could run shell commands. jduck's module implemented an HTTP proxy server that would man-in-the-middle (MITM) the Android device and inject malicious Javascript code into HTTP ads, in order to drop and execute a reverse shell. This worked well but required the attacker to have established a MITM stance on the target.

As I tested jduck's module, I ran into some problems (with the sample app I had built, it turns out). Attempting to debug things a bit I opened the malicious Javascript code in the stock Android browser: to my surprise, I got a shell! I reached out to jduck who verified that indeed many stock browsers were vulnerable - 70% of all devices had a built-in browser that was trivially exploitable. This turned out to be a separate, unreported vulnerability in the AOSP Browser app. I was not the first person to notice this either - later I found references to the bug on wooyun.org.

With my discovery in hand I tweaked jduck's module a bit to turn it into a browser exploit, added it to Browser Autopwn, and pushed it up for review. The initial module had its share of problems - it was not compatible with 4.0 devices, and it merely gained a shell in the context of the user - many Android permissions were lost along the way (like camera). With a lot of help from community contributor timwr, we were able to get a working Android meterpreter session from the exploit that retained the permission level of the browser.

Some months later, it was reported that the Adobe Reader app for Android exposed injected Java objects to Javascript code running in a PDF. After a bit of frustration, I moved the actual exploit logic into a mixin and was able to get a File format exploit module working that generated a PDF that spawn a Meterpreter session.

addJavascriptInterface lives on

In many ways, this exploit continues to be effective. For example, apps with ad views that were built before API level 17 are still vulnerable to jduck's original MITM vector. A discussion of the issue can be seen here. Eventually Android 4.4.4 was patched to prevent the Object.getClass call from being used, closing the hole for good on new devices.

Android Meterpreter Improvements

In late May, community contributor Anwar Mohammed added many improved commands to assist in exfiltrating data from targeted devices. These commands included dump_sms, dump_calllog, and geolocate. Of course, for these commands to work, the Meterpreter process must have the necessary privileges, which depends on the exploited application. For example, some Browser apps would run with webcam permissions, meaning the webcam_snap command was available.

In September I was reading through some public exploit code when something caught my eye - a trivial UXSS vulnerability in the Android stock browser on versions 4.3 and earlier. Security researcher Rafay Baloch had tried to report the vulnerability to Google with no success. UXSS vulnerabilities happen now and then in pretty much every browser, and allow content served by an attacker to access resources they are not supposed to - like cookies and CSRF tokens for another domain (say, bank.com). What was unique about this vuln was that I was sure I had seen it before. And I had - from a 2010 bug in Chromium (reported upstream to WebKit). It's a little mysterious as to how a 2010 bug affected an OS that shipped in mid–2013. Android's copy of WebKit was simply not kept up to date with upstream WebKit, and a bunch of security patches were missed. I had read this before (here is a 2011 presentation where ~20 WebKit bugs were found in Android 2.3, just by running through up-to-date WebKit's layout tests), but had no idea the issue was still this exposed.

Since the exploit PoC was already public, I wrapped it into a module with a few sample attacks (UXSS exploitation is incredibly flexible) and we shipped it. After the dust settled, Google responded and backported the patch to the Android 4.3 branch, although downstream adoption from the vendors still lags the upstream 4.3 branch considerably.

Of course, noticing a 3-year-old, previously disclosed vulnerability in Android 4.3's WebKit implementation was just the tip of the iceberg. Rafay continued to test WebKit bugs and successfully found five different UXSS vulnerabilities still present in 4.3! And those are just the ones that were found. A complete privacy breakdown. This kind of thing makes me sad, because not so long ago I was stuck on Android 4.3…

In November Quarkslab disclosed an issue affecting Samsung devices with the Knox security component. An arbitrary web page could force the user to install an arbtirary APK as an “update” to Knox. To exploit this, I worked with vulnerability discoverer Andre Molou to write a browser exploit that launched the update process, waited for the apk to be installed, then used an intent URL to launch the apk. The result was a one-click RCE exploit, where the user is essentially bullied into clicking “Install” (see the video).

If you need another reason not to use the 4.3 browser, Rafay discovered that it was possible to open a file URL from an HTTP page by getting the user to choose “Open in new tab”. By combining this with another vulnerability to open the sqlite cookie database as an HTML document in the browser, the entire cookie database (including HTTPOnly cookies) can be stolen, which means an attacker can steal all of your sessions at once. Rafay has a good writeup of this vulnerability on his blog. Luckily Android had already patched this issue in February 2014, but adoption from the downstream vendors that still ship 4.3 devices is slow to none.

Last but not least, afore-mentioned contributor timwr has done some excellent work porting CVE–2014–3153, a privilege escalation bug in the Linux kernel reported by researcher geohot into a local exploit. This would allow Meterpreter sessions on 4.4 to be upgraded to root (“system” uid 0), although the Android permission context is lost. This module is still awaiting review, so keep an eye out for it in upcoming releases.

The Way Forward

To escape the WebKit nightmare, users are strongly advised update to 4.4 (Kitkat) or higher as soon as possible. If that's not possible for you, it's time to get a new device. Seriously. Even if you were to replace the AOSP browser with the Chrome app (recommended), many, many apps will likely still be vulnerable to attacks on any WebView components embedded in those apps (including addJavascriptInterface RCE for apps compiled before API level 17). On 4.4 , the WebKit implementation of WebView is replaced with (the much more up-to-date) Chromium, and all these problems disappear.

Even better, as of 5.0 (Lollipop), the Chromium system library is updated separately from the OS, allowing regular Play store updates to provide out-of-band patches for the native browser and WebView components. Such a bright future. In 2015, we expect to continue and extend our coverage of mobile and embedded devices, so keep an eye on that Pull Request queue for the up and coming exploits that are no doubt waiting to be discovered!