Phishing with Unicode Domains
11–20 of 28 posts
Re: Phishing with Unicode Domains
#12Can a browser could track how many language/character sets are typically used by a browser profile, and warn the user when they are about to use a new, previously unused set, rather than waving the duty off as the "responsibility of domain owners"? With now over 1000 top-level domains, and however many homographic matches among character sets, expecting people to register dozens of matching domains seems unrealistic.
Won't it be even easier to just check if the domain contains something outside the currently used character set (perhaps always allowing ascii)? I think that, plus a "you have never visited this site before" kind of warning could go a long way towards combating these kinds of attacks. I think the real devil is going to be in the UI. You don't want to make it overly scary (otherwise you penalize domains which use some…
Well if you're Russian (or one of the many other nationalities that uses a Cyrillic character set), then that's still not going to help you. If you visit аррІе.com (all Cyrillic characters) you wouldn't get any warning that it wasn't apple.com (all Latin characters). It's a rather euro-centric solution to the problem.
The thing is, why should an English speaking person get a warning when they visit a Cyrillic url, but a Russian speaking person doesn't get a warning when visiting a url with Latin characters? Why is apple.com assumed to be legitimate and аррІе.com is considered the fraud?
In fact I'm almost sure that browsers originally used to disable IDNs using some kind of scheme that relied on language preferences back when they first started being used. I suspect they eventually abandoned that approach for this very reason. It only seems like a good idea if you're English speaking (or at least some other Latin-based language).
Re: Phishing with Unicode Domains
#13HN Discussion about the same topic from 2 days ago (126 comments to date): https://news.ycombinator.com/item?id=14119713
Re: Phishing with Unicode Domains
#14HN Discussion about the same topic from 2 days ago (126 comments to date): https://news.ycombinator.com/item?id=14119713
High level recap:
Chrome - fixed in 59 (current stable is 57)
Firefox - no plans to change; you can adjust network.IDN_show_punycode in about:config
IE - immune
Safari - immune
Re: Phishing with Unicode Domains
#15Earlier quoted context omitted.
Considering how easy email is to spoof, why bother using a unicode domain which is only similar to the target domain? Why not just use the real domain instead?
Spoofing isnt so easy for gmail and yahoo inboxes. Some web-clients warn of a return path too. For sophisticated spoofing and phishing unicode domains are helpful. Plus, spoofing emails is just a small attack vector.
A lot of email clients give a warning "this email might be spoofed". The good ones are more likely to send you straight to spam.
Still, most people are unable to confirm the origin of an email. The warning, if any, is likely to be ignored.
Re: Phishing with Unicode Domains
#16HN Discussion about the same topic from 2 days ago (126 comments to date): https://news.ycombinator.com/item?id=14119713
High level recap: Chrome - fixed in 59 (current stable is 57) Firefox - no plans to change; you can adjust network.IDN_show_punycode in about:config IE - immune Safari - immune
Could you explain what fixed/immune means? Is it only the confusable characters, ie characters that are visually identical or near-identical to latin characters, that is getting the punycode treatment?
Re: Phishing with Unicode Domains
#17What an odd coincidence: I just published a Go package yesterday to detect such attacks in source code. Is there a homography bug going around?
https://github.com/NebulousLabs/glyphcheck
(btw, Wikipedia notes that "The term homograph is sometimes used synonymously with homoglyph, but in the usual linguistic sense, homographs are words that are spelled the same but have different meanings, a property of words, not characters.")
Re: Phishing with Unicode Domains
#18What an odd coincidence: I just published a Go package yesterday to detect such attacks in source code. Is there a homography bug going around? https://github.com/NebulousLabs/glyphcheck (btw, Wikipedia notes that "The term homograph is sometimes used synonymously with homoglyph, but in the usual linguistic sense, homographs are words that are spelled the same but have different meanings, a property of words, not cha…
Interesting, but -from the repo description- why this is limited to Go source code files?
Re: Phishing with Unicode Domains
#19This is the scariest one: http://www.xn--80a6aa.com/ & http://www.app.com/
Re: Phishing with Unicode Domains
#20What an odd coincidence: I just published a Go package yesterday to detect such attacks in source code. Is there a homography bug going around? https://github.com/NebulousLabs/glyphcheck (btw, Wikipedia notes that "The term homograph is sometimes used synonymously with homoglyph, but in the usual linguistic sense, homographs are words that are spelled the same but have different meanings, a property of words, not cha…
Interesting, but -from the repo description- why this is limited to Go source code files?
Mostly because it has an "ignore comments" mode. A lot of non-English speaking programmers write code using English keywords and identifiers but use their native language in the comments.
With some work, it could be made language-agnostic, but that's more than I have time for right now. If comments aren't an issue, you can just grep through all your source files for the offending characters, which shouldn't take more than a simple bash script.