Phishing with Unicode Domains

[Usr6]

If I told you this could be a phishing site, would you believed me? tl;dr: check out the proof-of-concept

Punycode makes it possible to register domains with foreign characters. It works by converting individual domain label to an alternative format using only ASCII characters. For example, the domain "xn--s7y.co" is equivalent to "短.co".

From a security perspective, Unicode domains can be problematic because many Unicode characters are difficult to distinguish from common ASCII characters. It is possible to register domains such as "xn--pple-43d.com", which is equivalent to "аpple.com". It may not be obvious at first glance, but "аpple.com" uses the Cyrillic "а" (U+0430) rather than the ASCII "a" (U+0041). This is known as a homograph attack.

Fortunately modern browsers have mechanisms in place to limit IDN homograph attacks. The page IDN in Google Chrome highlights the conditions under which an IDN is displayed in its native Unicode form. In Chrome and Firefox, the Unicode form will be hidden if a domain label contains characters from multiple different languages. The "аpple.com" domain as described above will appear in its Punycode form as "xn--pple-43d.com" to limit confusion with the real "apple.com".

Chrome's (and Firefox's) homograph protection mechanism unfortunately fails if every characters is replaced with a similar character from a single foreign language. The domain "аррӏе.com", registered as "xn--80ak6aa92e.com", bypasses the filter by only using Cyrillic characters. You can check this out yourself in the proof-of-concept using Chrome or Firefox. In many instances, the font in Chrome and Firefox makes the two domains visually indistinguishable. It becomes impossible to identify the site as fraudulent without carefully inspecting the site's URL or SSL certificate. This program nicely demonstrates the difference between the two sets of characters. Internet Explorer and Safari are fortunately not vulnerable.

Screenshots: Chrome, Firefox, Firefox SSL

This bug was reported to Chrome and Firefox on January 20, 2017 and was fixed in the trunk of Chrome 59 (currently in Canary) on March 24, 2017. The problem remains unaddressed in Firefox as they remain undecided whether it is within their scope. The Bugzilla issue was initially marked "RESOLVED" and "WONTFIX", though it has since been reopened, made public, and given the "sec-low" keyword.

Our IDN threat model specifically excludes whole-script homographs, because they can't be detected programmatically and our "TLD whitelist" approach didn't scale in the face of a large number of new TLDs. If you are buying a domain in a registry which does not have proper anti-spoofing protections (like .com), it is sadly the responsibility of domain owners to check for whole-script homographs and register them.

A simple way to limit the damage from bugs such as this is to always use a password manager. In general, users must be very careful and pay attention to the URL when entering personal information. I hope Firefox will consider implementing a fix to this problem since this can cause serious confusion even for those who are extremely mindful of phishing.

You can follow me on Twitter @Xudong_Zheng

 

Sursa: https://www.xudongz.com/blog/2017/idn-phishing/