In this article, I will show you how you could have previously performed “spoofing” of the address bar in Chrome and Firefox browsers. In other words, make the domain displayed in the browser’s address bar not the one where the user actually is. As a consequence, the attack can be used for phishing, for example, to steal user data. The CVE numbers CVE-2017-5089 and CVE-2017-7763 were assigned to this vulnerability.
Some time ago, a lot of confusion on the internet was caused by post made by Xudeng Zheng, in which it was shown how it was possible to register a domain that looked exactly the same as “apple.com” but consisting only of Cyrillic characters. Mozilla announced then, that the issue would not be repaired, and the protection against such a problem was the responsibility of entities registering domains.
The whole thing was an inspiration for me to answer the question: are there any other characters in Unicode, whose display in the browser’s address bar may allow you to engage spoofing of the domain name?
Search for Interesting Characters
The easiest way to discover any “interesting” characters seemed to be to write a simple script that:
- Iterates on all Unicode characters from 0x0000 to 0xFFFF.
- I will try to create a link to http://testX.bntk.pl – where the current character is inserted in place of X.
- It will check if the browser creating such a link does not include the prefix “xn--” at its beginning. If the prefix is not added, it means that the character is not displayed literally, but in the punycode form. For example, an attempt to create a link to the http://test©.bntk.pl domain will make the browser display it as http://xn--test-8fa.bntk.pl/. In such links, therefore, there is no potential for spoofing.
- For all links that have not generated punycode, it prints them on the resulting HTML page.
The code for this script was:
|
1 2 3 4 5 6 7 8 9 10 |
<script> const a = document.createElement('a'); for (let i=0; i<0xffff; ++i) { const url = `http://test${String.fromCodePoint(i)}.bntk.pl`; a.href = url; if (!a.href.startsWith('http://xn--')) { document.write(`${i.toString(16)} <a href="${url}">${url}</a><br>`); } } </script> |
In the last step, I just had to run the script in my browser and go through the results in search of something interesting. Honestly, I did not really know what I was looking for; I was hoping that something interesting would catch my eye.
Unexpected … space
And it really happened. From between several consecutive characters of the Tibetan alphabet, the most interesting of which was U+08FC TIBETAN SIGN INVERTED MCHU CAN, it turned out that they are rendered as spaces (Figure 1)!
The next step was adding so many spaces to the domain name that the parent domain (i.e. bntk.pl) was no longer visible in the address bar. What’s more, by using Let’s Encrypt I can even issue a trusted SSL certificate for this domain!
Moving from thoughts to deeds, I registered the appropriate domain, issued an SSL certificate and could pretend to be in possession of the Very Important Google Domain (Fig. 2 and 3).
In both cases, at first glance, it seems that we are within the “secure” domain important-domain.google.com (the green padlock seems to confirm this), but in fact on both screenshots the browser displays the domain: https://important-domain.google.xn--com-lumaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.bntk.pl/. Of course, having access to such a domain name, we could try to use phishing attacks to convince users to provide their login details to a Google account.
Reporting Errors
At this stage, the only thing left to do is reporting bugs to the creators of the relevant browsers. After the report, it turned out that the reason for the issue was not on the part of the browsers, but in the font used on MacOS to render characters of the Tibetan alphabet. In its metadata, this font had information that could render the U+0F8C sign, but in reality, it did not have any glyph for it. Effectively, this rendered the character as empty space. Both Mozilla and Google – independently from each other – have reported the problem to Apple. But for the time being, it has not been repaired.
Regardless of the reaction (or lack thereof) of the Cupertino based company, the browsers included corrections to this error simply by adding the U+0F8C character (as well as several others) to the “black list” of characters on the MacOS that cannot be rendered in the address bar.
Updated versions of both browsers were released in the first half of June, so if after clicking the link above you still see a lot of spaces in the browser bar, it is a sign that you are due for an update.
In Figures 4 and 5 I show how browsers display this earlier address after patching.
Summary
In the article, I showed how the U+0F8C character on MacOS could be abused to perform a domain spoofing attack, thus convincing the user that they are on a different domain than they really are. As a result of such an attack, you could successfully try to capture login data.
The bug was fixed in Chrome 59.0.3071.104 and in Firefox 54.0.