Phishing with Unicode Domains
xn--80ak6aa92e.com
Phishing with Unicode Domains
1–10 of 39 posts
Re: Phishing with Unicode Domains
#2Ouch. 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?
Re: Phishing with Unicode Domains
#3Chrome 58 rolled out yesterday fix the issue
Re: Phishing with Unicode Domains
#4Chrome 58 rolled out yesterday fix the issue
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.
Re: Phishing with Unicode Domains
#5Gosh 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... - 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.
Re: Phishing with Unicode Domains
#6Chrome 58 rolled out yesterday fix the issue
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 peopl…
What would you consider a proper fix?
Re: Phishing with Unicode Domains
#7Chrome 58 rolled out yesterday fix the issue
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 peopl…
I can't think of a real fix though; you'd have to disambiguate the Unicode itself for that.
Re: Phishing with Unicode Domains
#8Earlier quoted context omitted.
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 peopl…
What would you consider a proper fix?
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.
Re: Phishing with Unicode Domains
#9Re: Phishing with Unicode Domains
#10Earlier quoted context omitted.
What would you consider a proper fix?
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 th…
The fix is 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.