1367120 - [IDN Phishing] Use the "xn--chu" character to hide the real URL

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[Artur]

Attachment: xnchu_char.png

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170517122419

Steps to reproduce:

Analysis has shown that there is a possibility to use the "xn--chu" character to hide the real domain address. The "xn--chu" character allows to use spaces in the address.

Example (url bar):
google.com        .com

Simple Code:
<a href="http://google.xn--com-chuaaa.com">link</a>

Attackers can register a new domain or create subdomains on their own hosting.




Actual results:

PoC:
<a href="http://google.xn--com-chuaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.com">link</a>


Expected results:

Recommendation:
The browser should truncate all "spacing" characters in the domain name.

Comment 1

[:Gijs (he/him)]

I can also reproduce on OS X (reporter seems to be on Windows).

My IDN-fu is terrible, but it seems like the spaces in the string in question are for https://codepoints.net/U+18AA?lang=en - is that right? Jonathan, is this just fonts being terrible, or should this be treated as a space by something that isn't? Also, the internet seems to suggest this is a Mongolian script character, and so why isn't this tripping mixed script detection?

Comment 2

[Jonathan Kew [:jfkthame]]

I see a string of Mongolian letters (also on OS X, but I probably have extra fonts installed). So yes, if you're seeing blank spaces (not tofu boxes, not hexboxes, not actual Mongolian characters) then you must be getting a bogus font that claims to support the codepoint but maps it to a blank glyph.

FWIW, Mongolian is classified as an "aspirational" script in UAX#31,[1] which is how it comes to be allowed in the Moderately Restrictive profile as described in UTS#39.[2] However, a forthcoming update to UAX#31[3] is expected to get rid of the Aspirational category, merging it with Limited, and that will exclude these characters. There's a patch pending review in bug 1364283 that will make this change, so although this isn't really a Firefox bug -- it's a font problem, apparently somewhat widespread -- it's likely to get fixed soon anyhow. :)

[1] http://www.unicode.org/reports/tr31/#Aspirational_Use_Scripts
[2] http://www.unicode.org/reports/tr39/#Restriction_Level_Detection
[3] http://www.unicode.org/reports/tr31/tr31-26.html#Aspirational_Use_Scripts

Comment 3

[Artur]

Hi,

I found another character:

"xn--0bf"

Best Regards,
Artur

Comment 4

[Artur]

...and another one: "xn-fgb" :-)

Comment 5

[Jonathan Kew [:jfkthame]]

(In reply to Artur from comment #3)
> Hi,
> 
> I found another character:
> 
> "xn--0bf"

That's another Mongolian character; if it's showing up as a blank for you, that's a fault in the font. But bug 1364283 will make it display as punycode, anyhow.

(In reply to Artur from comment #4)
> ...and another one: "xn-fgb" :-)

And that's an extended Arabic-script character. Again, if it's blank, that's a font bug. (For me, on both OS X and Windows 10, it displays the expected "ؠ" glyph.)

Comment 6

[Artur]

Thanks for information :-)

Yes, on my Mac (Sierra) it is displayed as blank space.

Regards,
Artur

Comment 7

[Daniel Veditz [:dveditz]]

bug 1364283 is now landed in Nightly fixing the first two cases. For the third I get the same results as Jonathan.

Comment 8

[Artur]

Thanks for information ;-)

Best Regards,
Artur

Comment 9

[:Gijs (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #7)
> bug 1364283 is now landed in Nightly fixing the first two cases. For the
> third I get the same results as Jonathan.

FWIW, I also see a space (OS X Sierra, fully updated) at the bottom of Jonathan's comment here:

I wonder if we should check the font(In reply to Jonathan Kew (:jfkthame) from comment #5)
> (In reply to Artur from comment #4)
> > ...and another one: "xn-fgb" :-)
> 
> And that's an extended Arabic-script character. Again, if it's blank, that's
> a font bug. (For me, on both OS X and Windows 10, it displays the expected
> "ؠ" glyph.)

Jonathan, I'm still confused why this doesn't trigger mixed-script stuff (and also, I can't get this to show up in the URL bar with just 'xn-fgb') -- is it worth checking if we need to do more font blacklisting and/or look into this further?

Comment 10

[Jonathan Kew [:jfkthame]]

(In reply to :Gijs from comment #9)
> Jonathan, I'm still confused why this doesn't trigger mixed-script stuff
> (and also, I can't get this to show up in the URL bar with just 'xn-fgb') --
> is it worth checking if we need to do more font blacklisting and/or look
> into this further?

That should be "xn--fgb", clearly a typo.

The "Moderately Restrictive" level (see UTS#39) allows "Latin with other Recommended or Aspirational scripts except Cyrillic and Greek", so these are not prohibited mixtures. If you change network.IDN.restriction_profile to "high", such combinations will not be allowed and will trigger punycode display instead.

I suppose if we identified which fonts have the incorrect blank glyphs for these characters, we could consider blacklisting them (along the lines of bug 1360309), but given that we've just landed the patch to exclude the Aspirational script category anyway, I don't think it's worth doing more at this point.

Comment 11

[Artur]

I'm sorry! Yes, it's "xn--fgb" :-)

Thanks for help :-)

Comment 12

[Artur]

It's similar to bug 1360309 :-)

Best Regards,
Artur