Mitigation tools for IDN security problems

Sorting it all Out
Michael Kaplan's random stuff of dubious value
Be sure to read the disclaimer here first!

Mitigation tools for IDN security problems

  • Comments 16

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)

Comment on the blather
Leave a Comment
  • Please add 7 and 5 and type the answer here:
  • Post
Blog - Comment List
  • 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.
  • 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!
  • 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.
  • I doubt that it would be a popular move with the registrars to start talking punishment....
  • 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
  • Hmmm.... well, I'll wait to see what the UTC comes up with, and how people use this package from Microsoft. :-)
  • 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
  • Hi Maurits --

    Of course they used to take money for them. Do you think they refunded it all? :-)
  • A recent thought from a reader, sent via the Contact link:

    Hi. I actualy tried finding the correct...
  • Back in February, I talked about theory vs. practice for Korean text collation, comparing Microsoft's...
  • Did you see this?
    http://www.icann.org/general/idn-guidelines-20sep05.htm

    Public Comment period ends October 20.
  • There does have to be ICANN interest here, obviously. They need registrars and others to be involved with the screening processes...
  • 64-bit is becoming more and more popular.
    This I know because not a week goes by that I do not get either...
  • So it was a little under a year ago that I posted about the Mitigation tools for IDN security problems,...
  • Remember earlier this month when I was talking about the Update to the mitigation tools for IDN security...
Page 1 of 2 (16 items) 12