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?
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
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
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..
"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?
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.
Actually, they didn't find anything. They demonstrated how the IDN character support could be used to trick users. A virtually identical demonstration can be found in the original paper/advisory. Thanks for the FUD, slashdot editors.
Furthermore, whether this is actually an exploit or not remains a subject of debate, as is evident from Opera's response ("It's implemented properly"). Fact remains that people can be fooled, though.
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.
You're right - the example from a couple of years ago was using www.microsoft.com but with the Os in microsoft being a russian character that is drawn identically.
I can't be arsed to search for it either.
Justin.
You're only jealous cos the little penguins are talking to me.
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
Incidentally, it seems that Slashdot's ASCII-only URL reporting system successfully deflects such spoofing here: Go to paypal.com
four nine eighteen twenty-7 thirty-nine forty-7 fiftyeight sixty-nine seventy-9 eighty-8 one-hundred-and-nine one-twenty
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.
The short answer is no. If you start taking away this feature from browser, non-Latin named domain owners will complain (yes, they do exist). The Unicode problem has more to do with the fact that many browsers only check for canonical equivalents for Latin-based code points, not Russian, Chinese, or any other languages. And yet, canonical equivalents for these characters have existed in Unicode standard for a long time. Grapheme cluster equivalence though, is very tricky to implement, which may never be implemented in most software, not just browsers.
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)
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
The problem is that the browsers are rendering the address correctly.
The HTML entity а != U+1072. It corresponds to U+0430 CYRILLIC SMALL LETTER A, which it seems most fonts render almost exactly identical to U+0061 LATIN SMALL LETTER A.
It appears the problem is in RFC3491 "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)" or RFC3292 "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)". As I understand it, one of the processes these RFCs describe involve a sanitisation process to be carried out on domain names, that fixes cases where an attacker is using odd unicode control characters to make one character appear like another.
The problem is that these procedures overlooked U+0430 CYRILLIC SMALL LETTER A (and perhaps others?).
So I suggest flagging the address field with a red tint when such characters are discovered as a work around, until the clever people who write RFCs come up with a good idea of how to proceed.
More info on this blog, if you are interested.
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