1592055 - The browser IDN blacklist policy is lacking, making users susceptible to homograph attacks.

Status: RESOLVED DUPLICATE of bug 1507582

(Firefox :: Address Bar, defect, P3)

Description

[Tzachy Horesh]

While going through various Unicode characters and checking how to bypass the IDN display algorithm of various browsers, I've found that Firefox's IDN display algorithm is lacking and displays Unicode domains that can be used to phish users.
I know that according to https://wiki.mozilla.org/IDN_Display_Algorithm Firefox decided to use the "Moderately Restrictive" profile according to the Unicode Technical Report 39 and also that it is a decision not to "treat non-Latin scripts as second-class citizens".
However, I'd like to point out the solution that Edge uses (and explorer before it) in which they rely on the languages installed on the user's machine and display punycode for any domain that contains letters outside these languages.
Another solution was made by Chrome to have the "Highly Restrictive" profile according to the Unicode Technical Report 39 and to add a list of 5K top sites that will be tested against the domain typed/clicked by the user.
This balances between the need to treat everybody the same and block phishing attacks directed at Firefox's users.
I also know that you can disable the Unicode display completely from the about:config menu, but I don't think most of the users are technical enough to do that on their own while being aware to these attacks at all.
Anyway, the partial list is as below, it contains top domains that are more prone to be faked. (all are in Chrome 5K domains)
þookmyshow.com þ U+00FE Latin Small Letter Thorn
dropÞox.com Þ U+00DE Latin Capital Letter Thorn
ßooking.com ß U+00DF Latin Small Letter Sharp S
æoncinema.com æ U+00E6 Latin Small Letter Ae
rottentomatœs.com œ U+0153 Latin Small Ligature Oe
gðogle.com ð U+00F0 Latin Small Letter Eth
businessinsidər.com ə U+0259 Latin Small Letter Schwa
ебау.com б U+0431 Cyrillic Small Letter Be
Ыпԍ.com Ы U+042B Cyrillic Capital Letter Yeru
ьъс.co.uk ъ U+044A Cyrillic Small Letter Hard Sign
beしcy.jp し U+3057 Hiragana Letter Si
βββ.org β U+03B2 Greek Small Letter Beta
αμ.com μ U+03BC Greek Small Letter Mu
υη.org η U+03B7 Greek Small Letter Eta
αττ.com τ U+03C4 Greek Small Letter Tau
ωωε.com ε U+03B5 Greek Small Letter Epsilon
gṃail.com ṃ U+1E43 Latin Small Letter M with Dot Below
www.googlẹ.cn ẹ U+1EB9 Latin Small Letter E with Dot Below
googlẹ.com.tw ẹ U+1EB9 Latin Small Letter E with Dot Below
googlẹ.in ẹ U+1EB9 Latin Small Letter E with Dot Below
οκ.ru ο U+03BF Greek Small Letter Omicron
ωρ.com ω U+03C9 Greek Small Letter Omega
ωρ.com ρ U+03C1 Greek Small Letter Rho

Regards,

Tzachy Horesh

Comment 1

[:Gijs (he/him)]

I think this is a straight dupe of bug 1507582. :stpeter, can you doublecheck if I'm missing something?

(In reply to Tzachy Horesh from comment #0)

However, I'd like to point out the solution that Edge uses (and explorer before it) in which they rely on the languages installed on the user's machine and display punycode for any domain that contains letters outside these languages.

This means for all of the latin equivalents of the domains you cite in comment #0, people who use the scripts that are used to "confuse" are still vulnerable.

Comment 2

[Tzachy Horesh]

(In reply to :Gijs (he/him) from comment #1)

I think this is a straight dupe of bug 1507582. :stpeter, can you doublecheck if I'm missing something?

(In reply to Tzachy Horesh from comment #0)

However, I'd like to point out the solution that Edge uses (and explorer before it) in which they rely on the languages installed on the user's machine and display punycode for any domain that contains letters outside these languages.

This means for all of the latin equivalents of the domains you cite in comment #0, people who use the scripts that are used to "confuse" are still vulnerable.

I'd like to point out that it's not a duplicate as most of these characters are bypassing any browser policy right now. I've pointed out to other vendors and they are working on a fix.

Also, for the Edge example, this reduces the attack vector dramatically as most users will not have more than 1 to 2 languages installed and thus will be less likely to be phished. Combined with the "Highly restrictive" profile Unicode Technical Report 39 (and maybe a few adjustments) you can protect the users much better and still don't treat the vast majority of Unicode domains fairly as they are likely to direct themselves to a specific language group of users.

Comment 3

[:Gijs (he/him)]

(In reply to Tzachy Horesh from comment #2)

I'd like to point out that it's not a duplicate as most of these characters are bypassing any browser policy right now.

This is confusing - comment #0 suggests these URLs are blocked by Chrome. Is that not the case? Can you link us to the chrome issue please? (yes, it will probably be restricted, that's OK - the URL will help us if we need to get in touch and coordinate what fixes get used.)

Combined with the "Highly restrictive" profile Unicode Technical Report 39 (and maybe a few adjustments)

We already switched to "highly restrictive", this was https://bugzilla.mozilla.org/show_bug.cgi?id=1399939 . What "adjustments" did you have in mind?

Also, for the Edge example, this reduces the attack vector dramatically as most users will not have more than 1 to 2 languages installed and thus will be less likely to be phished. [...] you can protect the users much better and still don't treat the vast majority of Unicode domains fairly as they are likely to direct themselves to a specific language group of users.

I'm not sure what you're saying - is your suggestion that if an attacker uses, say, cyrillic, to resemble Latin, we should just accept that they will be able to target users who have cyrillic-script-based languages installed?

Comment 4

[Tzachy Horesh]

(In reply to :Gijs (he/him) from comment #3)

(In reply to Tzachy Horesh from comment #2)

I'd like to point out that it's not a duplicate as most of these characters are bypassing any browser policy right now.

This is confusing - comment #0 suggests these URLs are blocked by Chrome. Is that not the case? Can you link us to the chrome issue please? (yes, it will probably be restricted, that's OK - the URL will help us if we need to get in touch and coordinate what fixes get used.)

Sorry for not being clear earlier, only some of these URLs are being blocked by chrome.
https://bugs.chromium.org/p/chromium/issues/detail?id=1017707

Combined with the "Highly restrictive" profile Unicode Technical Report 39 (and maybe a few adjustments)

We already switched to "highly restrictive", this was https://bugzilla.mozilla.org/show_bug.cgi?id=1399939 . What "adjustments" did you have in mind?

Good to know that you switched to "highly restrictive", it's just that https://wiki.mozilla.org/IDN_Display_Algorithm has not been updated.
The "adjustments" that I was referring to are "patches" that close some holes (like making look alike characters that still got in even after applying all of the steps of your policy appear as punycode)

Also, for the Edge example, this reduces the attack vector dramatically as most users will not have more than 1 to 2 languages installed and thus will be less likely to be phished. [...] you can protect the users much better and still don't treat the vast majority of Unicode domains fairly as they are likely to direct themselves to a specific language group of users.

I'm not sure what you're saying - is your suggestion that if an attacker uses, say, cyrillic, to resemble Latin, we should just accept that they will be able to target users who have cyrillic-script-based languages installed?

Sorry again for not making myself clear: What I meant is that if you combine both Edge's and Chrome's policies, (or your's) it'll make phishing much harder. I agree that just taking edge's policy will make current users who are less likely to get phished, get phished.
(I suggested to take this action as blacklisting will never end and this way we can minimize the group of users that might be a victim of this attack)

Comment 5

[Daniel Veditz [:dveditz]]

We're extremely unlikely to take the Edge approach on philosophical grounds (surprised it's not mentioned on that IDN wiki page; we've certainly discussed it). Not entirely convinced this isn't just a dupe of the approaches we might implement such as the bug Gijs mentioned.