Slashdot Mirror
Shmoo Group Finds Exploit For non-IE Browsers
shut_up_man writes "Saw this on Boing Boing: East coast hacker con Shmoocon ended today and they had a nasty browser exploit to show off... using International Domain Name (IDN) character support to display fake domain names in links and the address bar. Their examples use Paypal (with SSL too) and this looks very useful for phishing attacks. Interesting note that it works in every browser *except* IE (which makes this exploit a lot less dangerous in the end, I suppose)."v The reason IE isn't vulnerable is because it doesn't natively support IDN; with the right plug-in, it too is vulnerable.
To disable IDN as a workaround for this problem (on Gecko-based browsers): hit about:config and set network.enableIDN to false.
How am I supposed to fit a pithy, relevant quote into 120 characters?
I'm surprised to hear that Microsoft's refusal to adopt international standards in their browser actually thwarts a potential phishing attack rather than aiding it. If the problem can't be fixed in the browsers, maybe email clients and websites can find some way of decoding, detecting, and disabling such links. Are phishers going to bother trying to use this exploit if it works on less than 10% of their potential victims?
You are in error. No-one is screaming. Thank you for your cooperation.
Serves those Internet Explorer users right! They should immediately switch to ... uh, wait. Nevermind.
I'm a big tall mofo.
This isn't per-se a browser fault, it is more of a flaw in the IDN system.
Atleast, we can bash FF instead of IE now.
Damnit... now I'm switching back.
This would actually appear to be a flaw in the Punycode standard rather than the browsers themselves, given that all IDN (internationalized domain name) aware browsers similarly fail.
Looks like someone may have to fix Punycode. Then we can update the browsers. In the mean time perhaps Opera, Firefox, etc. can given some kind of visual notification when Punycode is used, in the same way the URL turns yellow when a secure URL is entered in Firefox.
If you "View Source" for some weird reason the real address shows up in the title bar.
I have a theory that the truth is never told during the nine-to-five hours. - Hunter S. Thompson
I can remember discussions about it years ago. I'd bet there may even be a /. article about it, although its not really worth searching to see.
This was a big part of the critisism around supporting larger character sets in domain names.
From the text:
.. eventually.
VI. Vendor Responses
Verisign: No response yet.
Apple: No response yet.
Opera: They believe they have correctly implemented IDN, and will not be making any changes.
Mozilla: Working on finding a good long-term solution; provided clear workaround for disabling IDN.
So, Opera won't fix it? They have a proof of concept, and Opera believe their implementation is correct? Maybe, but they still need to provide an update, and something tells me they will
Ok, it doesn't work in IE... so when the patch will be released? I mean... it is IE, the exploits HAVE to work. Microsoft should be worried, they are not doing their job properly.
Seriously, it's been known for years that adding international character sets was going to cause the problem of multiple identical (or almost identical) characters.
On the other hand, no-one really seems sure of the best way to fix it... One option is obviously to mark somehow when non-ASCII characters are used, but while this will help the people who only want ASCII URLs, it will still leave the problem for everyone who wants to use this extended system, making it effectively useless....
Combination - fun iPhone puzzling
Except when implemented in their own country code namespace of course.
There are so many characters that look alike, that it is trivial to register a domain name that will look the same as another one. Typically the different character would only be recognised by a native that used that character, although using it alongside normal English characters would probably throw them off as well.
Solution? Maybe an "IDN" icon in the URL bar, or a warning if an IDN uses a mixture of normal English characters with some foreign characters in an IDN.
The 'fix' they mention (setting network.enableIDN to false via about:config) only works until you restart the browser - when you reopen the browser, things are back to the same even though the setting is still false..
It doesn't seem to work with Lynx, either. The URLs are obviously different from what they're supposed to be, and they don't point to any site at all.
Lynx does try the URL, though, so it may be possible to set up another domain to catch it, but the URL would still be obviously wrong (something like p%a%y%p%a%l.com)
One man's -1 Flamebait is another man's +5 Funny.
-------
Warning: Slashdot may contain traces of nuts.
If i copy /paste the link into notepad it just looks right And if i copuy /past it back to firefox i get the "spoofed" page back again.
next:
Trolls can have a couple of days fun on slashdot.
And verisign van sell a lot of domains to phishers. (profit!)
Comments like this worry me. We really have to be careful about letting our guard down just because Firefox is more secure. The whole point of the article is that the exploits DO exist.
/. community) love to talk about how Firefox's market share is growing quickly but then minimize potential problems. So how is this problem 'less dangerous than some IE exploits'?
On one hand, we (the
Don't get me wrong, I'm all about Firefox, but we can't get lazy.
This brings up the amusing problem of character recognition by human and non-human intelligences. Douglas Hofstadter discusses this issue in on seeing A's and seeing As.
In the case of this exploit, a deep flaw in IDN and computer fonts means that character #1072 is rendered typographically as an "a". The irony is that this is one of the few cases in which a computer can readily tell the difference between "a" and #1072 and a person cannot. The only solution would be rules that prohibit isomorphic characters in typefaces or a in-browser warning system that analyses the potential for ambiguity and alerts the user.
Two wrongs don't make a right, but three lefts do.
This will probably lose me major karma for going against groupthink, but the statement that "The reason IE isn't vulnerable is because it doesn't natively support IDN; with the right plug-in, it too is vulnerable." does seem ridiculously biased.
While it may be technically true, it's like suggesting Firefox is susceptible to IE's infamous ActiveX vulnerabilities, just because there's an ActiveX plugin for Firefox too. Everyone is quick to jump on MS when there's new IE exploits, but we've got to accept that this seems to be one they got right. Making excuses about plugins doesn't really change that.
Here in Scandinavia, the letters Å,Æ,Ø, are actually quite new. It is acceptable to spell them as AA, AE and OE respectively on non-scandinavian keyboards. With IDN adresses now becomming available, you constantly have to remember which spelling is used on which website. It would be a hell of a lot more practical if only the 26 alphabeth was used and software would automatically expand ingeniøren.dk to ingenioeren.dk. This way you could use whatever you want. And websites will not be too happy about using special characters, because it makes them almost impossible to reach on non-scandinavian computers.
10 ?"Hello World" life was simple then
IE wasn't relevant to this article, yet you found a way to wedge it in and smear it regardless.
What about to the people who have the plugin for IDN? This is a place for geeks, and there are bound to be people that have that sort of plugin. Saying IE isn't affected is pretty much false in that light.
Do tell me how am I going to have to type in a Chinese or Japanese domain name if I don't have keyboard layout (not to mention that I amy not even know *how* to input all these gliphs...).
Do tell me when you became the world. Just because you personally likely won't use a feature doesn't mean it isn't useful for someone out there (what's the population of China and Japan combined?)
Je ne parle pas francais.
I'm planning on taking an airplane flight in 7 years, and am already taking classes on aeronautics, history of flight, airplane engineering, and am enrolled in the technical school for airplane building and maintenancy.^H^H
.5 ohm resistor, with a diode overlay. I'll do that as soon as I'm done casting the waterpump for my car.
Uh-oh, looks like my "delete" key stopped working again. Must need another
If you don't know what AltaVista is (was), get off my lawn.
>The reason IE isn't vulnerable is because it doesn't natively support IDN; with the right plug-in, it too is vulnerable.
Well, if we're going to disregard them on those grounds, we might as well disregard ActiveX exploits too (since FireFox doesn't support it). An exploit is an exploit. Don't play the game of justification.
p.s. I use Firefox.
Although not a Linux, Windows, or Mac vulnerability, it could become one.
If the site spoofed were a trusted site for firefox extensions they could get some code to execute on the box. They could package a root kit and take control of a Linux or Mac, or the Buffer overflow du jour to take control of a Windows machine. Granted the Linux would be the most difficult due the the large variation of distros (and each distro differs on opinion where file belong), compiler options, etc.
For a truly secure OS, you should remove all applications and just run the OS in its pure state.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
There is already a fix for this IDN problem in the unicode spec, if people would just use it:
Before resolving, all domain names should be normalized according to normalization form KC. (see http://www.unicode.org/unicode/reports/tr15/) Once that's done, anything that looks like an "a" really will be an "a", and not something that looks identical in Cyrillic.
That simple (SIMPLE!) step would avoid this problem, almost completely. There'd still be an issue with people using "paypál" instead of "paypal", but at least then the user has some vague chance of seeing the difference in the URL in the browser window.
It would also be good if responsible registrars refused to accept domain registrations for domains not normalized according to NFKC, but asking companies to refuse business simply because someone else would get hurt is probably not going to be effective.
Why don't you just start typing in your URIs from now on?
Where "sees" means "displays it this way on the status line":
:)
Netscape 3.04 sees http://www.p?ypal.com/ -- looks the same in docsource
OffByOne 3.4a sees http://www.p0ypal.com/ -- looks the same in docsource
K-Meleon 0.9 sees http://www.p?ypal.com/ -- looks like http://www.pypal.com/ in docsource
IE 5.00.2314.1003 (yes, minor builds can make a *big* difference in how IE displays stuff) sees it as http://www.paypal.com/, but the "a" is about half normal size (this is at 1024x768). Docsource as IE feeds it to notepad looks like http://www.pypal.com/
Mozilla 1.5 sees it exactly the same as IE5.00 (above), including docsource
AOLpress (HTML editor with built-in browser) sees it exactly the same as OffByOne (above), including docsource
Netscape 4.50 sees http://www.p?ypal.com/ but displays http://www.pypal.com/ in docsource
Firebird 0.7 sees it exactly the same as Moz 1.5 and IE5.00 (above), including docsource
And Mosaic 0.9 can't figure out WHAT to do with the page and wants to save it to disk.
At this point, I ran out of installed browsers.
~REZ~ #43301. Who'd fake being me anyway?