“Google has patched a bug in the Chrome browser on Android, which allowed an attacker to spoof a user into thinking they’re accessing one website when they’re actually visiting another,” Zack Whittaker reports for ZDNet.
“Rapid7, which detailed the flaw, said users should contact carriers or handset makers to ensure they received the patch,” Whittaker reports. “But bad news for Apple, which now has to scramble to fix a similar flaw found in its Safari browser.”
MacDailyNews Take: One big difference: When Apple corrects the issue, iOS users will actually get the update en masse. “Contact carriers or handset makers?” Puleeze. What a bad joke Android is.
“A proof-of-concept exploit was published Sunday that allows an attacker spoof the address bar in Safari on iPhones, iPads, and Macs,” Whittaker reports. “The exploit is far from perfect, as the browser can visibly be seen fighting the code to try to display the correct address.”
Full article here.
The proof-of-concept is extremely simple… it uses JavaScript to load up a website (dailymail), every 10 micro-seconds, which is not enough time for the website to begin loading. So it’s displaying that website address, but hasn’t actually loaded it yet. Meanwhile, it’s on a different website, which could have active malware.
Does that make it a DDOS?
You would be denied access to the website that was being spoofed, yes, so long as JavaScript was enabled in your browser.
I was meaning more along the lines of a British newspaper site being used for the demo being hit with all of the traffic from people trying the proof of concept website.
Technically, no. This is not a
Distributed
Denial
Of
Service attack. It’s occurring due to web code as opposed to being an attack on an IP address from the Internet at large, either a single or distributed source.
From what I’ve heard (from Steve Gibson’s ‘Security Now’ podcast last week) and read about this problem, it’s a method that could be used for fooling people being phished or being subjected to something to the effect of ‘click-jacking’.
From the Rapid 7 source article with me substituting Safari for Android/Chrome:
In the event that patches are unavailable for [Safari], users are advised to avoid using the [Safari] browser to perform authentication, especially when following links from untrusted or unverifiable sources until patches are available.
An earlier, slower form of this site address injection problem is well known in the browser community. Apple has previously addressed it in 2012 for Safari. What’s different here is that the address injection speed is now severely faster, overwhelming the web browser, in this case Safari & Chrome (vicariously Opera and all Chromium flavors).
The current version of Firefox is not affected. Mozilla has security articles detailing the situation and their patches from both 2009 and 2013. Apparently, their older patch is still good for this hyper-ized version of the spoof.
Are iCab and OmniWeb (it still limps along) affected? Don’t know!
Apologies: Please ignore ‘(vicariously Opera and all Chromium flavors)’ which is WRONG. Instead read:
“…in this case Safari & Chrome in Android’.
I’m up late again, awake on low caffeine titer. 🙁
What about issuing a pop-up window with navigation bar disabled, and then display a fake HTML version of the address bar along the top of the window. So it would look like an address bar but actually would just be part of the page content, and could display whatever.
Yup, but that’s not really exploiting a browser bug.
I think MDN is mistaking the default Android browser with Google Chrome for Android. The former is usually part of the firmware package and the latter is a download that is easily updated via the Google Play store.
It would be ZDNet to whom you should refer.
From the source Rapid 7 article:
…an attacker can cause the stock Chrome browser on Android to render HTML pages in a misleading context. This effect was confirmed on an Android device running Lollipop (5.0)
This is referring to the Chrome browser that is included AS PART OF Android. Nothing in any of the documentation I can find about the bug refers to a downloadable version of Chrome for Android that would solve the problem.
Thanks for the clarification. I was just commenting on the MDN take for this article. Pointing out that there is a difference between the 2 browsers and that MDN was probably thinking of the default browser when making their comment since Chrome is just as quickly updated en masse.
I see the confusion. Obviously, I fell for it myself, as I pointed out.
If you’d like to play along with the Proof-Of-Concept of this bug in Safari, here is the link:
http://www.deusen.co.uk/items/iwhere.9500182225526788/
When you hit the ‘Go’ link, you’ll see a mess going on in the address bar. Notice on the far left the hyperactive blue flashing as the browser repeatedly attempts to load the page. On the right of the spoofed web address you’ll see:
“?random=0.blahblahblah”
The ‘blahblahblah’ is a rapidly changing number.
In the POC demo, you’re eventually sent to the actual site being spoofed, just to show you the difference.
I’m a hog. Sorry. But I just did some testing for the Mac security gestalt to which I belong and I wanted to pass the results along to everyone here as well.
What I did: I went to the access page for the proof-of-concept exploit of this JavaScript susceptibility bug and pulled a .webloc file to my desktop. I then dropped it into each web browser to load the access page (or I could have simply done a copy-paste) and hit the ‘Go’ link. I noted the results.
TEST RESULTS:
Safari: Yes, susceptible. I had already described what occurs in Safari further up this thread.
iCab: No problem. The address bar reads correctly. However, if you set iCab to play a sound when a page has finished loading, you can hear the exploit running over and over again in the background.
OmniWeb: Yes, sort of. It goes into total chaos, flashing both the fake and the actual URL over and over in both the address bar AND the title bar.
Opera: No. But, it freaks out Opera enough that it locks up. You can’t close pages. You can’t quit the application. Force Quit is the only option. IOW: It kills Opera dead.
Chromium: No. But again it freaks out the application into lock up, requiring a Force Quit. (I’m using the latest Chromium beta for Mac, version 45.0.2406.0).
Firefox: As reported, it does not have the problem. But you will notice that the proof-of-concept page never finishes loading. The rotating loading icon goes on forever. I would imagine the Tor browser will show identical results because its core is Firefox.
I didn’t test Chrome as I don’t use it. But I’d imagine it would also lock up.
Feel free to share my results, but of course perform your own verification.