Over the years, many changes have been made to the Domain Name System (DNS). Some of these changes were made to allow internationalized domain names (IDNs). The concept behind these is simple—to allow language-specific scripts or characters that are not part of the usual Latin alphabet to become part of domain names.
However, the security and cybercrime implications of international domain names have to be considered. We know that criminals jump at every new technological development to make money… and that some open the doors to cybercrime more easily than others.
This is a subject I’ve been thinking about for a while now. There are a number of facets to the IDN discussion and a number of associated risks.
Top-Level Internationalized Domain Names
Initially, country-code top level domains (ccTLDs) were not part of IDN implementation. For example, you could use Cyrillic characters in an .ru domain but the country code would not be in Cyrillic. (IDN support would be decided by the bodies managing each specific ccTLDs.)
Several internationalized domain names have already been approved for use by the following countries:
- China (中国 and 中國)
- Egypt (مصر)
- Hong Kong (香港)
- Russia (рф)
- Saudi Arabia (السعودية)
- Taiwan (台灣 and 台湾)
- United Arab Emirates (امارات)
The first threat that comes to mind is domain squatting in these new country-code domains. Let’s consider a theoretical example of the (fictional) company Bingo. бах is Bingo in Russian. Suppose someone registers бах.рф before Bingo gets around to it.
The customers of Bingo would be exposed to phishing from бах.рф before the legitimate Bingo organization is able to register its domain. (This threat would occur anytime a new TLD is approved that is applicable to an existing organization.)
(Note: The previous two paragraphs originally appeared with “bingo.рф” as the example. This was incorrect, as it is not possible to register bingo.рф. If the top-level component is internationalized, the second-level component must be as well.)
It gets worse. With a valid registration, it would not be hard to prove that a domain is legitimately owned and thus get an SSL certificate. This could lead users to believe they are visiting the legitimate site. The only real solution here is vigilance on the part of the domain owners and registrars and careful scrutiny on the part of computer users.
However, we know that most users do not closely examine all of the URLs they see. Many are still unaware of the risks phishing poses or are too trusting of information they receive by email and by other communication channels. Consider the following list of targets cybercriminals attacked via phishing in August:
Cybercriminals would not persist with this method of attack if it were not profitable.
Synchronized Country-Code Top-Level Domains
Complicating matters is the issue of synchronized ccTLDs. These are ccTLDs that have been deemed equivalent in the sense that there is a user expectation (based on cultural or linguistic traditions) that domains under each should “resolve to the same address or value.”
For the current international ccTLDs, the most obvious candidate would be Chinese. As noted earlier, both China and Taiwan received two ccTLDs each but these are actually synonymous, differing only in how they are written. In China, simplified characters are preferred. In Taiwan, the opposite is true—traditional characters are preferred.
IDNs like the above that would be considered identical if written in Unicode could be linked in DNS so that they all have identical registries. However, this feature is not yet active.
Directly related to this is another discussion about offering the same feature at the second level. Where looking at synchronized ccTLDs would have a very small number of synonyms (i.e., those approved by the ICANN), synchronized domain names (i.e., roughly analogous to equating XYZ.com with xyz.com and Xyz.com) would have many more possible combinations, depending on the language/script used.
I believe this has potential to throw up a whole number of issues for the security industry. If they are deemed to all be different domains, the industry would have to identify each individual variant of a domain used by a malicious server.
There is still much discussion ongoing in the area of synchronization (or, more accurately, variants). Trend will be keeping an eye out for future developments.
Currently, all upper-case letters are forbidden from use in IDN labels, however not all characters of all scripts fit neatly into upper and lower case categories. How this will impact the use of IDNs remains to be seen.
Internationalized Domain Names on Standard Top-Level Domains
As mentioned earlier, some ccTLDs support IDNs even if their country codes still use Latin alphabet characters. This was an issue I discussed earlier this year in my post, “Can IDN Use Open a Can of Unicode Worms?”
Theoretically, nothing can stop someone from registering a similar-looking name in .com (say paypal) using another character set.
This is known as an IDN homograph attack or ASCII spoofing. In theory, this sounds very scary. However, in reality, it is hard to implement.
In order to successfully carry out an IDN homograph attack, the cybercriminal would need to find a domain name with characters that you can entirely construct in another script.
There is an IDN guideline that prohibits an IDN label from containing characters from more than one script. This will prevent an attacker from creating a label by combining characters from the Cyrillic, Greek, and German scripts to create a domain name that looks like one ASCII word. However, because it was created from different Unicode characters it has a completley different value, and thus would direct the user to a different and possibly malicious website.
In reality, I have seen proofs of concept (POCs) that are able to confuse Unicode implementation into displaying characters from other character sets. However, these need very controlled conditions and, therefore, would be difficult to exploit.
Trend Micro Solutions
The Trend Micro Web reputation service has IDN use well in hand. Trend Micro customers will remain secure as we continue to focus on preventing new threats before they reach customers’ networks.
To summarize, the current and emerging challenges thrown by IDNs are:
- Database bloom. IDNs would allow many more DNS records to point to one location. This could cause Web blocking databases to substantially expand.
- Increased phishing potential. In some cases, it is possible to make a URL look similar to a well-known existing URL. However, this is not earth-shatteringly new.
- Domain squatting. The biggest threat from IDN is the first that I discussed. We cannot assume that every domain owner will have time or the inclination to continuously demonstrate high levels of vigilance and users cannot be expected to constantly scrutinize URLs (however much we would like them to).
Update as of October 6, 2010, 8:00 P.M. (UTC-7)
Correction made to domain squatting example.
Update as of October 7, 2010, 6:00 P.M. (UTC-7)
Corrections and clarifications made in various portions.