Android UXSS + XFO bypass no longer operational

[todb-r7]

I know you've noticed this already, @joevennix -- I'm not sure how to go about fixing and you type fluent Javascript about 1024 times faster than me.

I've tested android_stock_browser_uxss, and that still works like a champ on my Samsung Galaxy SIII mini, and the XFO bypass is still functional, as seen here:

require 'net/http'  
require 'uri'  
uri = URI.parse("https://play.google.com/#{"a" * 10000}")  
@r = Net::HTTP.get_response uri  
ret = @r.each_header {|x| puts x}  
if ret["x-frame-options"]  
  puts ret["x-frame-options"]  
else  
  puts "Missing x-frame-options!"  
end  

So, how about it? :) We see daily press mentions of this exploit, so it'd be super nice to be able to demo again.

[todb-r7]

@joevennix said this: https://twitter.com/joevennix/status/567450622471839744

So, obviously :)

[joevennix]

Called out! @todb-r7 I did look into this a bit, a few days ago. Play store 403's any request that matches stock Browser's User Agent (I suspect they mucked this up at first and that's why they accidentally blocked Firefox, which is funny). For a demo you might try the exploit in a WebView-wrapping browser that overrides User-Agent to something else.

Another neat thing to demo (although this would not involve a UXSS) would be a module that runs android_browser_new_tab_cookie_theft, then proxies some HTTP requests to play.google.com through msf, which replaces the Cookie: header with the ones you've stolen and replaces User-Agent with Chrome's.

[todb-r7]

@joevennix okay thanks -- Usually Maxthon and CM browser are good for that kind of thing. I'll give it a shot today.

[todb-r7]

Mainly, I'm concerned that Google Play store's protection is inadequate and that bad guys will figure out a way around it. That would leave people in a situation where they can't safely test with Metasploit, giving them the impression that all is clear, even though the UXSS and XFO bypass are still present and potentially exploitable.

[joevennix]

4846 will allow theft of secure/HttpOnly cookies, which is enough to steal the victim's session and install through the Play Store remotely. That would be a good demo.

I don't think I will find a way around the User Agent check, so I'm going to close this out. Fixed! (kinda)

[todb-r7]

Just a quick update -- I've tested through the User-Agent protections that Play store is using, and it appears effective on the usual suspects: AOSP, reskinned AOSP, Maxthon, and CM.

However, while looking for a list of "most popular mobile browsers," I came across this one:

https://play.google.com/store/apps/details?id=com.decad3nce.hoverbrowser&hl=en

It's only got 5k-10k downloads, but it's mentioned on:

http://www.tomsguide.com/us/pictures-story/408-5-best-mobile-browser.html

It's a weird browser, but it's WebKit, and it seems to be lying about its User-Agent. It's claiming:

Mozilla/5.0 (Linux; Android 4.4; Nexus 5 Build/KRT16M) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36

So, this module is still effective, though in a very limited way. It can be triggered when a custom browser, built with older WebKit, rewrites its User-Agent for whatever reason (malicious, compatability reasons, or otherwise).

IOW, I envision an attack scenario where a malware author reskins the stock browser, puts it on the play store, and uses it to later inject UXSS and slide in Play store apps. Thus, the Metasploit module is still effective at demonstrating this risk, though it's vastly decreased.

[todb-r7]

And now I have a 4.3 device with OEM skinned AOSP, Chrome, Firefox, Maxthon, CM, Dolphin, Opera, Opera Mini, and Hover Browser. :)

/cc @joevennix

[joevennix]

Haha, wow, hooray for options. You know, I bet the attack would still work if the user has the "Request Desktop site" option checked.