WingNews logo WingNews GitHub [2]
top | item 14155091

You think you can't be phished?

192 points| ribasushi | 9 years ago |hackaday.com | reply

133 comments

order
[+] walrus|9 years ago|reply
Firefox: open about:config, set network.IDN_show_punycode to true. Next time you open the page, the address bar will show https://www.xn--80ak6aa92e.com/ instead of https://www.apple.com/. Better yet, always type in or bookmark pages where you might enter sensitive information.

I was surprised this was still an issue, as I heard about IDN homograph attacks years ago.

[+] TeMPOraL|9 years ago|reply
IDN homograph attacks are old, but - as the original article shows - people are still vulnerable to this when you manage to make a full name homograph entirely within one language in Unicode. The only fixes for it that come to my mind are dropping IDN altogether, disambiguating homographs on IDN level, or... disambiguating Unicode.
[+] pasta|9 years ago|reply
This is strange. Maybe 7 years ago I tested this in all browsers and the only browser that didn't show the punycode was Internet Explorer.

Now I'm on Firefox and was fooled by the link. Thanks for the about:config.

[+] noja|9 years ago|reply
Maybe the non-ascii characters could be coloured somehow, like with a different colour background.

That way we could still show the real characters and not the punycode.

[+] awqrre|9 years ago|reply
Why would Mozilla think that it would be a good idea to set the default to false... at least in the English language.
[+] inetknght|9 years ago|reply
The fact that I have to open developer tools to inspect the cert on Chrome is infuriating.
[+] problems|9 years ago|reply
I'm reminded of a Torvalds quote from about a decade ago:

> This 'users are idiots, and are confused by functionality' mentality of Gnome is a disease. If you think your users are idiots, only idiots will use it.

[+] dunham|9 years ago|reply
Yes, it is infuriating. I didn't even realize it was in the dev tools until today. I thought they'd just dropped the functionality altogether.

The dev tools are nice, and I like using the multiple profiles for both dev (logging in as multiple users) and segregating my banking cookies. Otherwise I'd drop chrome for safari.

(I also wish they'd expose certificate metadata to plugins, so I could write my own cert checking/pinning code.)

[+] AcerbicZero|9 years ago|reply
It was one of those minor chrome changes that shouldn't bother me, but ends up driving me slightly insane.
[+] zip1234|9 years ago|reply
Why would they even change that?
[+] atmosx|9 years ago|reply
I open Safari just for that... It wasn't like that a few versions back.
[+] beamatronic|9 years ago|reply
What if you just don't click on any links in email? Particularly if they are really important sites. Just accomplish the proposed task another way. For example, if you get an email from Paypal, stating that you need to update a credit card or something, don't click their link, instead open a browser and enter "https://www.paypal.com" yourself, and go into your account information and look for your saved payment methods.

edit: typos

[+] pasta|9 years ago|reply
Our government (Netherlands) doesn't provide links in emails. They even don't provide the domain name (which can be turned in to a link by the client), but refer to the website with the name of the website.

For example:

"There is a new message in your inbox on MijnOverheid. Please visit MijnOverheid to read this message."

And every time they also warn that they never will provide any link in any email.

I would be great if more (all) websites start doing this.

[+] jandrese|9 years ago|reply
The only time I click on links in emails is when I've just requested them. Like I've just set up an account and it says it is sending me an email to verify the address. If it is some email out of the blue I would never click the link or open the attachment. I actually enforce the attachment rule by configuring my mail client to only support "save" as an option for attachments.
[+] diminoten|9 years ago|reply
A good way to get a lot of people with a phishing attempt is the 'Unsubscribe' button in an email.
[+] askmike|9 years ago|reply
What about links on websites? Do you also not click those?
[+] Adverblessly|9 years ago|reply
I always hover over links before I click them to see where they actually lead in the status bar. It is less safe than your suggestion (since if I'm not careful I can fall for "googel.com" or "goog1e.com"), but is still often useful (even just to avoid going somewhere I'm not interested in going, not specifically against phishing).
[+] jdavis703|9 years ago|reply
Which is why I look for the organization's name in the browser bar when I'm logging in to a high-value website (Google, Apple my bank, etc). For those who don't know the UI for extended verification certificates see the difference in the screenshot: http://imgur.com/a/ycVwA.
[+] tener|9 years ago|reply
This is very easy to miss, even as a technical user. Still good advice.
[+] calebegg|9 years ago|reply
Google doesn't use EV certs.
[+] 542458|9 years ago|reply
Amusingly, Facebook seems to block this link from being posted publicly (The site reports "There was a problem updating your status. Please try again in a few minutes" - private messages work fine however).

I wonder what Facebook's heuristic there is, since they don't seem to block all punycode URLs. Maybe something about character distribution (all latin-like characters -> probably phishing)?

Edit: Actually, it might not be a block at all. I think it might just be a bug in Facebook's URL parser, since when pasted into messages the automatic hyperlink is set to http://invalid.invalid.

[+] artimaeis|9 years ago|reply
This is probably the most effective advertising to update to the newest Chrome release that I've ever seen.
[+] irl_|9 years ago|reply
I really hope things like this do not lead us to a mentality that anything that isn't the Latin alphabet is malware or spam. There are people in the world using non-Latin alphabets and allowing them to have domain names in their native alphabets is a good thing, we just haven't worked out how to do it securely yet.

Disabling the rendering of punycode is actually not helpful in cases where you wanted to visit a domain using the Cyrillic alphabet which you want to be sure of, and someone registered some similar looking domain which looks equally like a bunch of gibberish to the one you're looking for.

Some suggestions, maybe good, maybe bad:

* It may be as simple as adding a character set into the address bar

* Flag a warning if the domain name alphabet doesn't match the page content (as would be the case in this example) or maybe something else

[+] kardos|9 years ago|reply
>This affects the current version of Chrome browser, which is version 57.0.2987 and the current version of Firefox, which is version 52.0.2.

Firefox 52.0.2 & linux here, and the "L" in the URL looks like a capital i with serifs - quite noticeable. Perhaps different on windows/osx though.

[+] gwu78|9 years ago|reply
Text-only browser shows the IDN, not the phished domain.

</sarcasm>I guess I need to "upgrade to a modern browser" for websites to work correctly?</sarcasm>

As an aside, I still do not understand how "modern" browsers evolved to hiding portions of the URL or using a phony address bar i.e. "omnibox" to the right of the real address bar.

In the first case, it seems to offer no benefit other than to hide important details.

In the second case, it seems so overtly deceptive for newcomers to the www that I am surprised they could pull it off.

Maybe these things have changed recently as these monster programs are constantly changing. If so, pardon my ignorance.

Is it not true that users who do not understand the basics of www usage e.g., what is a domain, a URL, etc. are always going to be at risk of manipulation?

[+] TeMPOraL|9 years ago|reply
> Is it not true that users who do not understand the basics of www usage e.g., what is a domain, a URL, etc. are always going to be at risk of manipulation?

It is, and the general attitude seriously irks me. Technology is complex, but if they're hiding the actual details behind half-assed, inconsistent, lying abstractions, they're not helping anyone - the user will never develop a consistent mental model of what's going on if every other piece of software lies about some parts of it.

[+] gommm|9 years ago|reply
As much as I like Firefox, I don't really agree with their reason for not considering this to be a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1332714

> Indeed. Our IDN threat model specifically excludes whole-script homographs, because they can't be detected

> programmatically and our "TLD whitelist" approach didn't scale in the face of a large number of new TLDs. If you are

> buying a domain in a registry which does not have proper anti-spoofing protections (like .com), it is sadly the

> responsibility of domain owners to check for whole-script homographs and register them.

> We can't go blacklisting standard Cyrillic letters.

[+] robbyking|9 years ago|reply
I wanted to share the fake Apple URL with my team, and Slack expanded it to https://www.xn--pple-43d.com when I hit send.
[+] Dylan16807|9 years ago|reply
Note that the URL people are excited about is the pure-cyrillic xn--80ak6aa92e, not xn--pple-43d.
[+] TheAceOfHearts|9 years ago|reply
Even though Safari is behind the curve for many web tech features, I've been pretty happy using it as my main browser for the last few months. On a MacBook Pro, none of the browsers even come close to competing with Safari when it comes to battery life. I still keep Chromium and Firefox installed, and Chromium is my go-to option for web development. But I'm happy to find that Safari has sane defaults when it comes to displaying URLs.
[+] LeoPanthera|9 years ago|reply
Safari is not fooled. http://i.imgur.com/2PyCWtz.png
[+] nimnio|9 years ago|reply
Brave is not fooled either, which is interesting because it's based on Chromium.

Brave 0.14.1 libchromiumcontent 57.0.2987.133

Fixed in Chrome 58, so I wonder what the significant difference is.

[+] amenghra|9 years ago|reply
U2F as a second factor prevents this (and many other) kinds of phishing attacks.

The token's crypto takes the page's domain into account.

[+] SadWebDeveloper|9 years ago|reply
Verified by: Let's Encrypt

Somehow i was expecting that comodo was the one culprit for the valid cert but i forgot how easy is to ask for certs like this. Sometimes i think that lets encrypt is hurting more than doing good.

[+] goodplay|9 years ago|reply
Given a choice between a safe web by default and nice looking urls, I'd choose the former.

Furthermore, the real problem is that the green lock is displayed for https sites rather than those with extended verification. Http should be red, https should be plain, and ev https should be green with a padlock.

It's a failure in browser UI.

[+] zulln|9 years ago|reply
A password manager would be what (hopefully) saves me from this.
[+] _nalply|9 years ago|reply
I thought about normalising homographs then I tried out an implementation.

https://github.com/nalply/homoglyph_normalize

The idea is: get confusables.txt from Unicode and generate from that a JavaScript object which does the mapping.

It's not guaranteed to work, I didn't even test it, but it's perhaps a starting point for whatever you want to do with it.