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 reason IE isn't vulnerable is because it doesn't natively support IDN; with the right plug-in, it too is vulnerable.
IE wasn't relevant to this article, yet you found a way to wedge it in and smear it regardless.
The browsers the exploit WAS found for weren't even mentioned by name, yet IE was.
How is this anything except nasty propaganda?
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.
The reason IE isn't vulnerable is because it doesn't natively support IDN; with the right plug-in, it too is vulnerable.
IE is safer because it doesn't support a feature? Don't worry, I'm sure the plug-in will be installed with the next security update!
Taking guns away from the 99% gives the 1% 100% of the power.
"Propaganda" being anything someone says that you do not like. Mentioning IE is quite relevant. My first thought on reading such a thing is its status in regards to MSIE. Also, in case you have not heard before, MSIE has a reputation for being subject to such exploits in the past.
Don't blame Durga. I voted for Centauri.
I've confirmed that konqueror is vulnerable. Anyone know how to disable this in konqueror?
If you had super powers, would you use them for good, or for awesome?
I thought this was a well-known attack -- using Unicode characters that look like latin but aren't. As more and more web sites start accepting unicode in user names without policing, I think we'll find more interesting applications for this type of attack.
This is not that different from "spoofing" using this address:
http://www.paypaI.com I.e. replacing the lower-case L with an upper-case i. (except that paypai.com appens to be taken already, by an annoying site that maximizes the browser window no less.)
Security through inutility
Links is unaffected - it goes to the real paypal site.
-------
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!)
This can apply to any time anyone says anything. However, in practice, the word "propaganda" is only used when someone does not like being said. It is similar to "rhetoric" in this regard.
Don't blame Durga. I voted for Centauri.
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....
I think you're on the right track here.
Perhaps the best approach is to use a different font/different color for particular ranges of characters, or characters outside of one's locale setting, so e.g. if my local is Germany, and cyrillic or french accent-grave or what have you characters are loaded, then display that character in bold, or in red, or what have you. Also, tint the background of the URL pink or something, so if the offending character is scrolled off the end of the URL field, the user still gets a visual clue that something is wrong.
I'm sure there are other possibilities, like putting a little warning at the top whenever characters are in the URL that are strikingly similiar to characters in the default local OR standard ASCII, specifying what the character is and perhaps stating something like "http://spo0furl.com IS NOT THE SAME as http://spoofurl.com".
The Future of Human Evolution: Autonomy
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.
Maybe one language is a little bit overkill. How about limiting it to one char. set?
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.
It's intentional that there are multiple glyphs that look the same, but represent different characters in Unicode. (for sorting order, spell checking, etc.)
... the different sets assigned to each language or function).
So you just need to work off of that strength, and flag when someone's mixed any two groups of characters. (I'm not sure what the official Unicode name is for them
Anyway, you start with the assumption that a domain name is going to contain only characters from one of those groups, and you report if it's otherwise. Now, there are still problems with people not looking closely, and confusing 'resume.com' with 'résumé.com' or something similar, but you'll fix the problems with identical glyphs.
The important thing to do is to not assume that ASCII is the only 'good' form, as that would make it rather english-centric (I'm not sure what other languages can map all of their characters into ASCII)
Build it, and they will come^Hplain.
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
Spoofstick is a useful tool, too. I don't know if it protects against this particular attack, but it's good for the casual browser (i.e., mom/aunt gert/the cranky old guy down the street who always asks for computer help) to help protect against phishing.
No, you see, you are missing the point. The IDN system is flawed, not any particular browser.
By making browsers an issue in the headline, there could be an immense amount of spin generated from this, where there didn't need to be any. Anybody who reads only the headline will thing an entirely different thing from someone who actually reads the comments and gets a perspective.
To give an example of this that swings the other way, do you remember that announcement of the SP2 vulnerability in the stack overflow checking or something like that, that happened a week-or-so ago? And then Microsoft later said that no exploits have been found for it? That's the kind of thing that this headline can induce, because there is no perspective.
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.e.
Doesn't work so well now, does it?
This fact (IMHO) is more dangerous than not being able to make the setting at all. At least with Safari (et al) I know that I always have to be vigilant, instead of being lulled into a false sense of security.
Clearly, Firefox has a major BUG in it. Fortunately, they seem to be pretty quick to fix these sort of things.
"terrorism" and "pedophilia" are the root passwords to the Constitution
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
Has anyone checked to see if this exploit is possible in the recent 1.0.1 builds? Presumably they contain security fixes... perhaps for this issue among whatever others exist.
This seems to be more of a bug in Unicode than in the browsers. Unicode has defined multiple character codes as having the exact same glyph. I thought we'd already run into this in Unicode with multiple long representations of the same character, decided it was a bad thing and corrected it by making any representation longer than the shortest illegal. Shouldn't we do the same thing here, and simply make it illegal to have multiple character codes appearing as the same glyph?
Can anyone please tell me why people "hack" or "phish" or anything that is used for malicious activity? I'm not trying to start an argument, I seriously want to know why some people spend so much time trying to make others lives miserable.
Money.
Think for a minute why it would be beneficial to the bad guys to have people logging into their site with valid PayPal usernames and passwords.
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?
Slashdot has covered this problem before.
This sig is umop apisdn.
This is strongly dependent on both the language and OS in question. For example, Japanese input methods work very well on US keyboards; you key in romaji, and the input method converts it to hirigana or katakana on the fly. When you hit space, a menu of kanji with the given reading is presented. Space again picks the first one, or cursor up/down before hitting space to pick another.
This is apparently a quite common input method, as a Japanese friend who had never used a Mac told me how to use OS X's input method.
The dead keys on Mac OS for Western European languages are also quite easy to get used to. (The AltGr thing on X11 I'm not so fond of.)
But, of course, most Scandinavian users (referring to the grandparent post) will have Scandinavian keyboards, and they aren't entering foreign language sites, they're going to sites in their native languages.
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?
(dated feb 2002)
... it's an authentication problem
This problem is not a software bug. Sort of disabling the feature, I don't see a way of fixing the problem in the client software. I mean, I don't see a software patch (or even a standards modification) fixing the problem.
What it is, is a problem exacerbated complexity. People speak different langauges around the world, often multiple langauges. That rules out an ASCII-centric solution. Even rewriting the standards wouldn't help; the problem boils down to protecting people from tmemselves, or at least human cognition flaws.
Any solution would have to be a process solution. Specifically, the process determining that you are who you say you are. The current process for doing this is flawed for the average person. Your average person is just going to click through warnings which he or she doesn't understand.
As I see it, it is not a bug. International Domain Names are a standatd sind a while, already. The only problem is that some unicode characters look exactly like some UTF-8 characters and because of that, people can be "cheated".
But who needs IDNs??
In Mozilla/Firefox and maybe also in Thunderbird (if you download the about:config extension) IDNs can be disabled by using the about:config thingie.
Open your Gecko based brwoser and type "about:config" (without the quotes) and hit return. Search for "network.enableIDN" (without the quotes) and set it to "false" (without the quotes).
--
Max
When you go to a secure page Firefox highlights the URL yellow.
When you go to a page with anything but ordinary ASCII characters perhaps it could highlight the URL blue, or red, or something...
455fe10422ca29c4933f95052b792ab2
LiveHeaders on FF correctly reports that the HOST is not paypal.com
Looks like I'll have to use that to double check now. Still safer that IE.
Generally, these are tools (run as a regular user) to gain root access by exploiting things on the local box that are not accessible via the network. Espicially programs running with the suid bit (cron anyone?)
If you run linux you will normally see many frequent security patches to protect *local* programs from just such exploits.
----- If communism is a system where the government owns business, what do you call a system where business owns govern