1507678 - IDN Phishing using whole-script confusables (suggested solution with DNS lookup)

Status: RESOLVED DUPLICATE of bug 1332714

(Firefox :: Address Bar, defect, P3)

Description

[antoine.coeur]

+++ This bug was initially created as a clone of Bug #1332714 +++

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161209094039

Steps to reproduce:

See https://www.xn--80ak6aa92e.com/ - if you compare with https://www.apple.com/, URL looks identical on Windows and Linux. On OS X, the font is slightly different, and it is potentially possible to distinguish between the two.

The domain xn--80ak6aa92e.com is currently proxying requests to apple.com to demonstrate how difficult it is to distinguish the malicious domain.

This security issue only exists in Firefox (not in Chrome, Safari, etc.).


+++ Suggested solution (Here, because I'm not allowed to comment on the original report from two years ago) +++

1. Collect all the Cyrillic letters in a label and then see if they are all in the set of 22 confusables.
2. If they all are and the TLD is ascii then do a DNS lookup on the ascii homograph domain.
3. If the ascii homograph domain has a different owner/IP than the Cyrillic one, then display the label as punycode.

Comment 1

[Matthias Versen [:Matti]]

Please do not file duplicate bug reports on purpose.

Comment 2

[antoine.coeur]

(In reply to Matthias Versen [:Matti] from comment #1)

@Matthias Versen [:Matti]

So, you mean you will deliberately prevent any solution from being suggested to solve a security issue?
But we don't want Firefox designed to be the least secure browser in the world.

You could have just copy-pasted the last three lines as a comment in the original thread.

Comment 3

[:Gijs (he/him)]

(In reply to antoine.coeur from comment #0)

People can see the duplicate annotation if CC'd to the original bug.

> +++ Suggested solution (Here, because I'm not allowed to comment on the
> original report from two years ago) +++
> 
> 1. Collect all the Cyrillic letters in a label and then see if they are all
> in the set of 22 confusables.
> 2. If they all are and the TLD is ascii then do a DNS lookup on the ascii
> homograph domain.
> 3. If the ascii homograph domain has a different owner/IP than the Cyrillic
> one, then display the label as punycode.

There are a number of reasons this doesn't work:

- it assumes the ascii domain is "more important" than the cyrillic domain. Why isn't the ascii domain penalized for homograph-attacking the cyrillic domain?
- it requires additional DNS lookups, which are async (and may fail, especially if the browser is now offline and we're showing a page from session restore or similar) - what do you present to the user while waiting for the result, or if the result is missing?
- it will produce different results for different people depending on their DNS setup, which is problematic especially in the case of active attackers. If I was actually intending to abuse the fake apple.com, I'd use it for spearphishing on public wifi I controlled, and just returned my fake domain/IP for requests to the 'real' apple.com, and then this suggested solution wouldn't help at all, even though under the hood the browser *knows* that these two domains are not the same.
Even without an active attacker specifically aiming to exploit a particular homograph, this would produce broken results in situations with captive portals which hijack DNS to point to the same place anyway (ie legitimate cyrillic or other non-latin domains would be punycode'd, and that'd confuse users).