Secure Computing: Sec-C

I had a very informative phone call with Comcast this afternoon. According to Comcast, they had patched many of their servers, and for acceptable reasons (which I will not disclose), they consciously chose not to patch some servers but will have them patched shortly.

Attack Methods

There are 3 things needed to exploit a DNS cache poisoning attack.

1. You need to predict the source port.
   
2. You need to predict the transaction ID.
   
3. You need to respond faster than the legitimate response.
   With some DNS server, there is a forth optional item that makes it much easier to perform the exploit. However, this is not required:
   
4. A DNS server that accepts multiple responses.

The general class of DNS cache poisoning attacks works by knowing when a request will be made (usually by triggering the query yourself), guessing the source port and transaction ID, and sending back a false reply before the real server can respond. If the source port is chosen poorly (i.e., sequentially or static port number) and the transaction ID is predictable, then an attacker usually only needs to send one packet, or a few packets (depending on the predictability).

In a blind attack, the attacker sends a flood of packets that cover a range of ports and transaction IDs.

In the attack method Dan Kaminsky identified, the generalized attack is simplified. (Wait for Dan to give the full details in less than two weeks.)

Detecting Vulnerable Servers

The biggest issue about whether a system is vulnerable ("POOR") depends on the metric. The system used by DNS-OARC (including the dig test most people use) scans for two items: a well-randomized source port selection, and well-randomized transaction ID. If either the port or ID selection is poorly chosen, then the DNS server is vulnerable to a cache poisoning attack. Thus, the "POOR" rating.

NOTE: The "Check My DNS" test found at doxpara.com uses an alternate test.

In the case of the disclosure made by Matasano (blog pulled but mirrors exist) and Dan Kaminsky, the attack is simplified. Insiders to the full details are not necessarily patching against the general cache poisoning attack, but are patching against the attack that Dan found.

Keep in mind: a full DNS cache poisoning can require dozens of packets; a blind attack can require tens of thousands of packets. In effect, Dan found a new way to exploit an existing problem faster. (I'm still not convinced that the attack is new. But as NBC used to say, "If you haven't seen it, it's new to you!") However, the full details have not yet been made public (wait for Black Hat!); there may still be interesting twists to this problem.

Already, exploits are being released. These exploits are based on Halvar Flake's and Matasano's speculation on the full problem, and not on Dan's full disclosure. Some of these exploits seem aimed more at the general cache poisoning attack and not necessarily Dan's attack method.

As it turns out, the mitigation method for the general DNS cache poisoning attack (random ports and random transaction IDs) is a great solution to Dan's attack. However, it is not the only solution.

To summarize: Even if a site gets a "POOR" rating against the general DNS cache poisoning attack, it may still be patched against Dan's method. This is where Comcast comes in. Their DNS software provider, Nominum, has patched against the method Dan identified. However, their solution is not necessarily optimal against a general DNS cache poisoning attack. Then again, if they see a flood of DNS response packets (responding to questions that they never asked), then they can take other steps to mitigate the attack.

Poor DNS

In my last blog posting, I identified a number of ISPs that tested "POOR" on many of the available public tests. Here's how they round out now:

• Comcast. Their customer-facing DNS servers are patched against Dan's attack method. However, some of their servers still test "POOR" against generalize DNS cache poisoning attacks. As I mentioned, Comcast does have a few DNS servers that were intentionally not patched (and I agree with the rational). I am convinced that they will be patched shortly.
  
  
• Adelphia. (This one makes me laugh, for many reasons.) Basically, the Adelphia servers are managed by Road Runner. The ones that I identified as actually being associated with Comcast had other problems (I won't provide details here). It is sufficient to say that Comcast gave me a warm "thank you" for pointing out the problem. It has now been fixed; that's why those two servers no longer respond to the dig test. Meanwhile, the actual Adelphia servers (Road Runner) are not yet patched. [Update 29-July-2008: Still reports 'POOR'.]
  
  
• Level3. (This one also makes me laugh.) The Level3 servers were not patched when I wrote my blog entry (21-July-2008), but appear to have been patched now. However, their patch solution is only against Dan's attack method; it is a "FAIR" (not "GOOD") solution to the general DNS poisoning issue. [Update 29-July-2008: Reports 'GREAT'.]
  
  
• Level3 and Verizon. Meanwhile, the reason that I called these servers both "Verizon" and "Level3" was because the WHOIS information for the IP addresses matched Level3, but the WHOIS for the associated hostname matches Verizon. As one commentor wrote, "If that isn't good enough, wait a bit and recheck the WHOIS information." (I haven't seen the change yet, but I'm still looking.)
  
  This was followed by an email from a Verizon representative, who wrote:
  

  I suspect that our failure to clean up the legacy domain registration information for gtei.net is the reason you've attributed these to Verizon as well. Verizon and Level 3 are discussing cleaning up that registration information.

  
  It can be difficult to find the actual owner of an IP address. I usually go by WHOIS records for both the subnet (IP address) and domain name. However, the problem with Verizon/Level3 -- where a WHOIS records does not correctly identify the owner -- is not isolated to Verizon/Level3. It seems that Dan's DNS announcement has made many other people take a closer look and is turning up everything from bad server configuration to forgotten servers to out-of-date WHOIS entries.
  
  For clarity: The servers I had listed were Level3 and not Verizon (even though the WHOIS said otherwise).
  
  
• SBC/AT&T. "Bitmage" wrote in to say that SBC/AT&T may be misclassified as "GOOD". Depending on where you are located, they direct you to different DNS servers. The ones that I tested were "GOOD"; the ones Bitmage tested were "POOR". I suspect that SBC/AT&T has many DNS servers, and not all have been patched.
  
  
• Earthlink and Suddenlink. Both are now reporting "GOOD". They appear patched.
  
  
• Other ISPs. I have not yet heard from BTInternet, Sprintlink, Tmnet Streamyx, Xtra, Bellsouth, and Wave Broadband. Unless I hear otherwise, I can only base my evaluation on the test against the general cache poisoning attack: these systems are vulnerable. [Update 29-July-2008: Bellsouth reports 'GREAT', Wave Broadband reports 'GREAT', and Tmnet is not longer accessible. All others still report 'POOR'.]

To summarize: Systems that test as "GOOD" really are good; they are either patched or were never vulnerable. Systems that test as "POOR" are vulnerable to the general DNS cache poisoning attack method; unless they say that they are patched against Dan's method, don't assume that they are.

Finally, I am feeling some degree of schadenfreude. The sheer number of DNS servers that companies forgot that they had, forgot to update, forgot to maintain, or simply have incorrect WHOIS entries is startling. I cannot wait until we start looking closer at web servers...

Update 26-July-2008: I've received reports that LogicSouth (a regional ISP) is fine (they reportedly run PowerDNS and are not vulnerable).

I've also received four more reports from AT&T users in parts of Eastern and Southern United States that are testing "POOR". AT&T's status ("GOOD" or "POOR") seems to be regionally specific. The "POOR" seems to start in North Carolina and goes south through Georgia. The "GOOD" has been found in Colorado, New York, and the New England area.