very hard to notice Phishing Scam - Firefox / Tor Browser URL not showing real Domain Name - Homograph attack (Punycode)

Patrick · October 30, 2019, 12:20pm

Awful. 3 years unfixed Mozilla @firefox #security issue. And @mozilla refuses to fix it. Tor Browser also affected. @torproject

https://www.аррӏе.com/ shows up as apple.com. Even including green SSL lock. But it is a demonstration, proof of concept of a phishing side by a security researcher.

https://www.xn--80ak6aa92e.com/ shows up as https://www.apple.com.

Note: there is nothing apple specific about this issue. Apple was just used as an example by the security researcher. Responsible for this issue is Firefox.

I can’t even find Mozilla’s rationale for being adamant about this. 3 years ago they wrote:

We now have an FAQ which makes our position clear:
https://wiki.mozilla.org/IDN_Display_Algorithm_FAQ

Nowadays this wiki page is empty (links to another empty wiki page).

Any reason why it is not enabled by default in Firefox? Any reason against enabling it?

Workaround: got to about:config in Firefox URL bar, search for network.IDN_show_punycode and double click to change its setting from false to true.

References:

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

Tor Browser bug report: https://trac.torproject.org/projects/tor/ticket/27887

Screenshot:
https://www.xudongz.com/static/942a1d48cb68b8678e2713249d1ae7ceaf9fa4c39767562a8caf6cc856626160.png

Thanks to @madaidan for pointing out this issue on telegram. Quote @madaidan:

https://trac.torproject.org/projects/tor/ticket/21961

Weird this hasn’t been enabled yet.

SokPuppette · October 30, 2019, 9:42pm

Yes, you absolutely should set network.IDN_show_punycode by default if Firefox and Tor browser won’t. You should also understand that that amounts to disabling internationalized domain names. Everything will show up as ASCII, and anything that is not ASCII will show up as ASCII-encoded garbage.

The real problem here is with the basic design of Unicode itself. There’s absolutely no way for a computer to determine whether two strings will look different to a user. In fact, you have to be very careful if you even want to do computer comparisons of Unicode strings. It’s possible to encode the same actual string of characters to two different binary representations even in the SAME UNICODE ENCODING, and if you don’t want that to happen you have to follow a bunch of super complicated, bug-prone canonicalization rules.

I argued against creating the whole IDN mechanism to begin with, for exactly this reason. I lost the argument. I kind of expected to lose.

In the end, the IETF made a bunch of rules for what specific characters were allowed in IDNs. Those rules don’t work. The various registrars apply different sets of of other rules, all of which share the attribute that they do not work. Various browsers try to address it with whitelisting or apply various heuristics… which don’t work. All of the “defenses” fall trivially to anybody who puts a little effort into picking the domains to attack.

I think Firefox’s basic point is that since they can’t possibly make it work, they’re not going to try. The only way to actually secure it would be to disable IDNs completely, which they are unwilling to do. It’s what I would do. It’s definitely what you should do. It’s what the Tor project should do, too. But Firefox is unwilling to tell most of the people in the world that they can’t use their native language character sets… which is understandable if unfortunate.

By the way, why do I have to give an email address to post on the forum of a Tor-based anonymity distro?

Patrick · October 31, 2019, 6:06am

Got any examples of internationalized domain names that would be affected?

I don’t speak any languages that don’t use the Latin alphabet. This is true of millions of other people. So for those kind of users, I guess network.IDN_show_punycode set to true won’t cause any inconvenience? I guess it wouldn’t be hard for Firefox to ask the user at first start of to guess that information somehow?

As for internationalized domain names… User who speak languages that don’t use Latin alphabet, couldn’t there be a different solution? How many domain names exist that mix Latin letters with non Latin letters? I guess for other domain names that use alphabet XYZ, just allow alphabet XYZ. I didn’t look into it but perhaps there aren’t many cases of mixing Latin letters with non-Latin letters?

In short: we are users of popular webapps. We don’t have resources to fix issues in these.
Longer answer: see this this: https://www.whonix.org/wiki/Privacy_Policy_Technical_Details#website
and related discussion: Wiki search fallback suggestion

SokPuppette · October 31, 2019, 1:07pm

Got any examples of internationalized domain names that would be affected?

Affected in what way? Any non-roman letter or any letter with any kind of diacritic will end up looking like garbage. If you mean names that are in actual use, idnworldreport dot eu says there are 7 and a half million registered IDNs. Which is fewer than I’d have thought, but still a lot.

So for those kind of users, I guess network.IDN_show_punycode set to true won’t cause any inconvenience?

It depends on what you mean by “don’t use the Latin alphabet”. European languages that use the Latin alphabet with diacritics are technically affected. uber isn’t the same thing as über. But it seems as though a lot of speakers of those languages don’t care enough to matter. idnworldreport.eu slash maps slash eu-idns.

There seem to be a fair number of Asian IDNs. China was even setting up TLDs.

I didn’t look into it but perhaps there aren’t many cases of mixing Latin letters with non-Latin letters?

Apparently there are a few… but it really doesn’t matter, because you can get a homograph attack even between two non-Latin languages. Or even within one language. Here’s an example from Masayuki Nakano in the Firefox bug report:

FYI: Similar issue was concerned even only with Japanese characters at supporting IDN. E.g., 口 (Kanji character, meaning mouth) vs. ロ (Japanese Kanatana-Ro). If there are ハ口ープロジェクト dot com and ハロープロジェクト dot com, it’s difficult to distinguish them with most Japanese font.

Patrick · November 1, 2019, 1:24pm

Patrick · November 8, 2019, 3:13pm

How did Chrome and other browsers manage to fix this issue?