Closed Bug 1507678 Opened 3 years ago Closed 3 years ago
IDN Phishing using whole-script confusables (suggested solution with DNS lookup)
+++ 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.
Please do not file duplicate bug reports on purpose.
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1332714
(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.
(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).
You need to log in before you can comment on or make changes to this bug.