Mitigation tools for IDN security problems

by Michael S. Kaplan, published on 2005/08/20 21:16 -07:00, original URI: http://blogs.msdn.com/michkap/archive/2005/08/20/454144.aspx

Back in January, just before the flap at the hacker's convention with the paypal.com like that used a cyrillic 'a' to prove that IDN without a way to ferret out phishing attacks, I posted my own post entitled International Domain Names? The sign on the door says 'Gone Phishing'....

It was an interesting flap because the RFCs for Internationalized Domain Names clearly points out the dangers and talks about the need to do some extra work to avoid security issues, but several browsers jumped ahead to support them and then just as quickly rushed out to turn them off by default.

Folks at Microsoft, who knew about the need to do work here first, did not jump ahead without looking. And Microsoft was complimented for not jumping in too quickly. :-)

Unicode has move in to assist with Unicode Technical Report #36: Unicode Security Considerations.

And now Microsoft has some functions to help ISVs jump in (functions that can and will also be used in future versions of Microsoft products!).

Here it is: Microsoft Internationalized Domain Names (IDN) Mitigation APIs 1.0.

From the overview:

The "Internationalized Domain Names Mitigation APIs" download includes several API functions to convert an IDN to different representations, as well as several API functions specifically intended to allow applications to mitigate some of the security risks presented by this technology. The functions IdnToAscii, IdnToUnicode, and IdnToNameprepUnicode each convert an IDN string to a particular form. The functions DownlevelGetLocaleScripts, DownlevelGetStringScripts, and DownlevelVerifyScripts allow applications to verify that the characters in a given IDN are drawn entirely from the scripts associated with a particular locale or locales. However, these functions are only helpers; applications have still to perform comprehensive threat modeling and create appropriate mitigation for these threats.

Also included are the Unicode normalization APIs IsNormalizedString and NormalizeString, which are used by the mitigation APIs.

This package is supported on XP (Service Pack 2 or later) and Server 2003 (Service Pack 1 or later). And differently named functions will also be in Vista!

For info on the Normalization API functions, look here.

For info on the IDN API functions, look here.

The cool functions in the package to help with the mitigation (they make use of ISO 15942 for their script definitions):

You can use these functions as part of your strategy for dealing properly with internationalized domain names -- warning users of potentially dangerous links to information.

Awesome!

 

This post brought to you by "а" (U+0430, a.k.a. CYRILLIC SMALL LETTER A)

# Maurits on Sunday, August 21, 2005 1:22 PM:

Phishers don't typically need to resort to IDN's to perform effective social engineering, of course. Consider windowsupdate.com:

windows-update.com was ACTUALLY USED by a phisher

then there's windows.update.com
updatewindows.com
W1NDOWSUPDATE.COM
windowsupdate.secure-login.com
windowsupdate-en.com

etc.

I only see a couple of ways around this:

1) Use microsoft.com as the parent domain
windowsupdate.microsoft.com
2) Use https
https://update.microsoft.com

Using microsoft.com as the parent domain means only thirteen characters (fourteen including the . before the m) need to be security-checked.

Using https means black hats have to shell out another couple of hundred. Also the security certificate issuer is expected to take certain steps to make sure the issuee really is who they say they are. There might even be liability.

# Michael S. Kaplan on Sunday, August 21, 2005 1:29 PM:

Hi Maurits --

I guess the main point of the functions is to help remove a particular new attack vector, not to solve all attack vectors (most of which, as you point out, are not internationalization issues).

Plus it adds normalization and IDNA support downlevel, which is awesome!

# Maurits on Monday, August 22, 2005 12:18 PM:

Perhaps the best way to address the problem is at the registrar level. ICANN might need to come up with some stiff penalties for registrars that accept obviously fraudulent name registration requests.

# Michael S. Kaplan on Monday, August 22, 2005 1:22 PM:

I doubt that it would be a popular move with the registrars to start talking punishment....

# Maurits on Monday, August 22, 2005 1:34 PM:

I know... but we're talking about identity theft here. Eventually the cops need to get involved.

Forcing URLs to be ASCII-only smacks of xenophobia and the anglicanization of the internet.

The company I work for has a fairly high percentage of employees with "8-bit" names... accented characters in particular. I've had to implement a policy of changing these to their vanilla equivalents when giving usernames and passwords. But I feel kind of dirty doing that. Hopefully in ten years they can keep their accented characters in their return email address, and keep the vanilla equivalent as a secondary email address on their mailbox.

Perhaps a similar rule can be generated for domain name registrations? So, for example,
mícrosoft.com [1]
COULD be registered - but ONLY by whoever holds microsoft.com
?

Note verisign et al. actually allow IDN registrations, and they're not too forthcoming with the fact that you can't actually use those domains in any practical fashion.

[1] MEE-crow-sohft -- accent is necessary per Spanish pronunciation rules

# Michael S. Kaplan on Monday, August 22, 2005 1:45 PM:

Hmmm.... well, I'll wait to see what the UTC comes up with, and how people use this package from Microsoft. :-)

# Maurits on Monday, August 22, 2005 1:51 PM:

Sorry, Verisign...

It appears that they have mended their ways. They no longer offer IDN registrations (though last time I registered a domain from them, they did.)

Now they merely link to other registrars that do.

http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/page_001397.html

# Michael S. Kaplan on Monday, August 22, 2005 10:03 PM:

Hi Maurits --

Of course they used to take money for them. Do you think they refunded it all? :-)

# Maurits on Friday, September 30, 2005 2:47 PM:

Did you see this?
http://www.icann.org/general/idn-guidelines-20sep05.htm

Public Comment period ends October 20.

# Michael S. Kaplan on Friday, September 30, 2005 2:53 PM:

There does have to be ICANN interest here, obviously. They need registrars and others to be involved with the screening processes...
Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

referenced by

2008/04/30 Why WC2MB needs a CP, chaver sheli!

2006/07/28 The download you requested is unavailable.

2006/07/16 Update to the mitigation tools for IDN security problems

2006/06/17 64-bit thoughts, and an apology

2006/01/14 Getting out of the compatibility zone, redux

2005/12/20 IDN hits the uber-client

2005/12/03 When even the bugs seem cool

2005/12/02 Getting out of dodge (or at least out of the compatibility range!)

2005/09/29 It's already in there, or it's on the way

2005/09/12 Theory vs. practice for Korean text collation, Redux

2005/09/09 Safe 'DrawText' function

go to newer or older post, or back to index or month or day