DNS Cache Poisoning: NAT Interference

After patching my DNS servers, I went about testing that the patch was working. I confirmed this with a tcpdump of DNS traffic. The source ports of outgoing queries leaving the DNS servers were indeed being set to a randomized UDP port.

However, I then tested my DNS server using the Check My DNS tool on Kaminsky’s blog site. I was surprised to see that the source port was no longer randomized. As the DNS queries leave our private corporate network for the public Internet, our NAT gateway is rewriting the random UDP source ports to a predictable sequential series of source port numbers: 14756, 14757, 14758, etc. Apparently, the NAT gateway is reducing the effectiveness of the additional entropy introduced by the random source ports.

More detail about how I performed the tests can be found in this blog posting.

So, are we at risk? Yes, and no.

We’re definitely better off than we were before the patch. As pointed out in a previous post, anyone who can make a recursive query can poison an unpatched DNS server. In our case, the DNS server is patched. That’s good. If an attack is operating entirely within our private network against our private DNS server, then we’re safe. It will be very difficult for an attacker to properly guess which random port the DNS server is using for a given query.

However, if the attack is being coordinated from both within the private network and from the public Internet, then we are still at a somewhat high risk of poisoning. The attacker can take advantage of the reduced source port entropy of DNS queries passing through NAT. The attacker need only initiate a recursive query from within the private network, while simultaneously attempting to poison the response from the public Internet. Because the query’s source port is no longer randomized following NAT translation, the attacker would need to send bogus replies to a small series of sequentially numbered ports on the NAT’s external IP address.

Unfortunately, our NAT gateway vendor does not yet have a patch available.

In the meantime, I will install a new DNS server in our corporate DMZ network to which all internal DNS servers will forward recursive queries to.

DNS Cache Poisoning: Risks

Today, I had a conversation with a friend who wanted to know how the DNS cache poisoning attack works. I regurgitated what I had already read on Kaminky’s blog post on the subject, as well as the deleted Matasano blog posting (which is now available elsewhere on the Internet).

The next question that came to mind: “Who is at risk?”

My simple answer: “Any unpatched server that provides DNS query recursion service is vulnerable to this new form of cache poisoning.”

In short, “unpatched recursive servers.”

But what does that really mean in terms of specific network configurations?

To understand this, I prefer to think of this vulnerability in terms of who/what/where the poisoning threat might come from.

As pointed out in a previous post, the full details of the problem will not be disclosed until August 7. However, enough has been revealed following the accidental leak by Matasano Security, such that I will try to shed some light on the risk.

Unfortunately, due to the nature of how a DNS infrastructure works, it’s not necessarily obvious whether someone is at risk or not. There can be many layers of DNS query recursion, forwarding, and referring. A server is only as safe as the weakest link in that chain. To help explain what the impact might be in different situations, here are some scenarios I came up with.

Scenario 1: Authoritative-Only DNS Server

If a server does not perform any recursion on behalf of other computers, then it is not affected. Such a server is often referred to as an authoritative-only server for a particular domain. It provides answers to queries of hostnames contained within the domain it is authoritative for. If a query is made for a hostname outside of that domain, the server will tell the asker to look elsewhere. For example, I can ask the Yahoo DNS server for the IP address of www.yahoo.com, and it will respond with But if I ask the Yahoo DNS server for the IP address of www.google.com, it will tell me to look elsewhere.

It is important to note that most publicly available authoritative DNS servers are authoritative-only, and thus they do not provide any recursion services. However, a server can be authoritative for a domain and provide recursion services, but such a server is usually not publicly available.

In the case of an authoritative-only DNS server, it does not need to be patched.

Scenario 2: Publicly Available Recursive DNS Server

Some DNS servers which are available to the whole Internet are also configured to allow recursion to anyone on the entire Internet. This is bad. In terms of the recent DNS flaw, these servers are most vulnerable, as the risk of poisoning can come from anywhere on the Internet. Put simply, anyone who is allowed to perform a recursive query on a DNS server can also poison it.

Such a server must be patched.

Scenario 3: Private Recursive DNS Server

An unpatched recursive server is vulnerable and can be exploited. Period.

Even if the recursive server is available only to a small group of computers, that small group of computers can be used to exploit an unpatched DNS server. Remember, it takes only 1 computer capable of making recursrive queries to poison the cache.

But what are the chances this could actually happen? Your chances will depend on a number of factors.

  1. The level of trust attributed to the computers capable of making recursive queries.
  2. The level of trust attributed to the users capable of making recursive queries, as well as the knowledge, skill, and motivations of those users.
  3. The number of computers capable of making recursive queries. The greater the number of computers, the greater the number of threat sources.
  4. The nature of the DNS service providing access to recursive queries. Some DNS services do not maintain a cache. In such cases, the cache-poisoning attack might affect only a single query, but it cannot poison a non-existent cache.

Let’s examine some specific examples.

Private Home Network

If you have a private home network, then chances are that you know who your users are, and you know what level of trust you have in those users. In many cases, the users are your spouse, your children, your roommates. Generally, you probably can trust these people.

But you are probably not running your own DNS server in such a network. You’re probably using a connection-sharing device. See below.

Broadband Connection Sharing Devices

These are usually consumer-grade DSL/cable Internet sharing devices, such as those made by Linksys, Netgrear, Dlink, etc. Many of these devices are configured to use your ISP’s DNS servers. I do not believe the device itself maintains a cache of its own, and so it alone may not be vulnerable. (Apparently, some of these devices do maintain a cache. A comment posted to this blog page indicates that his Linksys WT54G router uses dnsmasq to maintain a small cache.)

Nonetheless, I suspect that many of these devices are configured to forward queries to the ISP’s DNS server, which may or may not be vulnerable. Refer to the ISP section below.

Your ISP

If you have an Internet connection, especially a home DSL or cable connection, then chances are high that you are using your Internet service provider’s DNS servers to answer hostname queries for web sites you visit (www.google.com, www.yahoo.com, www.hotmail.com, etc). Often times, the DNS server is available for performing recursive queries on behalf of all customers of that ISP.

While not as high a risk as a wide open recursive server available to anyone on the Internet, the risk is still pretty high. The larger your ISP, the greater the risk that a poisoning attack can come from any one of the ISP’s customers.

The largest ISPs in the United States are SBC, Comcast, Verizon, and Time Warner. Collectively, these large ISPs represent greater than 50% of the market share. They are especially vulnerable.

Your ISP’s servers must be patched.

Open Wi-Fi Home Network

If you run an open wi-fi network, you are at risk if your network hosts its own caching, recursive DNS server. Trust level of your users is unknown. If anyone can access the open network, then anyone can poison it.

Note that many open wi-fi networks are created using a consumer broadband sharing device (see above), so the device itself might not be vulnerable. However, you are exposing your ISP’s unpatched DNS servers to attack.

School or University / Private Corporation

Many organizations provide private recursive DNS servers, which are completely hidden from the Internet. The private servers are configured to provide recursive service to the organization’s private networks only.

This is identical to the ISP example above.

I would be especially concerned on a university network. University students are usually smart and they may be highly-tempted to test their campus DNS servers.

Scenario 4: Forwarding-Only DNS Server

Some DNS servers do not do any recursion themselves. They are configured to forward all queries to another DNS server. I am uncertain whether a forwarding-only server is vulnerable. It probably depends on whether the forwarding server maintains its own cache.

Nonetheless, you are only as safe as the weakest link. So, if your forwarding-only server forwards to a vulnerable DNS server, then the forwarding-only server is affected, albeit indirectly.

DNS Cache Poisoning: Exploit Revealed

The Announcement

Since Dan Kaminsky‘s public announcement on July 8, 2008, regarding a serious DNS vulnerability, much publicity has been granted to this topic by the online press. Many key people in the industry reinforced the notion that this was serious. The message to system administrators was clear: “patch, trust us.”

This announcement was different than the prototypical announcement surrounding a software security vulnerability. Many vendors were already on board months prior, and patches for many DNS software applications were ready to be made public at the same time as the announcement. The unusual nature of the coordination effort and its subsequent announcement implied that this vulnerability was serious.

The good news: organizations had 30 days to patch their vulnerable software. On August 7, Dan will present the full details about the vulnerability at the Black Hat conference in Las Vegas.

30 Days Becomes 13 Days: Exploit Revealed

Unfortunately, that original window of 30 days turned out to be only 13 days. Last week, researcher Halvar Flake began speculating about the cache-poisoning nature of the vulnerability. While he did not get the exact detail of the exploit correct, he apparently got close enough. Shortly thereafter, Matasano Security published a blog entry, filling in some of the details that Halvar missed. The blog post was not intended to be posted before August 7, and it has since been deleted, but plenty of copies still exist on the Internet.

Too late. That was it. The cat was now out of the bag. Within a day or two, exploit code began appearing on the Internet.

As Kaminsky noted on his blog that day, “13>0 … Patch. Today. Now. Yes, stay late.” And that’s just what I did. Like a lot of people, I had dragged my feet on this one. Partly because I felt safe that I would have 30 days to patch.

Note to self: In future, assume 3 days instead of 30. Better yet, assume 0 days.