DNS Vulnerability Is Important, but There’s No Reason to Panic
by Dave Kennedy
Implementations of the Domain Name Servers (DNS) protocol may leave systems vulnerable to DNS cache poisoning attacks. Last week many incident response teams, along with software and hardware vendors, issued security bulletins and patches to reduce this risk. Cache poisoning attacks are almost as old as the DNS system itself. Enterprises already protect and monitor their DNS systems to prevent and detect cache-poisoning attacks. There has been no increase in reports of cache poisoning attacks and no reports of attacks on this specific vulnerability. DNS is infrastructure. Infrastructure must be trusted, and it must be perceived as trustworthy.
Verizon Business RISK Team recommends our customers update their DNS servers within 30 days with priority given to caching DNS servers.
Clearly, some media reports are hyping this issue. This is a vulnerability that requires attention. The RISK Team is reluctant to categorize this issue as all “hype”, especially since we want our customers to begin planning to address this issue almost immediately, so as to deploy within 30 days. The Internet is not at risk. Even if we started seeing attacks immediately, the reader, Verizon Business, and security and network professionals the world-over exist to make systems work and beat the outlaws. We’re problem-solvers. If, or when, this becomes a practical versus theoretical problem, we’ll put our heads together and solve it. We shouldn’t lose our heads now.
However, this doesn’t mean we discount the potential severity of this vulnerability. We just believe it deserves a place on our To-Do lists. We do not, at this point, need to work nights and weekends, skip meals or break dates any more than we already do. And while important, this isn’t enough of an excuse to escape next Monday’s budget meeting.
It also doesn’t mean we believe someone would be silly to have already patched and to be very concerned about this issue. Every enterprise must make their own risk management decisions. This is our recommendation to our customers. In February of 2002, we advised customers to fix their SNMP instances due to the BER issue discovered by Oulu University, but there have been no widespread attacks on those vulnerabilities for nearly six years now. We were overly cautious. We also said the Debian RNG issue was unlikely to be the target of near-term attacks and recommended routine maintenance or 90 days to update. So far, it appears we are right on target.
There have been no increase in reports of cache poisoning attempts, and none that try to exploit this vulnerability. As such, the threat and the risk are unchanged.
There are IDS signatures available to detect attacks on this vulnerability. So, like the Debian RNG problem, with many “researchers” eagerly watching in order to proclaim they were the first to witness an attack on this problem, we all have an enhanced “network” providing threat reports. Like Debian RNG, we expect to have advanced warning of any significant attacks on this vulnerability, and can adjust our level of concern appropriately.
Technical details: (from Wikipedia)
The Domain Name System (DNS) associates various information with domain names; most importantly, it serves as the “phone book” for the Internet by translating human-readable computer hostnames, e.g. www.example.com, into IP addresses, e.g. 208.77.188.166, which networking equipment needs to deliver information. A DNS also stores other information such as the list of mail servers that accept e-mail for a given domain. By providing a worldwide keyword-based redirection service, the Domain Name System is an essential component of contemporary Internet use.
Because of the huge volume of requests generated by a system like DNS, the designers wished to provide a mechanism to reduce the load on individual DNS servers. To this end, the DNS resolution process allows for caching (i.e. the local recording and subsequent consultation of the results of a DNS query) for a given period of time after a successful answer. How long a resolver caches a DNS response (i.e. how long a DNS response remains valid) is determined by a value called the time to live (TTL). The administrator of the DNS server handing out the response sets the TTL. The period of validity may vary from just seconds to days or even weeks.
DNS cache poisoning is a maliciously created or unintended situation that provides data to a Domain Name Server (DNS server) that did not originate from authoritative DNS sources. This can happen through improper software design, misconfiguration of name servers and maliciously designed scenarios exploiting the traditionally open-architecture of the DNS system. Once a DNS server has received such non-authentic data and caches it for future performance increase, it is considered poisoned, extending the effect of the situation to the clients of the server.
In theory, the reply to a DNS query can have 65,536 x 65,536 possible combinations of query ID and source port. In practice however, ports below 1024 are not used and in practice, prior to this week, many implementations used a very limited number of combinations of IDs and source ports. An attacker would only have to guess the correct query ID to spoof a DNS reply and poison a cache. The patches announced last week better randomize the source ports.
Authoritative name servers, those that provide an authoritative answer (flag aa) to a DNS query are not affected by this vulnerability. For example, the primary and secondary name servers for an organization and those that do not accept internal client DNS resolution requests, and do not cache the DNS answer from another server are not affected. However, as infrastructure, you should provide priority maintenance to these Internet-facing systems.
In the short term, the potential to corrupt one’s DNS infrastructure in the process of patching may be the most significant risk we face.
Testing updated deployments is essential. Rushing a patch when there is no change in threat is unwise. The desired end is a trusted infrastructure, and an outage in the process is contrary to that goal.
Tags: Cache Poisoning, Computer Attacks, DNS, DNS Cache Poisoning, Information Security, InfoSec, risk, Vulnerabilities
As the original finder of this issue, I’d just like to express my support for the core message of this post. The vulnerability is important, and should be fixed by August 6th, but there is no reason to panic, and every reason to test your updated deployments. Screw up DNS, and all goes wobbly very very fast.
Posted by: Dan Kaminsky on July 19th, 2008 at 7:24 pm