Bug 99358

Version:            (using KDE KDE 3.3.2)
Installed from:    SuSE RPMs
OS:                Linux

Copy from: http://www.shmoo.com/idn/homograph.txt

The state of homograph attacks				Rev 1.1


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-ins are available [5]).

III.	The details

Proof of concept URL:

http://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.

All about ssl:   'domain validated' ssl certs do not prove the identity
of the requesting party.  They simply validate who has control of receiving
email at that domain (which includes IDN).  I suspect if I tried to purchase a
higher-end cert for this demo, I would have been stopped right around step 2.
Some folks don't like domain validated certs - - I for one, love them, as they
keep my accountant happy. 

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
Some bazar versions of IE, or any version of IE with the I-nav plugin. 

Several RFCs talk about some basic security measures which can be done to
assist with preventing phishing attacks on IDN-supported browsers.  While I
believe these measures are insufficient or impractical in some cases, they got
completely ignored regardless.  Go read them.

http://www.faqs.org/rfcs/rfc3490.html
http://www.faqs.org/rfcs/rfc3491.html
http://www.faqs.org/rfcs/rfc3492.html


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.

Update:  The basis for this inconsistent behavior seems to be due to the fact
that it's not specified in any published RFC.  I'm assured that some RFC, due
any decade now, will clarify this issue.   I believe the correct method for
matching the CN with the HN+DN is to use the punycode version of the HN+DN.

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 (see community
response for additional tools for Safari).

Update:  There are some bugs related to keeping the state of "enableIDN" in
many versions of firefox.   This has been fixed in the latest nightly build.
Alternatively, you can use one of the methods listed here:

http://users.tns.net/~skingery/weblog/2005/02/permanent-fix-for-shmoo-group-exploit.html

(so please stop emailing me for tech support! :) 

VI.	Vendor Responses

Verisign: Got an email from I-nav lead  - - more on this later.

Apple:  No response yet. (Let me clarify - they did send me an email 
informing me of their public disclosure policy, which was not very helpful)

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.

Geotrust:  (this is who I purchased the ssl cert from, purely based on cost) 

I have to give these guys props.  Not only did they dig up my number can call 
me, it was the _not_ the legal department. Anyway, I'm told that they now have 
a manual filter in place to review all IDN-related cert requests.   They are 
considering outright blocking of all IDN certs.  I consider their response 
to be what I expect from a vendor - - prompt, respectful, responsive, and
helpful. Maybe some of their behavior will get leaked into the other vendors
out there. 

VII.    Community Responses

The community response has been much larger than expected.  Promptly after the
public diclosure of this advisory, several tools showed up on the market to
assist with detection of IDN spoofing attacks.   Some of those are listed
below:

Disable IDN support in firefox, for good:
http://friedfish.homeip.net/extensions/no-idn.xpi

Trustbar for firefox - shows punycoded IDN, and allows for better SSL management
http://trustBar.mozdev.org

Safari IDN spoofing defense:
http://bob.pythonmac.org/archives/2005/02/07/idn-spoofing-defense-for-safari/



VIII.	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
Feb 11, 2005 - Update to advisory

IX.	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] http://www.cs.technion.ac.il/~gabr/papers/homograph.html
[2] http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/index.html
[3] http://mct.verisign-grs.com/index.shtml
[4] http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/page_002201.html#01000002
[5] http://www.idnnow.com/index.jsp
[6] http://www.verisign.com/verisign-business-solutions/anti-phishing-solutions/