platform; including automated penetration tests and risk assesments culminating in a "cyber risk score" out of 1,000, just like a credit score.
First slide label
Some representative placeholder content for the first slide.
Second slide label
Some representative placeholder content for the second slide.
Third slide label
Some representative placeholder content for the third slide.
Google Chrome, Firefox Address Bar Spoofing Vulnerability
published on 2016-08-16 06:16:00 UTC by Rafay Content:
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.
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
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$.