Punycode phishing attack detection

[fproulx-pbox]

Describe the issue

Punycode based phishing attacks may become a threat to consider

There are Chrome extensions that detects those - it'd be nice to have it part of UBlock

like
https://chrome.google.com/webstore/detail/punycode-domain-detection/fkenopinnpinfcjneoanjoimhkmdcjne
or
https://chrome.google.com/webstore/detail/idn-safe/kegeenojcnijgmfgkcokknkbpmjcabdm

[fproulx-pbox]

@anewuser ok - but if we have feature request - there's just no way to communicate those?

[bershan2]

@fproulx-pbox uBlock is a network blocker (filter), not URL checker. While it can protect you from known (black listed) malware domains, it is not really tasked with verifying URLs.

Also, consider this:

1. You can, and should just install an extension for that -- which is the easiest fix.
2. Punycode phishing is not really an issue (or will be resolved soon) for all up-to-date browsers. Update and you won't need the extension either.

Apple Safari, Microsoft Edge, and Internet Explorer protect against this attack. A Chrome fix arrives in Version 59 this week, but Firefox developer Mozilla continues weighing whether to release a patch.
Source: https://www.wired.com/2017/04/sneaky-exploit-allows-phishing-attacks-sites-look-secure/

3. Adding any code to the main codebase increases number of potential bugs and complicates the code. As you can see, even the default filters were moved to a separate repo https://github.com/uBlockOrigin/uAssets
4. You could try to make a rule for this (and add it to custom rules list or propose it to malware domain list), but a comprehensive regular expression might be very complicated. (Assuming that regular expression exists.)

[bershan2]

@fproulx-pbox Considering what I wrote above, the solution here is simple and does not require any changes in uBlock:

0. If you use outdated browsers... update or use extensions forever.
1. If you use up-to-date Apple Safari, Microsoft Edge, and Internet Explorer, you are all set.
2. If you you use Google Chrome (which probably you do, since you gave links to Chrome store), use extension for now and wait till 59 is released.
3. If you use Mazilla... switch or use extensions until further notice.

[okiehsch]

If you you use Google Chrome (which probably you do, since you gave links to Chrome store), use extension for now and wait till 59 is released.

Actually the issue has been fixed in Chrome 58 released today.
https://bugs.chromium.org/p/chromium/issues/detail?id=683314

[gorhill]

I will consider adding a small sign (something like superscript letter u prefix -- ^u аpple.com) aside hostname entries in the dynamic filtering pane which contain at least one Unicode character, and hovering over these hostnames will show the punycode version.

[Atavic]

It's a browser issue.

For Firefox, Palemoon, K-meleon:
In about:config set network.IDN_show_punycode to True (Default value is set to false).

[RoxKilly]

I'm with @bershan2 here. This doesn't seem to me to be in uBO's wheelhouse since there is no filtering, so the maintenance overhead that comes with introducing a new capability along with its UI may not make sense. Besides consider: the suffix u @gorhill will consider adding won't mean anything to casual users (and most advanced users) unless it comes with a tooltip that links to more info.

[gorhill]

won't mean anything to casual users

It will be displayed in the advanced user pane, and only for when there is a mix of ascii and unicode characters in the domain name.

maintenance overhead that comes with introducing a new capability

I can't make sense of this. This is a rendering issue, not a new capability one. The code change is merely how to render domain names in the advanced user pane, there is no new capability introduced.

Let's not turn a simple issue into a never ending bikeshedding discussion.

[gorhill]

Commit: 0b3d147 + 52332da:

add basic mitigation to potential abuse of IDN

improve solution to #2550: mind only the 22 confusable unicode characters

Key word: mitigation. There is no magic solution for the whole issue. The chosen (and trivial codewise) change here is to render the base domain name with the label idn for when the following condition is met:

The base domain is a mix of one more of the "22 confusable unicode characters" and zero or more normal ascii characters, and nothing else.

Examples:

• api.jquery.com
• api.јquеrу.com: mimicry
• québec.qc.ca
• wіkіреdіа.org: mimicry
• δπθ.gr
• 清华大学.中国
• ea.com
• еа.com: look-alike domain name

The label is strictly informative of the above condition -- the user is responsible to act based on that information.

The final solution is inspired from the discussions at:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1332714
• https://bugs.chromium.org/p/chromium/issues/detail?id=683314

Additionally, the punycode version of a base domain name will be provided through a tooltip if there is at least one unicode character in the base domain name minus public suffix.

Demo: http://raymondhill.net/ublock/idn-tricks.html.

[gorhill]

I did some more reading and modified the condition under which uBO will use the idn label. I modified my comment above to reflect these changes. Mainly, the label idn will be used if and only if there is potential for ambiguity. I learned that the whole issue can be narrowed down to only 22 unicode characters -- so this means that with the better solution the idn label won't be used when there is no place for ambiguity (for example, québec.qc.ca).

[gorhill]

I'm going to need to revise slightly again, the idn label would not be used currently for québеc.qc.ca -- the е is not ASCII, it's the Cyrillic character. The logic in the solution used for Chromium is what really work, I just need to implement it more fully.

[lowven]

@gorhill

When I test your IDN test site and look in advanced pane the international root domains correctly have the IDN symbols. But if you click +all to show subdomains it is not that clear. Unlike jquery.com (mimicry) api.jquery.com (mimicry) shows as api.jquery.com under jquery.com (mimicry) but with no IDN symbol or hover text showing the real IDN domain name (api.xn-qur-sdd5e5f.com). It should show these for subdomains too to avoid confusion.

Also, try creating some dynamic filters from advanced pane for both api.jquery.com (real) and api.jquery.com (mimicry) and then go to My Rules. There are 2 rules that are almost visually identical as api.jquery.com but they are different rules. It should instead create 2 rules that should be visually different, 1 as api.query.com (real) and the other api.xn-qur-sdd5e5f.com (mimicry).

What do you think?