In December 2001, a paper was released describing Homograph attacks. This new attack allows an attacker/phisher to spoof the domain/URLs of businesses. At the time this paper was written, no browsers had implemented Unicode/UTF8 domain name resolution.

Fast forward to today: Verisign has championed International Domain Names (IDN). RACES has been replaced with PUNYCODE. Every recent gecko/khtml based browser implements IDN (which is just about every browser except for IE; plug-in are available).

See also an article at Boing Boing describing the issue. The Shmoo Group provides proof-of-concept examples where they have spoofed paypal.com. The irony is that this is the first security alert I've ever seen that effects every browser except Microsoft IE.

If you're using a mozilla-based browser (Firefox, e.g.), there are instructions on how to implement a workaround by setting 'network.enableIDN' to false, but there are also reports that the workaround doesn't fix the issue. Making the change worked for me; your mileage may vary. Read the advisory by the Schmoo Group (including footnotes) and the article at Boing Boing for more information.

Comments

Restart your browser and try it again. It should fail. It looks like Mozilla browsers aren't saving the state of the "no idn" flag correctly.

This is a huge, scary problem, and apparently, when IDN was first proposed, this exact problem was noted as a flaw. IE is only immune because it doesn't implement IDN support. Who knew that feature-incompleteness was a security feature?

Slashdot actually has useful commentary on this topic.

(For the less technical, IDN is way to map URLs with non-English characters to a URL that is only composed of English characters. Browsers that support it show the non-English character name in the address bar, but use the converted address behind the scenes. The problem results from using characters that are not part of the standard English character set, but look like characters that are. To the computer, they're different, but to a person, they're identical. You can then put up a fake web site that looks like a real web site and get people to enter in their personal information.)

It's scary that Shmoo has even been able to build a site behind ssl that Firefox was more than happy to accept. And even scarier that after changing the config value and restarting the browser, I still get carried to the bogus site. The config screen still says that the network.EnableIDN value is false, but it seems to ignore it. Toggling it true and back to false fixes it temporarily again.

The reason that FireFox allowed an SSL connection is that the Shmoo group got a cert from an organization that is signed in turn by one of the root CAs recognized by FireFox, Safari, et al. Any decent phisher could do the same thing, supplying a phone business address to get the cert.

Mozilla et al can't do anything about it, because there's no way to tell that a cert is for a company up to no good. All it can tell is whether or not the cert is signed by someone who (ultimately) is trusted.

Of course. But that's one of the issues behind the "Web of Trust". You can tell that the cert is current and belongs to, for instance, www.paypal.com. But without examining the certificate yourself you don't know whether this is the trustworthy well-known online payment company or somebody else. The browser accepts the cert and moves on. And the user happily glances at the little lock and marches forward. Unlike, for instance, paying a bill by mail, the user can't easily tell that he's sending a payment to Nigeria rather than Cupertino.

This is the social side of information security, that always comes second when dealing with computer communications.

I've poked around with this for a few minutes and discovered if you mouse over the link in to the fake paypal in theShmoo group advisory the status bar in Safari shows paypal.com and not p(freaky looking A)ypal.com. However, when you copy and then paste the URL into a text app, it's painfully obvious that that's not paypal.com.

While I know little, very little, about Safari and OSX it's too bad there isn't some way to get Safari to tap into the Unicode bit of OS X, then maybe it would display the freaky looking A properly. Just a thought.

Thanks for the heads up, though I'm wary enough to not even click the paypal link when I use ebay or anywhere else.

If a text app isn't showing a lower-case A (technically, it's a cyrillic lowercase A), then it's the text app that isn't using Unicode properly. More likely, it's using Monaco or some other font which doesn't have a full Unicode character set. Change the font to Ariel, and you'll see a lowercase a.

And the IDN system exists to allow internationalized URLs. Disabling Unicode characters in the address bar would mean that URLs would turn into gobbeldygook on non-English systems. That's not an acceptable solution.

I'm not against unicode or internationalization. All I want (and maybe didn't convey very well) is to see the cyrillic a as a cyrillic a in the url. I get email in foreign alphabets regularly and the body of text is in that foreign alphabet. Am I wrong but isn't that how unicode is supposed to work, english writing looks english, russian looks russian, etc.?

Oh, I didn't think you were against internationalization or localization. Sorry if my reply came off that way.

I think you misunderstand; a cyrillic a looks like, well, an a. If you have a Mac, go to the Edit menu and choose "Special Characters...". In the palette that pops up, choose "Unicode" from the View combo box. Then choose Cyrillic from the left-hand side select. About 5 rows down and one character from the right, you'll see the cyrillic lowercase a. It's virtually identical to the roman character, and at the 10 or 12 point size used in the address bar, there's no way you could tell the difference.