Google Chrome, Firefox Address Bar Spoofing Vulnerability

Introduction

Google security team themselves state that "We recognize that the address bar is the only reliable security indicator in modern browsers" and if the only reliable security indicator could be controlled by an attacker it could carry adverse affects, For instance potentially tricking users into supplying sensitive information to a malicious website due to the fact that it could easily lead the users to believe that they are visiting is legitimate website as the address bar points to the correct website.
In my paper "Bypassing Browser Security Policies For Fun And Profit" I have uncovered various Address Bar Spoofing techniques as well as bugs affecting modern browsers.  In this blog post I would discuss about yet another "Address Bar Spoofing" vulnerability affecting Google Chrome's Omnibox. Omnibox is a customized address bar api developed for better user experience such as search suggestions, URL prediction, instant search features so on and so forth.

Technical Details

Characters from languages are such as Arabic, Hebrew are displayed from RTL (Right To Left) order, due to mishandling of several unicode characters such as U+FE70, U+0622, U+0623 etc and how they are rendered combined with (first strong character) such as an IP address or alphabet could lead to a spoofed URL. It was noticed that by placing neutral characters such as "/", "ا" in filepath causes the URL to be flipped and displayed from Right To Left. However, in order for the URL to be spoofed the URL must begin with an IP address followed by neutral characters as omnibox considers IP address to be combination of punctuation and numbers and since LTR (Left To Right) direction is not properly enforced, this causes the entire URL to be treated and rendered from RTL (Right To Left). However, it doesn't have be an IP address, what matters is that  first strong character (generally, alphabetic character) in the URL must be an RTL character

Logical Order

The following is the logical order of characters in the memory.  Since, Omnibox removes"http://" and displays strings without "http://" prefix.

127.0.0.1/ا/http://example.com

Display Order

The following is the display order of characters after the browser removes the leading "http://", decodes the percent-escaped bytes, and applies the bidirectional algorithm.

http://example.com/‭ا/127.0.0.1

Steps To Reproduce

1) Visit the following link for the vulnerable browser - http://182.176.65.7/%EF%B9%B0/http://google.com/test

2) You would notice that the URL has been flipped from Right to left and the browser displays http://google.com/test/182.176.65.7 while it displays the content from the IP address.

The IP address part can be easily hided specially on mobile browsers by selecting a long URL (google.com/fakepath/fakepath/fakepath/... /127.0.0.1) in order to make the attack look more realistic. In order to make the attack more realistic unicode version of padlock can be used in order to demonstrate the presence of SSL.

Firefox Mobile Address Bar Spoofing CVE-2016-5267

Firefox was also prone to a similar vulnerability, however this did not require IP address to trigger, all it required was is arabic RTL characters, which in this case i provided arabic TLD (عربي.امارات) in order to trigger the vulnerability which resulted in

Proof of concept 

http://عربي.امارات/google.com/test/test/test

As you can see from the above screenshot that the page is hosted on عربي.امارات , however the address bar points to google.com.

Important Note

Variation of similar vulnerability has also been discovered in several other browsers that are still undergoing a fix there i am refraining from disclosing them. Details will be disclosed, once a fix has been landed. 

Fix

RFC 3987 § 4.1 states that "Bidirectional IRIs MUST be rendered in the same way as they would be if they were in a left-to-right embedding.", therefore setting paragraph direction to LTR fixes this issue. This is a known issue and has already been discussed in great detail here.

Credits

I am highly indebted to "Matt Giuca" from the Google Chrome team for his extensive help on this issue and "Tod Beardsley" for handling the disclosure.

Bug Bounty 

The total bounty rewarded for all bugs combined was 5000$.