On June 30, 2015 security researcher David Leo publicly disclosed a vulnerability in Google Chrome on the full disclosure mailing list. Via this vulnerability it is possible to spoof the location of the address bar in the latest version of Chrome.
The team behind Chrome has been notified by the researcher of this issue via responsible disclosure. Google thought it wasn’t a serious issue and thus they haven’t patched it (yet?). Google classified the bug as a denial of service vulnerability. As a result, the security researcher decided to fully disclose all the details of the vulnerability, including a working exploit, in order to gain attention to the problem.
This week this vulnerability was broadly discussed within the security scene and there were a lot of different opinions and no clear threat analysis was made. I hope to add something to that discussion with my analysis.
Functional analysis of exploit & vulnerability
I have customized and modified the exploit that was publicly released in order to target the attack on an important web site. I took PayPal as an example.
The following is the exact exploit code that I used. Source code for: index.html
Source code for: content.html
I optimized the exploit with onload functionality, fixed a few JavaScript errors and added shortcut icons for the targeted web site to make the impersonation attack more realistic.
The file paypal.png that I refer to in the exploit contains a screenshot of the official PayPal login screen, in order to demonstrate how a phishing site could look like that misuses the vulnerability.
When running the exploit the following screen is generated:
When clicked on the ‘Log in on www.paypal.com’ link, a new browser window opens:
The PayPal web site is protected by an extended X.509 certificate and as you can see in the red rectangle in the screenshot above, the web site looks really valid and trustworthy. However, a malicious log in screen is shown.
When clicked on the green lock in order to examine the certificate, it is legitimate:
And even when the HTML source code is inspected (via the shortcut CTRL+U in Chrome), the real source code of the URL in the address bar is shown:
After some time (on my laptop in around six minutes), the specific Chrome tab that the exploit is loaded in crashes:
Opera is vulnerable also
After testing the exploit also in the latest version of Firefox, Internet Explorer and Opera, it seems that Opera is also affected by this bug. That is new information that was not disclosed by the original researcher. Below evidence that supports this finding:
And also Opera crashes after some time, in my case around eight minutes:
The vulnerability is not specific to a single browser vendor. Some people report that Firefox is affected also (at least in version 40.0a2). I couldn’t reproduce that observation.
Technical analysis of exploit & vulnerability
The vulnerability reveals when a web pages (the parent) opens a new window (the child) via window.open(). The HTML code of the child is rendered and displayed by the browser. The child then makes directly an automated HTTP redirect to the web site that will be impersonated. Almost immediately after the child starts the redirection process, the parent from then on continuously redirects the child to the impersonated web site via a recursive call with setTimeout(). The browser has no time to fully execute the redirect and render the HTML code of the page that is redirected to, and thus the already rendered HTML code of the web page that performs the redirection is still shown.
Window opening restriction
The exploit works by opening a new browser window. Chrome and Opera have out of the box pop-up blocking configuration active in a way that blocks pop-ups that are immediately loaded when opening a web page. For example, loading the exploit when the web page is opened via <body onload=”init()”> will result in the pop-up being blocked:
The current exploit is based on getting the user to click on a link:
When the link is clicked, a pop-up will initially load the real URL in the address bar, showing the location of the exploit code (of content.html). Then almost instantly the URL is changed to the impersonated web site. It is really hard to notice the swift change in the address bar.
Timing complexity
When the exploit code is run on the same computer as affected browsers are installed on, it has a 100% success rate. That percentage is lower when the code is run on a web server on the internet.
Because the exploit makes use of timing techniques via JavaScript function setTimeout() in order to fool affected browsers, remotely loading the exploit (on a server on the internet) has a lower success rate compared to locally running the exploit. Clearly it works best with a fast network connection.
User input not accepted
The given exploit has been tweaked to see how it functions under different timing conditions. The original code has the following configuration:
The infinite loop of the next() function causes user input not to be accepted. When the loop is terminated, the browser will load and show the HTML code and thus the interface of the URL in the address bar, effectively eliminating the URL spoofing.
Various configurations are tried (loading content in an <iframe> or Flash object) to get input to be accepted by the browser but all have failed. Additional research should be performed to make sure that this restriction on entering user input could not be bypassed. This restriction makes the displayed page read only; user input is not accepted and thus a form cannot be filled by a victim of the exploit, a clear condition for a phishing web site.
Browser tab crash
The two setTimeout() values result in high CPU usage as shown in the following performance measurement:
The very fast infinite loop of the next() function also causes the browser to use more and more memory. The following screenshot shows that the memory consumption raises quickly already within minutes since opening the exploited web page:
After six minutes the Chrome browser tab crashed and in some cases multiple unrelated browser tabs crashed and even Windows error messages where observed. Opera seems to be more tolerable about memory consumption by web pages and crashes a few minutes later than Chrome does.
In one instance the graphic display of one of my Windows 7 test laptops was completely messed up and Windows had to be rebooted to get rid of that error. This error didn’t occur on my Windows 8.1 laptop.
Windows resizing
When the browser window is resized during exploitation, it will display a white screen in its resized window.
Impact of vulnerability
The current exploit might not be optimized, but effectively demonstrates the vulnerability. It is trivial to modify the exploit so that it can be made effective against other web sites. It is possible that the currently exploit could be made much more effective. Further research is necessary to confirm that hypothesis.
Same-origin security policy is not broken
The same-origin security policy the most important security feature in all browsers today is not affected by the bug. That’s good news!
Only site authenticity is effected
This bug only affects the authenticity of a web site, and luckily not the integrity and confidentiality.
More authenticity when combining with an open redirection vulnerability
An attacker has to make a victim visit his web page that contains the exploit code. The chance that the victim would click on that link can be increased when the web site that will be impersonated also contains an open redirect vulnerability. Open redirects are a very common vulnerability in web sites. The exploited link in PayPal’s case could be something like:
https://www.paypal.com/scripts/redirect?url=http://evil.example.com/urlspoofer.html
User input is disabled
When performing the exploitation, all user input is disabled. During the impersonation of the attacked site the user interface is completely read only.
Reputation damage via authentic looking messages
An authentic looking message could be displayed on the domain name of an arbitrary web site. Reputation damage will occur when this message tries to discredit the web site owner.
Phishing sites are possible
When looking further into the effect on the authenticity of web sites, a very real attack scenario is that phishing sites are going to make use of the address bar vulnerability to impersonate web sites in order to gain tremendous credibility.
User input is disabled when running the exploit, so a phishing web site is only able to display an authentic looking message. The last few years there is a trend going with phishing web sites that a phone number is listed that the victim has to call urgently. The phisher has a staffed call center ready to answer any incoming calls. Phishers invest a lot in their criminal organisation, because the pay off is lucrative.
Solution for user input restriction
I’ve come up with a solution to get user input and thus a traditional phishing web site working, by termination the URL spoofing after a few seconds and then redirecting back to our own malicious HTML code.
I’ve added the code in the red rectangle to the exploit in order to get a phishing site working:
The code of content2.html is the same as content.html, but without the redirection JavaScript code:
After two seconds the impersonification process is stopped, enough time for an user to validate the URL bar and identity of the web site and start filling in forms. When the process is stopped the fake log in screen is show at its real location and all user input is accepted again:
History of this vulnerability
When performing this analysis, information popped up that this vulnerability was also discovered and reported in 2012 by another security researcher going under the pseudonym ‘patcheudor’:
That researcher also couldn€™t fix his exploit in order to make user input possible in the spoofed web page. His claim about finding the exact same vulnerability in 2012 seems legit after looking at the screenshot he attached as proof:
Based on this information it seems that the browser bug won’t be fixed soon in the near future.
Recommendations
The development of the security bug and exploit code should be monitored to see if the threat landscape changes.
At this moment there are no solutions known that could protect a web site from being fallen victim of the browser bug. Setting specific HTTP headers won’t help.
There is also no solution available for Chrome and Opera users, apart from using another browser until the vendor releases a patch for the problem.
Browser vendors should fix this bug by immediately resetting the document object model when a location.href redirection is started, for example by displaying a white page, or showing a progress bar. This should really be a simple fix for them to implement.
There is a detection opportunity for owners of high profile web sites such as banks that frequently have to deal with phishing sites. When manually validating phishing web sites it is possible to detect phishing sites that make use of the browser exploit. Every potential phishing web site should be visited with both Chrome and Internet Explorer (also the two most popular browsers at the moment). When a difference if observed in the address bar of the two browsers when opening a potential phishing web site, and Chrome shows a web page on the real domain name, than the original URL should be flagged as a phishing site.
Conclusion
At this moment there is not much that can be done to mitigate the authenticity risk from a browser user or web site owner perspective. Browser vendors should step in and fix the vulnerability.
Currently it is not possible to create a fully working phishing web site via address bar spoofing, because user input is frozen when the vulnerability is being exploited. It is however possible to create a credible message that looks to be coming from the impersonated web site.
A phishing web site could temporary make use of address bar spoofing in order to gain trust from the victim. After a few seconds it could redirect back to the original phishing website address in order to be able to receive user input again.
News sites referencing this research
