homepage Welcome to WebmasterWorld Guest from 54.237.125.89
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / WebmasterWorld / Webmaster General
Forum Library, Charter, Moderators: phranque & physics

Webmaster General Forum

    
spoofing advisory on domain "simulation"
international domains (IDN) fool visual inspection
amznVibe




msg:346744
 12:35 pm on Feb 7, 2005 (gmt 0)

This could become very serious for novices,
apparently international domains (IDN) can be
used to fool initial visual inspection:
demonstration: (I have no association with this site)
[shmoo.com ]
Look very carefully at the first "a" in paypal in that demonstration.

In theory this can be blocked at least in Firefox by turning off international domain support (IDN) as a temporary workaround:
type about:config in your address bar
search for network.enableIDN
click on it to set it to FALSE
IDN support should then be disabled

[edited by: trillianjedi at 6:00 pm (utc) on Feb. 7, 2005]
[edit reason] Fixing boldening [/edit]

 

Sanenet




msg:346745
 12:54 pm on Feb 7, 2005 (gmt 0)

This works in everything except IE

Who's laughing now? :)

Seriously tho', I can see this becoming a major issue once these lowlifes phishers get hold of it. Should be interesting to watch!

amznVibe




msg:346746
 1:13 pm on Feb 7, 2005 (gmt 0)

You missed the part where there are serveral plugins for IE being pushed by Verisign (Network Solutions) and others to enable IDN. This "feature" could easily be triggered by activex. Any person worldwide who visits non-english domains probably has this plugin installed already. It won't show up on any list of bad plugins or spyware - because it has positive uses too.

By the way, mac users are the most vulnerable (for a change) because of Safari's IDN support.

Sanenet




msg:346747
 1:43 pm on Feb 7, 2005 (gmt 0)

That I did. Even so, I'd like to know just how many IE users have that plugin installed - in my own experience, I've only come across a couple of IDN domains, all of them Arabic.
I was looking through verisigns site for anything about IDN plugin usage, but couldn't find any market research from later than 2003. ( [verisign.com...] ). This study concluded that "The primary reason for purchasing IDNs is for protection" and that "they are less likely to have a site or email associated with them".

I find it suspicious that there's nothing more recent about them - strikes me the results weren't good enough for them to publish.

amznVibe




msg:346748
 1:48 pm on Feb 7, 2005 (gmt 0)

The German domain name market is actually bigger than any other country and they use IDN. So do the French, etc.

It's simply not popular in english speaking countries because you need a special keyboard to be able to enter the special characters (in a quick manner).

examples of IDN domain names [i-dns.net]

Sanenet




msg:346749
 2:11 pm on Feb 7, 2005 (gmt 0)

Yes, I see that the germans have just extended their support for IDN in the .org domain "due to public demand". And that the Chinese gov is pushing for more chinese IDN support.

I see that up to 8% of all registered domains are IDN, which is we take 66.8M TLDs as being currently registered gives us aprox 5,344,000 IDN TLDs worldwide.

Added: According to Verisign, the IDN plugin for IE autochecks for updates every 24 hours. So if they fix this hole they should be able to fix all vul versions of IE pretty quickly.

grelmar




msg:346750
 3:00 pm on Feb 7, 2005 (gmt 0)

I'm not sure if the Verisign patch will be effective. It would be trivial to combine this with another year old known vuln in IE/Outlook:

<a href="http://www.microsoft.com/"><table><tr><td><a
href="http://www.google.com/">http://www.microsoft.com</td></tr></table></a>

Try it then run you mouse over the link using IE. When you mouseover the link, it should even show MS in the status bar. (NB: IE is is the only browser vulnerable to this form of link spoof. Outlook is the only email client vulnerable. This vulnerbaility was first noticed almost a year ago.)

Combine that with this, so the user is sent to the IDN which 301 redirects, and you have a heck of a whammy.

encyclo




msg:346751
 3:08 pm on Feb 7, 2005 (gmt 0)

One surprising part of the story is the attitude of Opera Software, who consider that their implementation of IDNs is correct and so they have declined to make any changes. With such an inadequate response, perhaps Wells Fargo [webmasterworld.com] are right after all?

Dynamoo




msg:346752
 3:27 pm on Feb 7, 2005 (gmt 0)

Who's laughing now? :)

Yeah, but the score is still:

Internet Explorer: 2
Mozilla-Firefox United: 876

or something ;)

However, part of the problem with phishing isn't just browsers, it's often email clients. Eudora 6.2 comes with a built-in antiphishing tool called ScamWatch which compares the "displayed" URL with the "actual" URL and warns you if it's deceptive. It's a useful tool, and hardly rocket science. How it would cope with Unicode URLs I don't know though.

Receptional




msg:346753
 3:30 pm on Feb 7, 2005 (gmt 0)

Thanks very much for sharing this amznVibe. Only this morning I received a clear phishing email with an apparent link to paypal.com and I didn't have a clue how they had done it. I didn't actually click on the link, but if I had I would have opened it in Firefox and been none the wiser if I had been unwary.

bcolflesh




msg:346754
 3:34 pm on Feb 7, 2005 (gmt 0)

It would be trivial to combine this with another year old known vuln in IE/Outlook:

This was patched by the vendor in August 2004:

[support.microsoft.com...]

encyclo




msg:346755
 4:34 pm on Feb 7, 2005 (gmt 0)

A note to those implementing the Firefox workaround: it doesn't work. When you first set
network.enableIDN to false, IDNs are disabled - but once you restart the browser the value remains false but the IDNs work again. So, we have a bug compounded by another bug, and a false sense of security brought about by a broken workaround.
amznVibe




msg:346756
 5:25 pm on Feb 7, 2005 (gmt 0)

I am not so sure that is correct.
I think IDN LOOKUPS are disabled when you set to false.
If it's in your dns cache already it will still work.

Here's a possible workaround to make it change the setting on startup everytime:
put this into user.js (using the chrome edit extension)
user_pref("network.enableIDN", false);

Really I think Firefox should change the address area's color when an IDN is present and I would bet an extension for that will be out within 48 hours.

An MSDN blog on the issue:
[blogs.msdn.com...]

ICANN's notes on the issue:
[icann.org...]

URL punycode explained at wikipedia:
[en.wikipedia.org...]

grelmar




msg:346757
 6:14 pm on Feb 7, 2005 (gmt 0)

This was patched by the vendor in August 2004:

[support.microsoft.com...]

Oh really? I have that patch, and it's about 50/50 effective.

To me, that means the vuln is unpatched.

Teknorat




msg:346758
 10:09 pm on Feb 7, 2005 (gmt 0)

Hmmm *makes paypal spoof site*

So how long before we see a patch for Firefox?

Bluesplinter




msg:346759
 10:40 pm on Feb 7, 2005 (gmt 0)

I checked out the Firefox support forums, and the nightly builds already have this fixed... it just hasn't made it out to the "stable release" area yet.

amznVibe




msg:346760
 6:10 am on Feb 8, 2005 (gmt 0)

A temporary workaround that "sticks" on Firefox has been posted:

you need to edit to your compreg.dat
For windows
c:\Documents and Settings\$USER\Application Data\Mozilla\Firefox\Profiles\default.random\compreg.dat
For UNIX
~/.mozilla/firefox/default.random/compreg.dat

Open this file with a text editor which understands the line endings in it, such as Wordpad (or your favourite text editor on other platforms), and comment out all lines containing IDN by adding # at the start of the line. For example:

# {4byteshex-2byteshex-2byteshex-2byteshex-6byteshex},@mozilla.org/network/idn-service;1,,nsIDNService,rel:libnecko.so

Note that you will have to repeat this edit if you install any themes or extensions, as compreg.dat gets regenerated.


stormy




msg:346761
 11:52 am on Feb 8, 2005 (gmt 0)

Correct me if I am wrong, but: doesn't any website that uses Paypal for payments become a potential threat now? All of them require you to click on a link to make payment... :-(

too much information




msg:346762
 1:00 pm on Feb 8, 2005 (gmt 0)

Well it's not just PayPal, it's any link.

Looks like I'm going to start checking the 'view source' on a page before hitting a link to submit a payment.

amznVibe




msg:346763
 9:25 am on Feb 9, 2005 (gmt 0)

24 hours to patches and extensions to deal with the problem.
Gotta love Firefox. Anyone can have a bug but how long until its fixed?

For those that need to keep IDN support working, try using the the firefox spoofstick extension
[corestreet.com...]
which has now been updated to highlight domains with extended ascii (IDN) characters:
[jarnot.com...]

ps. don't forget to visit windowsupdate today for your 13 patches to deal with issues months old

xxxxxpp




msg:346764
 2:53 pm on Feb 10, 2005 (gmt 0)

Who's laughing now? :)

It isn't that IE's implementation is not vulnerable, it's just that the vulnerability is in a feature that IE doesn't even support

One surprising part of the story is the attitude of Opera Software, who consider that their implementation of IDNs is correct and so they have declined to make any changes. With such an inadequate response, perhaps Wells Fargo are right after all?

Well, their response may be tonedeaf, but it's not "inadequate". The problem isn't in Opera's implementation of IDN (or Mozilla's), but in the IDN spec itself.

Xuefer




msg:346765
 4:18 am on Feb 14, 2005 (gmt 0)


It isn't that IE's implementation is not vulnerable, it's just that the vulnerability is in a feature that IE doesn't even support

how about activex?
can we just say: It isn't that Firefox/Opera's implementation is not vulnerable, it's that Firefox/Opera don't even support activex feature.

just joking :)

pmkpmk




msg:346766
 9:59 am on Feb 15, 2005 (gmt 0)

News update for Firefox:

So, in the mean time, the enableIDN preference will be set to "false" in Firefox 1.0.1 and Mozilla 1.8 beta, including all official localisations. An XPI will be made available to turn it on again; this XPI will make the risks of doing so clear. This means that by default, links to IDN domains which use the Unicode rather than the punycode form for the href will fail, and the browser will display any IDN domain visited in its raw form.

[weblogs.mozillazine.org...]

Sanenet




msg:346767
 9:00 am on Mar 5, 2005 (gmt 0)

Firefox fixes this flaw with one heck of a fudge:

[edition.cnn.com...]

Firefox 1.0.1, released last week, shows Web addresses with foreign scripts in code, preceded by the letters "xn." So "paypal.com" with a Cyrillic "a" becomes "xn--pypal-4ve.com."

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / WebmasterWorld / Webmaster General
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved