1790163 - Adopt chromium idn_spoof_checker rules to prevent Address Bar Spoofing via IDN U+30FC and others

Status: RESOLVED FIXED

(Core :: Networking, defect, P2)

Description

[Matthew Telfer]

Attachment: idn.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0

Steps to reproduce:

I have identified a method of bypassing PunyCode protections in order to perform Address Bar Spoofing. Normally, Firefox will protect against IDN Homograph Attacks by causing the URL to be displayed as PunyCode, rather than displaying the Unicode characters which can be used for address bar spoofing.
An example of this can be seen here: http://〱google.com
If you paste the above URL into your address bar, rather than that URL being displayed, it will instead display its PunyCode equivalent, so within your address bar you will see "xn-google-203e.com" rather than "http://〱google.com" - this is expected behaviour and is a protection mechanism to prevent address bar spoofing, however, usage of certain Unicode chars will prevent the PunyCode addresses from being displayed, and will instead display the IDN Homograph domain in the address bar. Take the following URL: http://ーgoogle.com/ - the expected behaviour would be for the PunyCode equivalent to be displayed, resulting in "xn--google-o64e.com" in the address bar, but instead, this particular Unicode character is causing the URL to be loaded without the PunyCode protection mechanism being applied, so rather than "xn-google-o64e.com" it displays "-google.com" within the address bar, allowing an attacker to perform a highly-convincing spear-phishing attack via the spoofed address bar.

Take a look at the following screenshot:
You can see in the error message that it can't find the server at "xn-google-o64e.com" which is the value you would expect to see in the address bar, but if you look at the address bar itself, it is displaying "-google.com" instead, as you can see in the attached image. An attacker could register xn-google-o64e.com and then send one of these payloads. The victim would click it thinking they are going to Google. Generally at this point, Firefox's PunyCode protections would kick into place, causing an untrusted URL to be displayed in the address bar -- but when we are starting our payloads with these specific Unicode chars, it will display "-google.com" instead as seen in the image. An attacker could host their malicious cotent on "xn-google-o64e.com" and when a victim loads and views that content, they will assume it is really from Google, due to the PunyCode protections not being applied.
As well as the URL I already provided, there are a few other Unicode chars which can be used which will also prevent IDN Homograph Attack protections from being applied in the form of Unicode. The following URL's will achieve the same end result:
http://ゝgoogle.com
http://ｰgoogle.com
If you have any questions, please don't hesitate to ask.
Kind regards,
Matthew Telfer.

Actual results:

Rather than the PunyCode value "xn--google-o64e.com" being displayed in the address bar, the PunyCode protections do not get applied, and we instead see "-google.com" in the address bar, allowing an attacker to carry out highly-convincing spear-phishing attacks through bypassing the PunyCode protection mechanism.

Expected results:

The PunyCode value "xn--google-o64e.com" should have been displayed in the address bar. See the attached image for an example of "-google.com" being displayed rather than the PunyCode URL.

Comment 1

[Matthew Telfer]

I forgot to include the screenshot, but it is now attached. Using these particular Unicode chars in URL's will prevent the PunyCode protections against IDN Homograph Attacks from being applied. When navigating to "http://ｰgoogle.com" we would expect it to display the PunyCode value "xn--google-o64e.com" in address bar as a form of protection against IDN Homograph Attacks, however it is instead displaying "-google.com" in our address bar, allowing an attacker to create a convincing spear phishing page for google.com.

I hope I have explained this properly. If there is any confusion, please reach out!

Comment 2

[Daniel Veditz [:dveditz]]

This somewhat misunderstands the way IDN works since these cases that look equivalent to English-reading eyes are treated 3 or 4 different ways (depending on how you count it).

• http://〱google.com — U+3031 is not allowed in IDN2008. It will always trigger punycode
• http://ｰgoogle.com — U+FF70 is a halfwidth variation character mapped to U+30FC (see below)
• http://ーgoogle.com/ — U+30FC is a valid katakana alphabetic. Even by the "strict" script-mixing standard followed by Firefox it is allowed in IDN2008. Chrome converts it to punycode in this case though. We'll come back to this.
• http://ゝgoogle.com - U+309D is a valid katakana alphabetic that, like the previous, is allowed in IDN2008. Unlike U+30FC, Chrome does show this one as IDN like Firefox, not punycode.

ASCII angle brackets are not allowed in domain names. Therefore the first and last example can't spoof real domains, and as a result they don't have any special rules applied. The first is denied and the second allowed simply based on how the Unicode standard classifies the kind of character it is. Much like https://§google.com gets turned into punycode not because it's spoofy but because it's punctuation.

So what's going on with U+30FC in chromium? You can't simply blacklist the character and show punycode because it's perfectly valid in Japanese words. I discovered chromium has some extra anti-spoofing rules they apply that aren't part of the IDN standards. In this case if that character appears surrounded by Japanese text then it's allowed, and if it's next to latin text that triggers the punycode treatment. It's not perfect, but it's a clever compromise.

We should do something like this.

it is instead displaying "-google.com" in our address bar, allowing an attacker to create a convincing spear phishing page for google.com.

Technically It shows "ーgoogle.com" which looks like an em-dash, not a hyphen! Even so, if users can't tell the difference between hyphen-google and plain google they are already in trouble from pure-ASCII spoofing like mozllla.org or paypa1.com—or even literally "-google.com"!

The spoofing danger is not to Google, but to domains that are already expected to have a hyphen in the middle.
For example, https://us.coca-cola.com/ vs https://us.cocaーcola.com/

The interesting chromium code is this whole file:
https://source.chromium.org/chromium/chromium/src/+/main:components/url_formatter/spoof_checks/idn_spoof_checker.cc;l=488

The above file is also where they deal with "dotless-i + combining mark" spoofing (bug 1473911), or at least the ones on less popular domains that wouldn't be protected by bug 1507582.

Comment 3

[:Gijs (he/him)]

I'm fairly sure that the implementation for these bits lives in network code, so moving accordingly.

Comment 4

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1790163 - Modernize illegalScriptCombo with enum r=#necko

Comment 5

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1790163 - Import chrome spoofing test cases r=dveditz

Depends on D161779

Comment 6

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1790163 - Disable tests that don't pass r=dveditz

Depends on D161780

Comment 7

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1790163 - Fix IDN spoofing 30FC r=dveditz

Depends on D161781

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/51d20d84a0ea
Modernize illegalScriptCombo with enum r=necko-reviewers,kershaw
https://hg.mozilla.org/integration/autoland/rev/b2ae8efefc8c
Import chrome spoofing test cases r=necko-reviewers,jesup
https://hg.mozilla.org/integration/autoland/rev/ac5db69fee7a
Disable tests that don't pass r=necko-reviewers,jesup
https://hg.mozilla.org/integration/autoland/rev/e33697d1250c
Fix IDN spoofing 30FC r=necko-reviewers,jesup

Comment 9

[Atila Butkovits]

Backed out for causing build bustage at nsIDNService.cpp.

Backout link: https://hg.mozilla.org/integration/autoland/rev/a29b80b107103df84e493008e420e30aea857da1

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=dcPegBNBQveWusHeLOowMA.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=7b91b96b9f37a41c89209a9ed220d2f66a2d82f7

Failure log: https://treeherder.mozilla.org/logviewer?job_id=397207476&repo=autoland&lineNumber=35335

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4d4def145a9e
Modernize illegalScriptCombo with enum r=necko-reviewers,kershaw
https://hg.mozilla.org/integration/autoland/rev/c041e5010f7f
Import chrome spoofing test cases r=necko-reviewers,jesup
https://hg.mozilla.org/integration/autoland/rev/821368e9165f
Disable tests that don't pass r=necko-reviewers,jesup
https://hg.mozilla.org/integration/autoland/rev/2796eb177a1a
Fix IDN spoofing 30FC r=necko-reviewers,jesup

Comment 11

[Norisz Fay [:noriszfay]]

Backed out for causing xpcshell failures on test_idn_spoof.js

Backout link

Push with failures

Failure log

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a5f111e5288e
Modernize illegalScriptCombo with enum r=necko-reviewers,kershaw
https://hg.mozilla.org/integration/autoland/rev/f8812208f269
Import chrome spoofing test cases r=necko-reviewers,jesup
https://hg.mozilla.org/integration/autoland/rev/f376ce0b6c8c
Disable tests that don't pass r=necko-reviewers,jesup
https://hg.mozilla.org/integration/autoland/rev/e09b29de7cff
Fix IDN spoofing 30FC r=necko-reviewers,jesup

Comment 13

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/a5f111e5288e
https://hg.mozilla.org/mozilla-central/rev/f8812208f269
https://hg.mozilla.org/mozilla-central/rev/f376ce0b6c8c
https://hg.mozilla.org/mozilla-central/rev/e09b29de7cff

Comment 14

[Ryan VanderMeulen [:RyanVM]]

This was reverted from Beta109 due to the ICU72 update it depends on being backed out for causing bug 1806042. For now, it remains in place for 110+, but that may need to be revisited in the future.
https://hg.mozilla.org/releases/mozilla-beta/rev/7deaef0e20e3