Broadband Tech > Security > Security > The state of homograph attacks

The state of homograph attacks

quote:

---

The state of homograph attacks

I. Background

International Domain Name [IDN] support in modern browsers allows attackers to
spoof domain name URLs + SSL certs.

II. Description

In December 2001, a paper was released describing Homograph attacks [1]. 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) [2]. RACES has been replaced with PUNYCODE [3]. Every recent
gecko/khtml based browser implements IDN (which is just about every browser
[4]
except for IE; plug-in are available [5]).

III. The details

Proof of concept URL:

»www.shmoo.com/idn/

Clicking on any of the two links in the above webpage using anything but IE
should result in a spoofed paypal.com webpage.

The links are directed at "http://www.pаypal.com/", which the browsers
punycode handlers render as www.xn--pypal-4ve.com.

This is one example URL - - there are now many ways to display any domain name
on a browser, as there are a huge number of codepages/scripts which look very
similar to latin charsets.

Phishing attacks are the largest growing class of attacks on the internet
today. I find it amusing that one of the large early adopters of IDN offer an
'Anti-Phishing Solution' [6].

Finally, as a business trying to protect their identity, IDN makes their life
very difficult. It is expected there will be many domain name related
conflicts related to IDN.

Vulnerable browsers include (but are not limited to):

Most mozilla-based browsers (Firefox 1.0, Camino .8.5, Mozilla 1.6, etc)
Safari 1.2.5
Opera 7.54
Omniweb 5

Other comment:

There are some inconsistencies with how the browsers match the host name
with the Common Name (CN) in the SSL cert. Most browsers seem to match the
punycode encoded hostname with the CN, yet a few (try to) match the raw UTF8
with the CN. In practice, this makes it impossible to provide 'SSL' services
effectively, ignoring the fact that IE doesn't yet support them.

IV. Detection

There are a few methods to detect that you are under a spoof attack. One
easy
method is to cut & paste the url you are accessing into notepad or some other
tool (under OSX, paste into a terminal window) which will allow you to view
what character set/pagecode the string is in. You can also view the details
of
the SSL cert, to see if it's using a punycode wrapped version of the domain
(starting with the string 'xn-'.

V. Workaround

You can disable IDN support in mozilla products by setting 'network.enableIDN'
to false. There is no workaround known for Opera or Safari.

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.

VII. Timeline

2002 - Original paper published on homograph attacks
2002-2005 - Verisign pushes IDN, and browsers start adding support for it
Jan 19, 2005 - Vendors notified of vulnerability
Feb 6, 2005 - Public disclosure @shmoocon 2005

VIII. Copyright

This paper is copyright 2005, Eric Johanson ericj@shmoo.com

Assistance provided by:
- The Shmoo Group
- The Ghetto Hackers

Thank you, you know who you are.

References:

[1] »www.cs.technion.ac.il/~gabr/pape···aph.html
[2] »www.verisign.com/products-servic···dex.html
[3] »mct.verisign-grs.com/index.shtml
[4] »www.verisign.com/products-servic···01000002
[5] »www.idnnow.com/index.jsp
[6] »www.verisign.com/verisign-busine···lutions/

---

Thanks for the information. I just set my Firefox browser for network.enableIDN = false.

reply to BeesTea
Thanks, BeesTea .

I've set the IDN value to false in Firefox as per the workaround and then confirmed the difference at the shmoo.com proof of concept page.

It's such an easy modification to make (in about:config or user.js) that it seems to me that anyone using a Mozilla browser would want to make sure to implement the change. Hopefully a fix (as opposed to a workaround) will be implemented in future released of the different Mozilla browsers.

Viewed the demo page -- the funky "a" was clearly visible when hovering over the URL. I would never click on that.

Eternal vigilance is the price of liberty, or something like that?

I'm not sure if that default should be changed or not.

The one thing tipping the scales is Verisign's support. If they're for it, it's almost assuredly a bad thing.

-- B
--
In a realm outside causality and function

from
»it.slashdot.org/article.pl?sid=0···from=rss
"..
To disable IDN as a workaround for this problem (on Gecko-based browsers): hit about:config and set network.enableIDN to false.

That is a great suggestion, except for the part where it does not work.

Go ahead, make the change, then restart your browser. Now go look at about:config again. Yup, still set to false. Now go see if it the setting worked. It does not. So at least with Firefox 1.0 just took a bad situation and made it worse. Now people will think turning off this setting will actually accompolish something and protect them and it will not. .."

edit: also
»forums.mozillazine.org/viewtopic···t=214914

Cudni

For what it's worth, same failure in Mozilla (the real one) 1.7.2. Definitely a problem in the main tree.

-- B
--
In a realm outside causality and function

reply to BeesTea
Ironic that it was the fact that IE once again didn't embrace a standard that got them off the hook on this one. Funny how that works.

By the way, for you Firefox users, go to:

about:config

But it doesn't work!

Has disabling it worked for anyone here?

-- B
--
In a realm outside causality and function

acehyde says it worked for him
edit: (now confirmed it did not work)
»/. has an article about Phishing exploit w/Firefox

edit: the only time i can make exploit fails is if i make config change everytime i start FF

Cudni

Re: fix breaks on browser restart

I only hope this is isolated and doesn't apply to OTHER configuration options kept in the PREFS.JS, boolean or not.

-- B
--
In a realm outside causality and function

Mozilla forum, bug links

reply to BeesTea

Re: The state of homograph attacks

reply to BeesTea
The preference does not revert for me, even after restarting Firefox:
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

So I use Slackware. Slackware 10.1 was released today, and in getting ready to upgrade my installation I was comparing the packages I've installed with the list of all available Slackware packages. Along the way, and as a result of this thread, I happened to notice that there is a separate Slackware package for IDN. I've never had that package installed, and I don't know if that makes any difference for setting the preference in Firefox. I don't suppose it would, but I don't know, either.

In any case, I don't lose the IDN setting after restarting Firefox.

But do you lose the BEHAVIOR?

None of us are losing the setting -- in about:config and PREFS.JS the setting stays "false", but the EFFECT is gone after restarting the browser.

Without IDN enabled I doubt you see a difference to begin with?

-- B
--
In a realm outside causality and function

reply to BeesTea
I get page not found, in FF and in MSIE 6 sp2.

reply to B
Oh, duh. Yes, I do lose the behavior. Also true if I change the preference with user.js rather than in about:config.

Okay, I thought that without the IDN package you mentioned the exploit wouldn't change at all. (Which is apparently true in part, since the "a" is not rendered properly but might be if you were to install the package.)

-- B
--
In a realm outside causality and function

So it seems that there was no IDN library package in Slackware 10.0. This appears to be a new addition in today's 10.1 release. Interesting to encounter this international domain names issue in two apparently unrelated contexts...

Anyway, even if the workaround were working, it still seems important to verify URLs before entering financial information and so on. It's not as though any technology can prevent a person from falling for the social engineering tactic du jour...