The Kaminsky DNS Vulnerability, announced at the 2008 Black Hat event, poses significant risk to all network users, globally. While DNS vendors have rallied to provide patches, which protect against this vulnerability, there is still a significant risk that DNS servers can be exploited using the techniques outlined by Dan Kaminsky.
To help provide further protection, NitroSecurity worked with several outside security agencies--including the Rochester Institute of Technology--to develop a method wherein intrusion prevention (IPS) technology may be used to actively block this attack. The results: on it's own, NitroSecurity's proffered solution provides protection on par with a properly applied DNS server patch; when used to protect patched DNS servers, the protection is complete--virtually eliminating the risk of DNS cache poisoning.
~ Rochester Institute of Technology
In response to growing concerns over the Kaminsky DNS Vulnerability, announced at the 2008 Black Hat event, NitroSecurity has researched additional methods of protecting corporate DNS resources, for use in addition to the application of DNS server patches, to prevent the successful exploitation of domain services. This research has led to the use of two custom detection signatures, which—when combined with reactive device blocking (also referred to as "blacklisting")—can provide much greater protection than that provided by DNS patches alone.
The need for the best possible protection against this vulnerability is driven by the proliferation of DNS throughout everyday personal and business Internet applications, and the potential risk involved in a successful DNS attack.
1
While patching DNS servers is a requirement, the patch does not remove the vulnerability: it simply makes it more difficult to accomplish. Successful attacks have already been made against fully patched DNS servers.2 Discussion throughout the community is underway to find more layers of randomization to further reduce the chances of a successful attack. Most companies currently deploy Intrusion Prevention Systems, and if those systems support the correct features and signature libraries, they may be used as a further defense against this vulnerability. NitroSecurity has determined that, with the right combination of signatures and IPS features, along with appropriate DNS patches, the probability of a successful attack can be reduced from to 0.003% over one year, down from 37.1% over one month using the patch alone.3
The Kaminsky DNS vulnerability is best described by Kaminsky himself4, but it is summarized here for convenience. The exploit uses known DNS vulnerabilities that allows a race condition between the attacker and a legitimate DNS server, in the attempt to gain ownership of DNS name/address translation. From Doxpara Research:
DNS can be thought of as a race: A request is sent. A good guy and a bad guy both want to get their replies to be trusted. The good guy has an advantage: He sees the request, and inside of it he can find a secret number, somewhere between zero to sixty five thousand. The race is not won until someone crosses the finish line with the secret number, and while the bad guy could guess the number, he has only a 1/65,536 chance of guessing correctly. Worse, the winner of the race gets to say how long it will be until the next race! The numbers can work out that it would take months, even years for the bad guy to finally win a race.
There's a new element, however, which improves the "bad guy's" chance of winning that race:
What's new is that the bad guy doesn't actually have to wait to start another race. DNS is actually more of a relay race than a sprint. Remember, you send a request to a server, and you might get a reply that says "www.foobar.com? Sure, here's the IP address to use." Or, you might get a message that says, "www.foobar.com? I don't know, ask ns1.foobar.com, here's its address." That's recursion. It's not a bug, or a rarely used feature. DNS is always sending you to different servers to find a record — this is how the servers that run .com work. ... names near www.foobar.com — 1.foobar.com, 2.foobar.com, 3.foobar.com — are referred to as "in-bailiwick". A referral to a name in-bailiwick must be trusted. ... he can run as many races as he wants. And eventually, he'll win one of them. And when he does win — when the bad guys guesses the secret number from 0 to 65536 — he won't just provide an answer for the random name that won. He'll simply feign ignorance: "83.foobar.com? I don't know, ask www.foobar.com, here's its address. Oh, and remember this for the next week."
From the perspective of a security vendor, this type of vulnerability is vexing because it is difficult to block. An IPS rule set to block DNS session responses would stop the attack, but would also block every legitimate DNS request, blocking legitimate traffic. The solution, as discussed later, must be aware of an attack, and must be capable of interrupting the race, but without arbitrarily blocking the legitimate operation of DNS.
The published solution to the vulnerability is the application of a patch to all vulnerable DNS servers (see CERT Vulnerability Note VU#800113 for a complete advisory). This is of course very important: the patch greatly reduces the probability of a successful exploit through randomization of the source port (in place of static udp/53). From CERT:
While this is true, analysis of the exploit probability shows that the attacks are still worthy of consideration. There is still a need to detect and protect against this exploit even after patches are applied. The solution discussed within this paper is fortuitously additive: that is, the solution will improve the protection provided by patching servers, to a probability approaching zero.
Figure 1 - Kaminsky DNS Vulnerability Exploit Probability
~ Dan Kaminsky 6
Figure 1 clearly illustrates that an unprotected and unpatched DNS server is essentially guaranteed to be exploited if attacked (The Blue Data). Protecting the network using the IPS protection solution (discussed in the following section of this paper) in conjunction with a patched DNS server is the best possible solution, resulting in minute probabilities of a successful attack (represented as green in Figure 1). It should be noted that deploying the DNS exploit IPS solution with an unpatched DNS server provides somewhat better protection than just patching the DNS server alone (the red and yellow lines in Figure 1). This presents a viable alternative to patching, if a DNS system is being used that can not be patched for some reason (although it is recommended that patches be applied immediately, and that if no patch is available, the DNS vendor in question be contacted immediately).
~ Michael Leland7
The given probabilities for the DNS exploit may be acceptable. However, new attacks are being developed every day—around this vulnerability and others. The ability to detect malignant behavior among legitimate Internet protocol use, and to block such behavior, is necessary to thwart new variants. Thus the need for a further solution—such as the IPS protection solution described herein—that will:
NitroSecurity's IPS Protection solution provides additional defense against the Kaminsky DNS Vulnerability. The solution focuses on three areas:
This solution utilizes a combination of several key IPS features, including:
Rate-based detection is not a new concept to the security industry, although virtualization of the IPS detection ("Virtual IPS"), and the result-dependent suppression ("Internal Blacklist Capability") may be. Internal Blacklisting is the unique feature that enables the detection to become active, effectively blocking the attack while preserving legitimate DNS operation. While not inherently necessary to the solution, in noisy attacks such as an attack against a patched DNS server, the ability to run multiple detection engine processes in parallel is deemed prudent for the detection of two distinct signatures on between 134,217,728 and 4,294,967,296 packets.8
Two signatures are used to detect and threshold the types of response packets needed to actually accomplish the Kaminsky DNS Vulnerability attack. Again, the two custom detection signatures are processed in parallel for performance reasons. While the exact signatures are not presented here, there are open source equivalents published on emergingthreats.net 9. Using these signatures, the IPS detects both DNS 'A' and DNS 'NS' packets consistent with a Kaminsky DNS Vulnerability cache poisoning attack10. The rules use a rate thresholding capability to detect an anomalous DNS packet rate within what would otherwise look like normal DNS traffic. Unlike other approaches 11 , which might detect a Kaminsky attack, the use of this solution allows blocking behavior for actual protection against the attack.
To mitigate the Denial of Service attack vector created by the two rules, the IPS' internal Connection Tracking system drops all DNS responses not preceded by a valid DNS request. The IPS makes available to the user detailed information about the triggered Kaminsky event, for use by SIEM or other event analysis tool. Included in this information is the triggering packet, containing the DNS Resource Records with the IP address of the dangerous DNS servers, the time at which the event was triggered, and which IPS detected the attack.
The IPS capability that enables protection—that is, active blocking—of the DNS attack is the internal IPS blacklist. Blacklists, unlike typical IPS "block" actions, are the end-result of previous signature results, rather than a simple "block matched packet" methodology, they provide a "block subsequent packets after a match" methodology. This allows normal DNS responses to be received as normal. However, when the symptoms of the attack are detected, subsequent DNS responses from the suspect source IP are temporarily blocked, preventing the attacker from winning the DNS response race.
In order to quantify how well NitroSecurity's solution mitigates Kaminsky attacks, Bernhard Mueller's DNS cache poisoning attack probability function12 was applied to an analysis of NitroSecurity's approach. NitroSecurity's NitroGuard IPS was used for internal test and validation. Figure 2 shows the details of the analysis. In addition to Mueller's assumptions, this analysis makes the following assumptions:
R - The number of attack packets reaching a DNS server per second
The value 15,000 was used for DNS servers not protected by an IPS based upon Mueller's assumptions.
The value 0.1 was used for DNS servers protected by a IPS because the effect of the technique reduces the number of attack packets reaching a DNS server to this value.
P - The effective number of ports used by a DNS server
The analysis assumes that unpatched DNS servers will only use 1 port
The analysis assumes that patched DNS servers will use all 64,000 unprivileged ports.
N - The number of Authoritative DNS servers per domain
The value 2 was chosen because at least two DNS servers per domain are required by DNS RFCs, and it also represents the scenario most vulnerable to a Kaminsky attack.
The analysis shows:
As with most network designs, there are considerations associated with a design that includes the NitroSecurity Kaminsky solution. These considerations are enumerated and discussed below. Kaminsky Flood Protection If an attacker floods a DNS server with nefarious DNS response traffic, consistent with a Kaminsky attack, the NitroGuard IPS will blacklist most of the flood traffic, thereby reducing the load on the protected DNS server and allowing it to maintain DNS responsiveness.
Because a top-level-domain Kaminsky attack looks just like any other Kaminsky attack to NitroSecurity's solution, the solution provides equally effective protection from this very dangerous aspect of the Kaminsky vulnerability. The NitroSecurity IPS protects against both single domain attacks (e.g., google.com) and tld domain attacks (e.g., com) by using the same signature detections and blacklisting
One recommended method of reducing the risk of an exploit is to implement trusted, distributed resolution services such as those offered by OpenDNS. However, internal services are still at risk, and circumstances (availability, performance, etc.) may prevent some enterprises from using these services. NitroSecurity's proffered solution protects internal name resolution, as well as providing additional protection to those networks where outside DNS services are not feasible. NitroSecurity recommends using a service such as OpenDNS as a secondary or tertiary domain resolver, as a matter of best practice.
To prevent a Denial of Service of DNS resolution during an attack, the use of a trusted third party DNS server external to the NitroSecurity IPS is recommended. This is because, in some circumstances, legitimate name resolution may be impeded by the actions of the IPS. In these circumstances, normal "best practice" DNS configurations, including the use of trusted secondary and tertiary DNS using a 'trusted authoritative source' will provide failover resolution capabilities, assuming the proper configuration of such a facility in the local resolver. The use of a distributed system such as OpenDNS is recommended for external name resolution.
The NitroSecurity solution alerts, via the NitroView Enterprise Security Manager (ESM), network security personnel of any attacks and provides the information necessary to address the attacks, and to take further action, as necessary.
