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

Patrick · October 13, 2021, 9:52pm

Documented here:
https://www.whonix.org/wiki/Social_Engineering#IDN_Homograph_Attacks

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:
IDN Display Algorithm FAQ - MozillaWiki

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:

Phishing with Unicode Domains - Xudong Zheng

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.

https://www.facebook.com/Whonix/posts/3165210863521147

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?

torjunkie · August 21, 2021, 6:31pm

Turns out it is still a threat - fixed in documentation i.e. another reminder that JavaScript is a PoS.

Talking about unfixed threats, the homograph/punycode issue is still a problem.
http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/very-hard-to-notice-phishing-scam-firefox-tor-browser-url-not-showing-real-domain-name-homograph-attack-punycode/8373

Still unfixed in Tor Browser/Firefox if you look at about:config.

If there is no fingerprinting risk, why not implement an option for toggling network.IDN_show_punycode to true on first use of Tor Browser? It would also be noted that non-Latin language users e.g. Chinese, Japanese etc. should not make any change due to garbarge appearance. (That’s millions of websites BTW).

Also, that investors page reminds me that any budding investor will want to see semi-regular census results - probably 6 monthly updates would be sensible to show Whonix is on the up and up. I expect by now that you have more than 10K estimated daily users, which is a steep growth trajectory in recent times.

If I had free $ or wanted to advertise on the Whonix website, that would probably convince me.

Patrick · August 21, 2021, 6:31pm

I don’t know if there is a fingerprinting risk.
It is up to The Tor Project:

Something similar, a first run popup existed for a while for the for the security slider:
add Tor Browser first startup popup to ask whether security slider should be set to safest
It was removed since it broke after a while.
This also makes all Tor Browser issues suddenly specific to Whonix, which is unmanageable.
For a stable implementation for that, someone would need to contribute and implement this:
[Feature Request] Environment Variable to set security slider level (#25391) · Issues · The Tor Project / Applications / Tor Browser · GitLab
Similar for punycode. Would be good if there was an environment variable in Tor Browser to enable/disable this. Otherwise no stable implementation is possible.

Patrick · August 21, 2021, 6:32pm

Could you document punycode in wiki the please?

torjunkie · August 22, 2021, 9:25am

No problem.

Patrick · August 28, 2021, 10:46am

User documentation:

IDN Homograph Attacks

Yay! Thank you!

Patrick · August 28, 2021, 11:04am

Made some minor changes.

Found the migrated The Tor Project issue ticket:

Which then lead to another interesting find:

Quote [archive] Tor developer [21] Matthew Finkel @sysrqb [archive]:

And Mozilla’s FAQ is/was Gerv's IDN Display Algorithm FAQ - MozillaWiki [archive]