Image: Lucian Constantin/IDGNS
The latest version of Google Chrome, released earlier this week, restricts how domain names that use non-Latin characters are displayed in the browser. This change is in response to a recently disclosed technique that could allow attackers to create highly credible phishing websites.
The ability to register domain names made up of characters like those found in the Arabic, Chinese, Cyrillic, Hebrew and other non-Latin alphabets dates back over a decade. Since 2009, the Internet Corporation for Assigned Names and Numbers (ICANN) has also approved a large number of internationalized top-level domains (TLDs) — domain extensions — written with such characters.
When used in the Domain Name System (DNS) — the internet’s address book — internationalized domain names are converted into ASCII-compatible form using a system called Punycode. However, when displayed to users inside browsers and other applications that support Unicode, they are shown with their intended non-Latin characters, making it possible for billions of internet users to read domain names in their native languages and scripts.
While this is great for global internet usability, the use of internationalized domain names does raise security problems because some alphabets contain characters that look very similar to Latin letters and this can be abused to spoof URLs. For example, the letters “a” in the Cyrillic and Latin scripts are visually identical, even though they’re different characters with different Unicode values: U+0430 and U+0061.
This similarity would allow people to create the domain name apple.com using the letter “a” from the Cyrillic alphabet and the rest from the Latin alphabet. Such a domain name could be used to set up a phishing website that would be very hard to distinguish from the real one if the browser would visually show apple.com for both in the address bar.
To prevent these so-called homograph attacks, browsers perform a series of complex checks to decide if it’s best to display domain names using their intended scripts or to display their equivalents in Punycode instead. One of the rules they enforce is that if Latin, Cyrillic or Greek characters are mixed together, then Punycode will always be used.
The Punycode version of the apple.com domain mentioned above, where the letter “a” is from Cyrillic, would be: xn--pple-43d.com. That’s what users would see in the browser address bar.
However, taking things further, a Web application developer named Xudong Zheng realized that for some domain names or brands it is possible to replace all of the letters with visually similar ones from a different script. For example, there are lookalike chracters in Cyrillic for all the letters in the word apple. In this case, the browser filter above would no longer apply because there is no mixed script in the name.
To prove this, Xudong recently registered the xn--80ak6aa92e.com domain and set up a website whose address looked virtually identical to apple.com when opened inside Chrome, Firefox or Opera on Windows and Linux. On macOS the “l” character looked a bit differently, but was still close enough.
Xudong reported this issue to browser vendors and Google fixed it Wednesday in Chrome 58 by adding yet another check to its internationalized domain name (IDN) policy. The browser will now display domain names in Punycode if all of their characters are Latin lookalike Cyrillic letters and if the top-level domain name is not an internationalized one. This means that the check only applies to traditional Latin-based generic and country-code TLDs like .com, .net, .org, .uk, .de and so on.
For example, xn--80ak6aa92e.xn--p1ai would still look in the browser address bar like apple followed by the internationalized country code TLD for Russia, which is written in Cyrillic.
The check does not match the script of the domain name with that of the TLD, which means that xn--80ak6aa92e.xn--fiqs8s also works, but with the internationalized country code TLD for China; so does xn--80ak6aa92e.xn--qxam for Greece, xn--80ak6aa92e.xn--3e0b707e for Korea and so on. These domains might not be suitable to launch phishing attacks against users in countries that use Latin-based alphabets, but might look legitimate to users that use different scripts.
The Google Chrome IDN display policy is already made up of 10 different checks with different conditions, highlighting how hard it is to cover all possible abuses of such domain names.
Mozilla is still considering whether it should take any action to block Xudong’s technique and hasn’t reached a final conclusion. A discussion on its bug tracker shows that there are strong opposing views about who should be responsible for preventing such attacks.
Some believe that whole-script homograph attacks, as in the case of apple.com written with Cyrillic characters, is not something the browsers should fix. They feel that the responsibility should fall with brand owners who should register those domains to protect their brands and with domain registrars who should have blacklists in place to prevent users from registering potentially abusive domains.
Gervase Markham, a policy engineer at Mozilla, published an unofficial FAQ document that explains how Firefox decides whether to display IDNs in their proper form and what implications a more restrictive policy would have.
Firefox users who do not care about seeing IDNs in their intended scripts can manually force the browser to always display them in Punycode. This can be done by typing about:config in the browser address bar, locating the network.IDN_show_punycode setting and changing its value from false to true.
Homograph attacks using IDNs are probably here to stay, as there will always be some edge cases not covered by existing policies. The debate is whether the risk is worth sacrificing usability for a large number of users, given that phishers already have a lot of success with simpler techniques that don’t rely on perfectly spoofed URLs.
