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.
Read the rest of this entry »

Last week at the BlackHat and DEFCON security conferences, independent researcher Craig Heffner demonstrated a new attack against home routers that combined DNS rebinding and Cross-Site Request Forgery (CSRF). This attack used JavaScript to trick the user’s browser into establishing a communication channel between the attacker and the admin console of his/her home router. If the router password is easy to guess (e.g., router or password) or still set to the factory default, the attacker can quickly gain full control of the device and by doing so expose every device on the network to attack. (For example, the attacker might be able to change the DNS settings of the router, making everyone connected to it vulnerable to phishing attacks.)

The Attack: Complex but Practical and Effective

First, the attacker has to assume a position where he/she is capable of changing the DNS records of the domain that will be used for the attack. Next, the attacker will need to create various pages on the malicious domain that will host the Web side of the attack and link these with DNS. Finally, the attacker must have sufficient control of the Web server such that he/she can cause it to send a TCP reset (RST) command on demand.

The attack begins when the user visits the malicious site. Heffner used DNS to collect the victim’s public IP address but there other ways to do this as well. Once the attacker has the victim’s public IP address, he/she needs to quickly create a new subdomain on the attack domain with 2 A records, which map a hostname to an IP address. The first A record points to the server while the second points to the public IP address of the victim’s router. The Web server now redirects the victim’s browser to a page with JavaScript code that will execute the CSRF portion of the attack.

Now we get to the interesting part. The browser begins to execute the JavaScript code that tries to connect to the temporary subdomain. The attacking server will reply with an RST command and end the session. This user’s system will then try the other IP address that it knows about for the hostname, which happens to be the external IP address of the victim’s router. Any result is channeled to the attacking server via a portal. The attacker can try different user name and password combination until he/she successfully connects or the browser window/tab is closed.

How Users Can Protect Themselves

Normally, the admin console is not exposed to the Internet because many consumer routers include a default setting (or provide an option) that prevents any IP address outside of the local network from connecting to it. However, many services on these devices listen for connections on all interfaces. Packet filtering will prevent external users from accessing the admin console but internal users can often access the console using an external IP address.

Here are some suggestions that will reduce risks brought about by this attack based on the list of suggestions provided by Craig Heffner:

• Enable the HTTPS admin console on your device and don’t forget to disable the HTTP console (if possible).
• Use a strong password for your router. Change the user name to something other than the factory default, if possible. If you worry about forgetting the new password, write it down and put it on the device itself.
• Disable access to your router’s admin console from any external network. This option is often accessible from the admin console.
• If you choose not to use the DNS servers automatically provided by your ISP, use another recursive resolver (with permission) or a resolver offered for public use such as OpenDNS. This will protect you from the published version of this attack code and the root servers will thank you.
• If possible, add a firewall rule preventing devices on your local network from sending packets to the block that your public IP address is a member of. This will prevent any IP addresses on your LAN from contacting the external IP address of your router. If your ISP changes the block used in your neighborhood, however, you will need to edit this rule. As an added benefit, this rule will prevent your systems from inadvertently broadcasting to your neighbors.
• Keep the firmware of your router and other network devices up-to-date.

Updates as of August 5, 2010, 2:05 a.m. UTC

Since this attack involves the usage of a malicious JavaScript, installing the NoScript plugin should be helpful in preventing being victimized by such attacks.

OpenDNS also discussed this same issue, and stated that using OpenDNS may be a valid solution to prevent these attacks.

Over the past few years, there has been plenty of talk about the exhaustion of IPv4 addresses and the need to adopt IPv6. One thing that is clear is that we will run out of space within 1–2 years, if not sooner.

How IPv4 addresses will run out

We know how IPv4 addresses will be exhausted. By policy, when there are only five remaining unallocated /8 IP blocks, the Internet Assigned Numbers Authority (IANA) will assign each of the five regional Internet registries (RIRs) their final IPv4 address spaces. (As of this writing, there are 16 unallocated /8 blocks.) From that point on, each registrar is on its own. This will be the first concrete indicator that we will be exhausting IPv4 space soon.

At this point, a rush to buy IPv4 space will happen. Most RIRs have between one and two /8 blocks in reserve. Service providers who want to keep IPv4 will be looking to snatch up extra space to ensure that they have room to grow. We should see IPv6 growth here, as IPv4 users watching from the sidelines will need to start moving before their services are affected.

Unfortunately, this means we should expect a full suite of related scams and frauds. These will most likely play on fears of network instability or (un)preparedness such as:

• Pay us $XXX to convert your existing IP addresses to IPv6.
• For a fee, we will guarantee that you can keep your IPv4 addresses.

There is also a potential for a gray/black market dealing in the IPv4 space. This could eventually lead to prefix hijacking. An offer to buy unused IPv4 space for a seemingly large payout may be legitimate. However, you will still be the registered owner of that block in the whois and RIR databases. Any malicious activity found there may cause you a knock on the door from a government agency.

Challenges of IPv6 migration

I expect IPv4 to be alive and well for a decade if not more. Too many legacy systems that do not face end users and work perfectly gain nothing from IPv6. Many services and service providers are not yet IPv6 capable. In addition, some long-standing issues with IPv6 keep getting kicked down the road in the hope that someone will solve them remain unsolved. These will slow the transition down. One such issue will sound very familiar to folks who have experience from the mid 1990s.

RIRs started allocating /24 blocks to end users that, in theory, they could take to any ISP (these blocks are said to be Provider Independent or PI). However, some of the larger tier 1 ISPs wouldn’t accept a route that small, forcing users to ask for IP space from the ISP (these were Provider Assigned or PA). Users were caught in a position where they had their own IP space but no way to connect to it or were using IP space from a single provider. This made it hard to create an alternate route through another provider or to get new numbers if they wanted to change service providers.

Do you have a plan to expand your operations into IPv6?

I recently made up two nonsensical domain names—eixpay.com and eixpay.com—can you spot the difference between them?

In a modern Unicode-capable browser, they are likely to appear identical but if you copy and paste each one into a search engine, you will get different results. The domain on the right was created using Cyrillic characters while the one on the left was created using Western characters. While most Cyrillic characters vastly differ from US-ASCII characters, a handful of symbols look at home in either character set (see page 2 of the chart).

When viewed in hexdump, you can clearly see the difference between the two domain names. As shown, .com is written in ASCII code in both names (see Figure 1).

I then created a simple HTML file with links to each domain name. Note that the ASCII domain name is italicized in the anchor tag while the Unicode domain name is not (see Figure 2).

When I first pulled it up in Firefox 3.5, the character encoding was set to ISO-8859-1(Western) so the Unicode link clearly differed (see Figure 3).

A quick change of my character encoding to Unicode(UTF-8), however, resulted in an altogether different scenario (see Figure 4).

GIZMODO points out that this works with other strings as well. An attacker thus only needs to find commonly used code pages that they can use to piece together the characters they will need to spoof legitimate sites. In my brief testing, I found that using more than one Unicode block in a single URL produces unpredictable results.

Recent discussions about the Internet Corporation for Assigned Names and Numbers (ICANN)’s approval of the use of internationalized domain names (IDNs) and how they can pose additional security risks have been ensuing. Some believe that allowing the use of IDNs can make antiphishing efforts harder.

Simply put, IDNs work by converting Unicode strings into punycode strings before the browser queries a Domain Name System (DNS). For instance, the punycode version of eixpay.com is xn--80aj7anh5h.com. At www.IDNstuff.com/, they have a handy tool for converting Unicode strings into punycode and back.

It took some digging but I did find a few registrars that support punycoded domain names on existing top-level domain names (.com, .net, etc.). Should a cybercriminal register xn--80aj7anh5h.com, he/she can create a pass-through of the ASCII eixpay.com page and use email, instant messaging (IM), or social networking to entice users to click a Unicode link that will connect them to a look-alike phishing page. Simply double-checking a site’s name may thus no longer be enough.

If you want to see how real IDNs react in your browsers and other tools, take a look here for some active samples.

Have you ever noticed how security often takes a backseat when trying something new? When I am trying out a protocol out for the first time, I barely skim the Security Considerations section of the RFC. Just the same, as more of us start experimenting with IPv6, the use of tunneling protocols is likely to rise. That is good for IPv6 adoption but not so hot for security.

I certainly don’t want to discourage anyone from trying IPv6. In fact, I would rather see folks testing the waters now, trying it out and getting comfortable with it, than thrashing and flailing when ICANN announces the exhaustion of IPv4 pools. I do want to make sure everyone is aware of the risks involved so they can take appropriate precautions.

This article will only cover 6to4 (Wikipedia/RFC 3056) not to be confused with 6in4 and Teredo (Wikipedia/RFC 4380) tunneling protocols. A direct tunnel to your providers’ IPv6 systems does not present the same problems and risks as these public protocols do.

Both protocols focus on easing the transition to IPv6 and neither one claims to offer any significant security protection. In fact, the Teredo RFC goes so far as to call itself the IPv6 Provider of Last Resort. This label comes primarily from the crazy stunts required to successfully traverse multiple NAT gateways. However, it is worth considering some other factors as well. 6to4 comes with an entire RFC devoted to security considerations (http://tools.ietf.org/html/rfc3964). Remember, IPv4 firewall rules don’t do anything to IPv6 traffic.

6to4 tunneling requires that the user endpoint exist in publicly routable IP space and be directly reachable by any 6to4 serving device. One advantage of this exposure is that you can make use of more than just one 6to4 gateway, the obvious disadvantage being that you have to trust traffic coming from any address claiming to support the protocol for full functionality.

6to4 can also support routes to networks behind the endpoint. Endpoints are assigned an IPv6 address from the 2002::/16 prefix. The 4 bytes immediately following 2002: are the IPv4 address of the endpoint converted to hex. Thus, 192.168.25.200 would map to 2002:c0a8:19c8::/48 (RFC 1918 IP used for example only, it would be invalid in actual operation). It is reasonable to say that if one was going to create a server and publish it to the IPv6 Internet, it should also be fortified against both IPv4 and IPv6 threats. The take-away here is if you publish a 2002::/16 IPv6 address, we also know the IPv4 address of your endpoint.

Teredo is designed to work just fine with the remote endpoint behind one or more NAT gateways. Unlike 6to4, however, only one host can exist behind the endpoint. Right from the start, we need to worry about tunneling from the public Internet to a host inside a NATed environment. If the host is not well-protected, we could stop right there. We also have endpoint address leakage to contend with. Teredo goes even further than 6to4 by encoding the IPv4 exit point of the NAT gateway, the UDP port used by the external NAT session, and the IPv4 address of the tunnel endpoint used by the client. Some obfuscation is used, XORing UDP port and NAT IP with all 1s. However, this fact is well-known and will only protect you from people afraid of Wikipedia.

The base prefix for a Teredo IP address is 2001:0000::/32. Teredo client addresses are assembled as follows:

1. 2001:0000::/32 — base prefix
2. 2001:0000:c0a8:19c8::/64 — add IP address of the tunnel server (192.168.25.200 -> c0a8:19c8)
3. 2001:0000:c0a8:19c8:0000::/80 — add 16 bits of flags (0×00)
4. 2001:0000:c0a8:19c8:0000:8888::/96 — add external NAT port number XORd with 0xFFFF ( 30583 -> 0×7777 ^ 0xFFFF = 0×8888)
5. 2001:0000:c0a8:19c8:0000:8888:F537:76C8/128 — add external IP of NAT gateway XORd with 0xFFFFFFFF (10.200.137.55 -> 0x0AC88937 ^ 0xFFFFFFFF = 0xF53776C8)

Again, I don’t want to scare anyone off. Just know the risks and take appropriate precautions.

Happy IPv6ing!