Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Punycode phishing attack detection #2550

Closed
fproulx-pbox opened this issue Apr 19, 2017 · 12 comments

Comments

@fproulx-pbox
Copy link

commented Apr 19, 2017

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

This comment has been minimized.

Copy link
Author

commented Apr 19, 2017

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

@bershan2

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2017

@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/

  1. 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
  2. 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

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2017

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

  1. If you use outdated browsers... update or use extensions forever.
  2. If you use up-to-date Apple Safari, Microsoft Edge, and Internet Explorer, you are all set.
  3. 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.
  4. If you use Mazilla... switch or use extensions until further notice.
@okiehsch

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2017

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 gorhill reopened this Apr 20, 2017

@gorhill

This comment has been minimized.

Copy link
Owner

commented Apr 20, 2017

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

This comment has been minimized.

Copy link

commented Apr 20, 2017

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

This comment has been minimized.

Copy link

commented Apr 21, 2017

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

This comment has been minimized.

Copy link
Owner

commented Apr 21, 2017

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

This comment has been minimized.

Copy link
Owner

commented Apr 22, 2017

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:

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.

a

@gorhill gorhill closed this Apr 22, 2017

gorhill added a commit that referenced this issue Apr 22, 2017
@gorhill

This comment has been minimized.

Copy link
Owner

commented Apr 22, 2017

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

This comment has been minimized.

Copy link
Owner

commented Apr 22, 2017

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.

gorhill added a commit that referenced this issue Apr 22, 2017
@lowven

This comment has been minimized.

Copy link

commented Dec 24, 2017

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.