Date: Tue, 8 Feb 2005 11:06:17 -0500
From: "Scovetta, Michael V" <Michael.Scovetta@...com>
To: "Brandon Kovacs" <liljoker771@...il.com>,
	<bugtraq@...urityfocus.com>
Subject: RE: International Domain Name [IDN] - browser-level fix (not network.enableIDN)


Brandon,

A few notes:
1. The 'network.enableIDN' appears to only work in the first browser
session after you set it. Set it, close your browser, open it again, and
try the POC. (At least, this was the case for me on Firefox 1.0).

2. Here's a browser-level fix (for any browser supporting proxy.pac
(most, if not all majors):

Add this to a text file called proxy.pac, and set that to be the
auto-configuration file:

function FindProxyForURL(url, host){
	var newhost = '';
	for (i=0; i<host.length; i++) {
	  if (host[i] == 'a') newhost += 'a';
	  if (host[i] == 'b') newhost += 'b';
	  if (host[i] == 'c') newhost += 'c';
	  if (host[i] == 'd') newhost += 'd';
	  if (host[i] == 'e') newhost += 'e';
	  if (host[i] == 'f') newhost += 'f';
	  if (host[i] == 'g') newhost += 'g';
	  if (host[i] == 'h') newhost += 'h';
	  if (host[i] == 'i') newhost += 'i';
	  if (host[i] == 'j') newhost += 'j';
	  if (host[i] == 'k') newhost += 'k';
	  if (host[i] == 'l') newhost += 'l';
	  if (host[i] == 'm') newhost += 'm';
	  if (host[i] == 'n') newhost += 'n';
	  if (host[i] == 'o') newhost += 'o';
	  if (host[i] == 'p') newhost += 'p';
	  if (host[i] == 'q') newhost += 'q';
	  if (host[i] == 'r') newhost += 'r';
	  if (host[i] == 's') newhost += 's';
	  if (host[i] == 't') newhost += 't';
	  if (host[i] == 'u') newhost += 'u';
	  if (host[i] == 'v') newhost += 'v';
	  if (host[i] == 'w') newhost += 'w';
	  if (host[i] == 'x') newhost += 'x';
	  if (host[i] == 'y') newhost += 'y';
	  if (host[i] == 'z') newhost += 'z';
	  if (host[i] == '.') newhost += '.';
	  if (host[i] == '1') newhost += '1';
	  if (host[i] == '2') newhost += '2';
	  if (host[i] == '3') newhost += '3';
	  if (host[i] == '4') newhost += '4';
	  if (host[i] == '5') newhost += '5';
	  if (host[i] == '6') newhost += '6';
	  if (host[i] == '7') newhost += '7';
	  if (host[i] == '8') newhost += '8';
	  if (host[i] == '9') newhost += '9';
	  if (host[i] == '0') newhost += '0';
	  if (host[i] == '-') newhost += '-';
	}
  	if (newhost != host ||
          dnsResolve(newhost) != dnsResolve(host)) {
		alert('Hack attempt: ' + newhost + ' is not equal to ' +
host);
		return "PROXY 127.0.0.1:9999";
}

I'm sure this can be greatly improved upon (I'm probably missing some
valid host characters. Doing it this way (for the paypal.com example in
the POC), comes up with a newhost value of 'www.pypal.com'. I also added
the dnsResolve as a 'just in case', but you can probably take that out.
This was just something quick I came up with, but it certainly prevents
the POC from working (in Firefox). 


Michael Scovetta
Computer Associates
Senior Application Developer
www.scovettalabs.com


-----Original Message-----
From: Brandon Kovacs [mailto:liljoker771@...il.com] 
Sent: Monday, February 07, 2005 11:39 PM
To: bugtraq@...urityfocus.com
Subject: International Domain Name [IDN] support in modern browsers
allows attackers to spoof domain name URLs + SSL certs.



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:

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&#1072;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@...oo.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-soluti
ons/





You can view the paper here:
http://www.shmoo.com/idn/homograph.txt

Powered by blists - more mailing lists