5 ms·

Phishing with Unicode Domains

65 points by tvvocold 10y ago

Jonnax 10y ago
Ouch. This is a good one. Whilst it's easy to say "Just enable punicode always" People that use the web in different languages lose a lot of functionality because of it. I could imagine a solution would be to collect a list of homogliphs then when the browser suspects an overlap it does a search for similarly spelt sites then warns the user of the possibility of the site being an imitation. Of course then also converting the URL in the address bar to punicode. What other ideas are there?
- 3131s 10y ago
  How about an icon next to the URL bar that displays and allows a user to select their preferred Unicode block(s)? If a character in the URL falls outside that block then the URL is highlighted in red or some warning is displayed.
mirages 10y ago
Chrome 58 rolled out yesterday fix the issue
- pluma 10y ago
  Except the fix seems to be simply to show the punycode URL. That's not a fix, that's a workaround. EDIT: This led me to read up on how various browsers handle non-ASCII letters which in turn helped me discover that apparently no browser supports the German sharp-s ("ß") which gets auto-expanded to "ss" although domains containing the sharp-s can be registered separately from "ss" domains -- effectively allowing people to register domains that can't be accessed in any browser without explicitly using the unreadable punycode representation. EDIT2: It seems the fix is more fine-tuned than just showing punycode for everything. So it's still a workaround (punycode URLs are not fit for human consumption so this still actively punishes confusing domains even if they're not intentionally malicious) but it affects fewer domains than I initially feared.
  - jwilk 10y ago
    What would you consider a proper fix?
    - pluma 10y ago
      Unless they did something ridiculously clever, they just made IDN domains unusable. That means legitimate IDN domains are as affected as malicious ones, punishing non-ASCII languages. A proper fix would keep the domain name human-readable but differentiate between the ASCII and homoglyph versions. How? Not my job to figure that out. If you want a random idea: the homoglyphs could be rendered differently (i.e. make the font disambiguate them). That's probably not a perfect solution but I'm not getting paid to do this.
      - jwilk 10y ago
        The fix is https://chromium.googlesource.com/chromium/src/+/08cb718ba7c3961c1006176c9faba0a5841ec792 https://chromium.googlesource.com/chromium/src/+/08cb718ba7c... : > Block a label made entirely of Latin-look-alike Cyrillic letters when the TLD is not an IDN (i.e. this check is ON only for TLDs like 'com', 'net', 'uk', but not applied for IDN TLDs like рф. That's neither "ridiculously clever", nor it will make (non-nefarious) IDN domains ununsable.
        pluma 10y ago
        Except that this assumes there are no legitimate IDN domains on non-IDN TLDs. Considering how few IDN TLDs there are, I would wager that most IDN domains don't live on these TLDs. However it seems they don't flat out block all IDN domains but only those containing the homoglyphs. IUIC they also don't block domains containing Cyrillic homoglyphs alongside other Cyrillic characters. This seems somewhat reasonable. I still think rendering Cyrillic in a way that makes alphabet mismatches more obvious would be a better and more future-proof solution.
        petters 10y ago
        That fix is an improvement, but in general I think it is better to whitelist stuff instead. Unicode is huge and complicated.
stereo 10y ago
Gosh that’s old. The original paper was from 2001, the Shmoo group wrote about it in 2005 - https://blogs.oracle.com/yakshaving/entry/so_not_funny_shmoo_group https://blogs.oracle.com/yakshaving/entry/so_not_funny_shmoo... - and Joi Ito and I were able to register Veriѕign.com then, to highlight how their greedy mismanagement of .com made this possible. Three possible solutions, not mutually incompatible: * Make the browsers catch it - Chrome just shows characters that look like apple.com here, and shouldn’t. * Whitelist character sets that are allowed to be mixed, at the registry level - it should only be possible to mix cyrillic-latin homoglyphs with cyrillic non-homoglyphs. * Don’t allow IDNs on gTLDs - if you want “écriture”, get écriture.fr, not .com Obviously, the registries have a conflict of interest here, and won’t let 2 and 3 happen on .com because it would cut into Verisign's revenue. See also https://en.wikipedia.org/wiki/IDN_homograph_attack https://en.wikipedia.org/wiki/IDN_homograph_attack
- darklajid 10y ago
  I'm not quite sure if I understand your second suggestion. Isn't that what the article claims to circumvent? I read that as 'Firefox/Chrome already do not render these characters, unless they're all from the same subset' - and the 'apple.com' is presented as completely cyrillic (I don't know/understand that alphabet and might've missed either your point or misread the article).
- ko27 10y ago
  Update your Chrome
  - runeks 10y ago
    There are no updates to Chrome for iPad in the App Store, and it looks like this: http://i.imgur.com/JjR5evp.jpg http://i.imgur.com/JjR5evp.jpg
- Dylan16807 10y ago
  As far as I understand it the actual solution is that registries aren't supposed to let you buy a domain that looks like an existing domain. But that's broken? And this domain isn't made of mixed characters.
jwilk 10y ago
https://en.wikipedia.org/wiki/IDN_homograph_attack https://en.wikipedia.org/wiki/IDN_homograph_attack
averagewall 10y ago
Do unicode URLs actually provide any real value? Every web user must be already used to typing Latin characters because so many major websites use them. So nobody would be excluded by that. Whereas, any non-Latin character is going to be nearly impossible for most of the world to enter. A particularly terrible language is Chinese where most old people can't type the characters even though they can type Latin letters. That's because you have to deliberately invest time to sit down and learn an input method which is a non-trivial endeavor that takes weeks of effort and old people just aren't going to go back to school for that.
- pilif 10y ago
  > Do unicode URLs actually provide any real value? yes. Not everybody speaks english. >Every web user must be already used to typing Latin characters because so many major websites use them. s/web user/existing web user/ Unicode domains are one more piece required for the net to be as inclusive as possible.
  - lambdadmitry 10y ago
    On the other hand, unicode domains may lead to balkanization of the net. How would you even type in something like борщ.рф (and before you ask, you can easily translate its contents using Google Translate after entering the URL)? And everyone, just everyone in Russia is already capable of typing in stuff in ASCII. So the upside is small and diminishing (more people learn English over time and that's a beautiful thing), and the downside is the reversal of the unification effect that Internet had. I'm pretty sure it's not an obvious choice. I should also add that the general attitude of "not everybody speaks English so we should adapt our tech to reduce the need for English" seems to imply a privilege of already knowing English. It is true that not everyone speaks English at this moment, but the right solution would be to teach everyone English as it expands horizons immensely, not to balkanize the world. Languages are not equal and English is the single most useful one. One can argue that e.g. Russian is just as good as English, but it's just not true. The amount of information available in English is immeasurably higher than in any other national language, and one should have the privilege of knowing English for some time (or being a native speaker) to forget the fact.
deleted 10y ago
[deleted]
herghost 10y ago
Safari just displays it as "https://www.xn--80ak6aa92e.com" https://www.xn--80ak6aa92e.com" whereas Chrome (Version 57.0.2987.133 (64-bit)) displays it as the author intended.
- herghost 10y ago
  heh, and updating Chrome to Version 58.0.3029.81 (64-bit) fixes the issue there.
- wila 10y ago
  Same with pale moon just displays it with the puny code instead of the unicode characters. Firefox 52.0.2 here displays it as apple.com So updated Firefox (which failed until I reran it) and then.. Still displays it as apple.com (Firefox 53.0)
  - wila 10y ago
    OK, I read the linked article now and apparently you have to change a setting in Firefox in order to see the URL in punycode as Mozilla decided it is "not a bug". Eg. about:config and set the "network.IDN_show_punycode" to true to avoid this trap.
- runeks 10y ago
  Chrome on iPad fails miserably: http://i.imgur.com/JjR5evp.jpg http://i.imgur.com/JjR5evp.jpg
merricksb 10y ago
Previous recent discussions: https://news.ycombinator.com/item?id=14130241 https://news.ycombinator.com/item?id=14130241 https://news.ycombinator.com/item?id=14119713 https://news.ycombinator.com/item?id=14119713

65 points by tvvocold 10y ago

Ouch. This is a good one. Whilst it's easy to say "Just enable punicode always" People that use the web in different languages lose a lot of functionality because of it. I could imagine a solution would be to collect a list of homogliphs then when the browser suspects an overlap it does a search for similarly spelt sites then warns the user of the possibility of the site being an imitation. Of course then also converting the URL in the address bar to punicode. What other ideas are there?

3131s 10y ago
How about an icon next to the URL bar that displays and allows a user to select their preferred Unicode block(s)? If a character in the URL falls outside that block then the URL is highlighted in red or some warning is displayed.

mirages 10y ago

Chrome 58 rolled out yesterday fix the issue

pluma 10y ago
Except the fix seems to be simply to show the punycode URL. That's not a fix, that's a workaround. EDIT: This led me to read up on how various browsers handle non-ASCII letters which in turn helped me discover that apparently no browser supports the German sharp-s ("ß") which gets auto-expanded to "ss" although domains containing the sharp-s can be registered separately from "ss" domains -- effectively allowing people to register domains that can't be accessed in any browser without explicitly using the unreadable punycode representation. EDIT2: It seems the fix is more fine-tuned than just showing punycode for everything. So it's still a workaround (punycode URLs are not fit for human consumption so this still actively punishes confusing domains even if they're not intentionally malicious) but it affects fewer domains than I initially feared.
- jwilk 10y ago
  What would you consider a proper fix?
  - pluma 10y ago
    Unless they did something ridiculously clever, they just made IDN domains unusable. That means legitimate IDN domains are as affected as malicious ones, punishing non-ASCII languages. A proper fix would keep the domain name human-readable but differentiate between the ASCII and homoglyph versions. How? Not my job to figure that out. If you want a random idea: the homoglyphs could be rendered differently (i.e. make the font disambiguate them). That's probably not a perfect solution but I'm not getting paid to do this.
    - jwilk 10y ago
      The fix is https://chromium.googlesource.com/chromium/src/+/08cb718ba7c3961c1006176c9faba0a5841ec792 https://chromium.googlesource.com/chromium/src/+/08cb718ba7c... : > Block a label made entirely of Latin-look-alike Cyrillic letters when the TLD is not an IDN (i.e. this check is ON only for TLDs like 'com', 'net', 'uk', but not applied for IDN TLDs like рф. That's neither "ridiculously clever", nor it will make (non-nefarious) IDN domains ununsable.
      - pluma 10y ago
        Except that this assumes there are no legitimate IDN domains on non-IDN TLDs. Considering how few IDN TLDs there are, I would wager that most IDN domains don't live on these TLDs. However it seems they don't flat out block all IDN domains but only those containing the homoglyphs. IUIC they also don't block domains containing Cyrillic homoglyphs alongside other Cyrillic characters. This seems somewhat reasonable. I still think rendering Cyrillic in a way that makes alphabet mismatches more obvious would be a better and more future-proof solution.
      - petters 10y ago
        That fix is an improvement, but in general I think it is better to whitelist stuff instead. Unicode is huge and complicated.

stereo 10y ago

Gosh that’s old. The original paper was from 2001, the Shmoo group wrote about it in 2005 - https://blogs.oracle.com/yakshaving/entry/so_not_funny_shmoo_group https://blogs.oracle.com/yakshaving/entry/so_not_funny_shmoo... - and Joi Ito and I were able to register Veriѕign.com then, to highlight how their greedy mismanagement of .com made this possible. Three possible solutions, not mutually incompatible: * Make the browsers catch it - Chrome just shows characters that look like apple.com here, and shouldn’t. * Whitelist character sets that are allowed to be mixed, at the registry level - it should only be possible to mix cyrillic-latin homoglyphs with cyrillic non-homoglyphs. * Don’t allow IDNs on gTLDs - if you want “écriture”, get écriture.fr, not .com Obviously, the registries have a conflict of interest here, and won’t let 2 and 3 happen on .com because it would cut into Verisign's revenue. See also https://en.wikipedia.org/wiki/IDN_homograph_attack https://en.wikipedia.org/wiki/IDN_homograph_attack

darklajid 10y ago
I'm not quite sure if I understand your second suggestion. Isn't that what the article claims to circumvent? I read that as 'Firefox/Chrome already do not render these characters, unless they're all from the same subset' - and the 'apple.com' is presented as completely cyrillic (I don't know/understand that alphabet and might've missed either your point or misread the article).
ko27 10y ago
Update your Chrome
- runeks 10y ago
  There are no updates to Chrome for iPad in the App Store, and it looks like this: http://i.imgur.com/JjR5evp.jpg http://i.imgur.com/JjR5evp.jpg
Dylan16807 10y ago
As far as I understand it the actual solution is that registries aren't supposed to let you buy a domain that looks like an existing domain. But that's broken? And this domain isn't made of mixed characters.

jwilk 10y ago

https://en.wikipedia.org/wiki/IDN_homograph_attack https://en.wikipedia.org/wiki/IDN_homograph_attack

averagewall 10y ago

Do unicode URLs actually provide any real value? Every web user must be already used to typing Latin characters because so many major websites use them. So nobody would be excluded by that. Whereas, any non-Latin character is going to be nearly impossible for most of the world to enter. A particularly terrible language is Chinese where most old people can't type the characters even though they can type Latin letters. That's because you have to deliberately invest time to sit down and learn an input method which is a non-trivial endeavor that takes weeks of effort and old people just aren't going to go back to school for that.

pilif 10y ago
> Do unicode URLs actually provide any real value? yes. Not everybody speaks english. >Every web user must be already used to typing Latin characters because so many major websites use them. s/web user/existing web user/ Unicode domains are one more piece required for the net to be as inclusive as possible.
- lambdadmitry 10y ago
  On the other hand, unicode domains may lead to balkanization of the net. How would you even type in something like борщ.рф (and before you ask, you can easily translate its contents using Google Translate after entering the URL)? And everyone, just everyone in Russia is already capable of typing in stuff in ASCII. So the upside is small and diminishing (more people learn English over time and that's a beautiful thing), and the downside is the reversal of the unification effect that Internet had. I'm pretty sure it's not an obvious choice. I should also add that the general attitude of "not everybody speaks English so we should adapt our tech to reduce the need for English" seems to imply a privilege of already knowing English. It is true that not everyone speaks English at this moment, but the right solution would be to teach everyone English as it expands horizons immensely, not to balkanize the world. Languages are not equal and English is the single most useful one. One can argue that e.g. Russian is just as good as English, but it's just not true. The amount of information available in English is immeasurably higher than in any other national language, and one should have the privilege of knowing English for some time (or being a native speaker) to forget the fact.

deleted 10y ago

[deleted]

herghost 10y ago

Safari just displays it as "https://www.xn--80ak6aa92e.com" https://www.xn--80ak6aa92e.com" whereas Chrome (Version 57.0.2987.133 (64-bit)) displays it as the author intended.

herghost 10y ago
heh, and updating Chrome to Version 58.0.3029.81 (64-bit) fixes the issue there.
wila 10y ago
Same with pale moon just displays it with the puny code instead of the unicode characters. Firefox 52.0.2 here displays it as apple.com So updated Firefox (which failed until I reran it) and then.. Still displays it as apple.com (Firefox 53.0)
- wila 10y ago
  OK, I read the linked article now and apparently you have to change a setting in Firefox in order to see the URL in punycode as Mozilla decided it is "not a bug". Eg. about:config and set the "network.IDN_show_punycode" to true to avoid this trap.
runeks 10y ago
Chrome on iPad fails miserably: http://i.imgur.com/JjR5evp.jpg http://i.imgur.com/JjR5evp.jpg

merricksb 10y ago

Previous recent discussions: https://news.ycombinator.com/item?id=14130241 https://news.ycombinator.com/item?id=14130241 https://news.ycombinator.com/item?id=14119713 https://news.ycombinator.com/item?id=14119713