Introduction
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 characterLogical 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
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.
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 inProof 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.
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.
The total bounty rewarded for all bugs combined was 5000$.
This post first appeared on Learn How To Hack - Ethical Hacking And Security, please read the originial post: here