Recently, we were thinking about purchasing new domain names for Imperva’s web site in languages other than English. This was a trigger for me to do some reading on ICANN’s International Domain Names (IDNs). Although I was already familiar with the general IDN concept, I knew that it is an evolving standard and I wanted to go back and re-examine the potential impacts on our WAF product. I didn’t find anything too interesting, but I did come to understand that there are some major security implications associated with this standard.  More importantly, no one has yet taken real responsibly for dealing with them.

But before I get into that, here’s a crash course in IDNs for those of you who are not familiar with the concept:

1. International domain names are becoming more and more available as more registrars and ISPs are implementing the IDN standard, which allows registering domain names that include non-ASCII characters.

2. Internationalized Domain Names in Applications (IDNA) is a mechanism for accessing IDNs that include non-ASCII characters with client applications. In order to have minimal impact on the Internet framework (e.g. DNS servers), IDNA assigns clients the responsibility of converting IDNs to restricted-ASCII domain names when communicating with network elements. So, from the network perspective IDNs are just funny looking ASCII domain names.

3. Another reason for this type of implementation is to allow applications that do not support IDNA to access IDNs by using the ASCII equivalent.  The conversions between ASCII and non-ASCII forms of a domain name are accomplished by algorithms called ToASCII and ToUnicode and, at the end of the conversion, a special prefix is appended to the domain name – “xn--“.  For example, the domain name www.blåbærsyltetøy.no will be converted by a browser to www.xn--blbrsyltety-y8aO3x.no” and only the ASCII form of the domain name will be used in DNS lookups and HTTP requests. Notice that each part of the domain is converted separately, leaving ASCII parts in their original form (“www” and “no” in the example).

Going back to the security implications of IDNA, one major security issue associated with IDNs is domain name spoofing (or homograph spoofing attack). This attack is much like the old trick of registering visually similar domain names by replacing the character “o” with a zero or replacing the character “m” with “rn” (“r” followed by “n”). Due to the large number of visually similar characters in the Unicode space, IDNs make it easier for attackers to register domain names that are visually similar to existing domains and thus, set up more convincing phishing sites.

Just to give you an idea of the extent of the problem, let’s take the domain name www.imperva.com as an example. For spoofing a visually similar domain an attacker can replace the “i” with the Hebrew character vav “ן“, replace the “p” or “e” with the Cyrillic “р” or “е”, replace the “a” with the Greek alpha “α”… I think you get the idea.

In my opinion the real issue here is that no one has really claimed responsibility for the problem except for partial efforts by browser vendors. When IDNA was first introduced, ICANN issued guidelines to registrars concerning the problem. However, no real countermeasure was proposed and the responsibility was handed to the Internet community.

I can’t blame anyone for not taking responsibility for this issue – it’s a hard one to tackle. However, I recommend that the security community keeps a close eye on how the IDNs standard evolves and be prepared to react quickly. I surly intend to.

source: http://blog.imperva.com