Hi folks! Sorry about the delay on this week's blog post. I've been responding to a few concerns about this week's Android revelations about the no-patch policy from Google with regard to nearly a billion in-use Android handsets, and incidentally, caught a face cold that's been floating around Rapid7's delightful open-space office model. I'm back online and fully functional, now, so I'll try to summarize here what I saw and responded to this week.
Pre-Jelly Bean Android WebView Patches
by http://en.wikipedia.org/wiki/User:Dsimic used under CC-BY")If you somehow missed it, I published a blog post earlier this week about how Google now is telling vulnerability researchers (at least, a couple that I know) that they will no longer be providing patches for pre-Jelly Bean Android. This ended up getting some pickup from such esteemed media outlets as the Wall Street Journal, Forbes, and Taylor Swift, which generated a few thousand comments spread all over the Internet. I'll take a stab at summarizing the critical reaction here, and I promise I'm being sincere when characterizing these sentiments fairly. If I screw it up, please tell me.
OEMs don't patch anyway, so who cares?
It's true that the security patching for Android is, at best, quite broken. I wrote a post back in November about this issue, and this rejoinder is totally valid.
My problem, though, is that we're talking about two different things. One, Google is (now) not interested in working up patches for Android for issues before KitKit (4.4), and two, downstream vendors are very slow on picking up patches from Google (if ever). They're related, to be sure. However, I don't think you can solve the latter problem without solving the former, and there are two problems here for sure.
With the second problem, you can easily argue that downstream OEMs, carriers, and retailers are dropping the ball by not applying patches for old, publicly reported vulnerabilities. However, if you consider that Google isn't producing patches any more for shipping and for-sale devices, I feel like there's no longer even a ball to drop for those OEMs. Moreso, I feel like this change in attitude from Google makes it very easy for vendors to shrug and disclaim any responsibility for old vulns on their devices. You can argue this legally, ethically, technically or otherwise and there's room for disagreement, but Google walking away from patches, in my mind makes this state of affairs much worse.
Now, with all that said: Today, we can test this! We have two Metasploit modules shipping today that breaks the security model for pre-4.4 WebView: one is fixed upstream, and one remains unfixed. I'm /very/ interested in figuring out which, if either, of these vulnerabilities sees a downstream patch on pre-4.4 handsets. It's a pretty ideal test case, since they were discovered and reported so close to each other.
If you keep tabs on downstream devices and patch adoption versus patch creation, I would love to hear from you. Let's work together to see what the practical effects of this policy shift is.
Jelly Bean is legacy, so who cares?
While it's true that Jelly Bean is two named revisions back, and KitKat adoption is ticking up nicely, it's not like everyone gets to automatically upgrade for free. There are hardware costs, time and convenience costs, the carriers often limit choices or penalize customers for upgrading, people don't know how to upgrade, etc. There's a whole host of reasons, some good, some not, to stick to Jelly Bean.
Let's remember that Ice Cream, Gingerbread, and Froyo together account for nearly 15% of tracked Android devices, and these guys are three, four, and five versions back! Heck, if I had an exploit that worked reliably on these phones, and I was the sort to go popping randoms who visit my evil website and snagging personal usernames and passwords, I'd be pretty thrilled to know that 15% of my target base is guaranteed vulnerable. After all, Windows XP accounts for about 18% of the total desktop market share today, and I know for a fact that there's an active criminal and government (and criminal government) marketplace for security bypasses on XP. 15% is good enough for plenty of shady applications.
Now, consider that when you add in Jelly Bean, you're talking about nearly half (46%) of all Android phones just by itself. Add to that the way-downrev versions, you come to way over half of all Android phones. So, where 15% is good for bad guys, 60% is way more than four times better. The value for bad guys is exponentially related to the install base.
Consider, too, that WinXP went end-of-life for security patches 12 years after initial release. Google's apparent attitude shift about patching WebView became apparent only 2 years (technically, 28 months) after Jelly Bean's release.
WebView isn't part of the Android OS anymore, so who cares?
Yes, Google took a great leap forward by decoupling WebView from Android as of the Lollipop (5.0) release. I'm thrilled for this, and in five years, I expect the majority of in-use phones will be Lollipop or later.
In five years, we'll also be shaking our heads in bewilderment over all those people stuck on KitKat at below, thanks to the above-mentioned broken patch distribution model for handsets. Or not? I hope not. That's just too depressing to consider. Let's move on.
It's just WebView, not Jelly Bean, so who cares?
If I'm an attacker, and I had to choose one component of Android to focus my exploit efforts on, it'd be WebView, hands down. WebView is the one component that's used in virtually every ad-enabling library to remind me that I still don't care about Clash of Clans, and is used when you don't click "open link in browser" in every web-rendering app.
The fact that Google will patch AudioPlayer, but not WebView, in a pre-4.3 context is frankly baffling. Why they would choose to abandon the best exploit vector an attacker has makes absolutely no sense to me.
I use Chrome, not AOSP Browser, so who cares?
Chrome (and other browsers, like Firefox and Dolphin), do not use the WebView component, so switching to these browsers for your day-to-day is a great mitigation step. If you're using the bundled AOSP browser on Jelly Bean or prior, stop it. If you're using your carrier's skinned browser, it's almost certainly using WebView as well, so stop that, too.
That said, though, the underlying WebView component is still exposed via apps and ad networks. TrendMicro took a look at a bunch of aftermarket browsing, messaging, and other apps, and found that a bunch are still vulnerable.
And that's it..?
I really do hope that I've captured the criticism here accurately, in an (unironic) fair and balanced way. If I've misstated your favorite argument, or if you have another that I haven't captured here, please comment below, or pick a fight with me on twitter.
While I'll happily talk all day about Android security, this wrapup is intended to cover the changes in Metasploit over the last three weeks and change, and we celebrated HaXmas in there, it's a little outsized. We have 11 new exploits, and 8 new auxiliary modules this week, for a total of 19 new usable modules to kick off 2015. Among those are, suprise, a new Cookie Theft module from Joe Vennix and Rafay Baloch that affects, double surprise, Android Jelly Bean. Will it be patched, ever?
- Desktop Linux Password Stealer and Privilege Escalation by Jakob Lell
- Malicious Git and Mercurial HTTP Server For CVE-2014-9390 by Jon Hart exploits CVE-2014-9390
- Pandora v3.1 Auth Bypass and Arbitrary File Upload Vulnerability by egyp7, Elizabeth Loyola, Fr330wn4g3, Juan Galiana Lara, Raymond Nunez, _flood, and mubix exploits CVE-2010-4279
- ProjectSend Arbitrary File Upload by Brendan Coles and Fady Mohammed Osman
- WordPress WP Symposium 14.11 Shell Upload by Claudio Viviani and Rob Carr exploits OSVDB-116046
- GetGo Download Manager HTTP Response Buffer Overflow by Gabor Seljan and Julien Ahrens exploits CVE-2014-2206
- BulletProof FTP Client BPS Buffer Overflow by Gabor Seljan exploits CVE-2014-2973
- i-FTP Schedule Buffer Overflow by Gabor Seljan and metacom exploits OSVDB-114279
- Lexmark MarkVision Enterpreise Arbitrary File Upload by juan vazquez and Andrea Micalizzi exploits CVE-2014-8741
- Microsoft Windows NtApphelpCacheControl Improper Authorization Check by sinn3r and James Forshaw exploits CVE-2015-0002
- Oracle MySQL for Microsoft Windows FILE Privilege Abuse by sinn3r and Sean Verity exploits CVE-2012-5613
Auxiliary and post modules
- ManageEngine Desktop Central Administrator Account Creation by Pedro Ribeiro exploits CVE-2014-7862
- MS14-068 Microsfot Kerberos Checksum Validation Vulnerability by juan vazquez, Sylvain Monne, and Tom Maddock exploits CVE-2014-6324
- Android Browser "Open in New Tab" Cookie Theft by joev and Rafay Baloch
- Konica Minolta Password Extractor by Deral "Percentx" Heiland and Pete "Bokojan" Arzamendi
- Apple Airport ACPP Authentication Scanner by Jon Hart exploits CVE-2003-0270
- Viproy CUCDM IP Phone XML Services - Call Forwarding Tool by fozavci exploits CVE-2014-3300
- Viproy CUCDM IP Phone XML Services - Speed Dial Attack Tool by fozavci exploits CVE-2014-3300
- Windows Outbound-Filtering Rules by Borja Merino