Did the DNS attacks begin? (part 2) - Fact or myth? Some facts. (updated x2)

I have seen a lot of reports on attacks on unpatched DNS Caching servers but with little or no (technical) information. A lot seems to be based on the email posted on the Fedora mailinglist by user James Kosin. (see Did the DNS attacks part 1)

The logs he provided were not signs of exploitation, but it was a indication of a scan for open resolving dns servers. An increase of DNS scanning has been reported by Arbor Networks in their "30 Days of DNS Attack Activity" post of the 28th of July.

Plotting UDP/53 attack activity (the thicker dark “pinkish red” line below) across Arbor’s “anonymous statistics program” participants (~70 ISPs) illustrates an order of magnitude increase in UDP/53 and/or DNS events beginning around July 9, 2008. Note that while most of the data from the anonymous statistics program is based on Network and Transport layer attributes of traffic, there are specific DNS capabilities that exist in our Threat Management System (TMS) product that deal extensively with payloads as well. Given that this vulnerability was partially disclosed on July 8, I suspect a great deal of this traffic is name server vulnerability scanning, as opposed to malicious cache poisoning attempts, although there may well be a mix of the latter.
...
One other interesting observation is that most of the activity we’ve seen thus far kicked off in conjunction with the disclosure itself, although there is a perceptible activity level increase just subsequent to the 13-day “leak” as well. This could be more vulnerability scanning, although it could also be actual cache poisoning attempts, and given that several exploit tools are now openly available, I don’t expect this to improve any time soon. (Source: Arbornetworks)

So still no conclusive proof there. But if you look at the graphic from Arbornetworks, the increase in DNS scanning since the 8th of July is concerning. Also the small difference after the 13-day leak is an indication of some kind.

Now, the metasploit exploit needs a service to determine the source port used by the target name server. The 'check' command does just that. The exploit itself will also query the Metasploit service if you set SRCPORT to 0. So no information is sent to metasploit.com unless SRCPORT is manually set to '0' or the check command is run (non-standard for aux modules). (Source: HD Moore on the Full Disclosure mailinglist). For more information, check the entire post.
So, it's useful to know that in some case, the metasploit tool will report information back. Now let's look at this Twitter message from the 24th of July:

HD Moore: About 75% of the folks checking exploitability via metasploit module are vulnerable. (

05:47 PM July 24, 2008)

So this is telling us that people were testing this tool and most of the DNS servers they were tested on were vulnerable (24 June) . This is not a good sign of course. But it doesn't proof malicious activity. Until I saw the following message on Twitter:

HD Moore: is happy that dns1.austtx.sbcglobal.net is no longer cache poisoned for www.google.com (it was serving ads). Too bad its still not patched. (July 29, 2008)

Oh. At least I hope it were not infected ad images or javascript injected pages as well. So I think the above gives enough indication to be sure that there is a rising problem. There is still a lot of inconclusive information out there. If you have some logfiles or indications of live attacks yourself, please report them. Surfing to www.google.com and seeing ads instead of a search engine is a clear sign.

UPDATE: As a result of the SBC/ATT DNS servers getting poisoned, HD Moore has added a module in Metasploit to compare the cache of two DNS servers. (/UPDATE)

Patching is in progress, but as Dan Kaminsky said. Patching is not the final solution. It only makes the exploit a lot harder. There is still a 1% change each hour to succeed in cache poisoning. There is a fierce discussion going on in the comments of the latest Bruce Schneier post: "The DNS Vulnerability". The article itself makes a good point that by having design security in the system in the first place, we wouldn't need the patch. I recommend to read it including the comments.

So again, advice for syadmins how can you detect this attack? Look for this kind of patterns in your logfiles:

deniedJul 27 18:42:37 local@ named[19501]: client attacker#53264: query (cache) eZ3bMrUqAEBBjNFH.net/A/IN'
deniedJul 27 18:42:37 local@ named[19501]: client attacker#53264: query (cache) eZ3bMrUqAEBBjNFH.net/A/IN'
deniedJul 27 18:42:37 local@ named[19501]: client attacker#53264: query (cache) eZ3bMrUqAEBBjNFH.net/A/IN'
deniedJul 27 18:42:37 local@ named[19501]: client attacker#53264: query (cache) eZ3bMrUqAEBBjNFH.net/A/IN'
deniedJul 27 18:42:37 local@ named[19501]: client attacker#42398: query (cache) AyQDrLbwlI9fHEIg.net/A/IN'
deniedJul 27 18:42:37 local@ named[19501]: client attacker#42398: query (cache) AyQDrLbwlI9fHEIg.net/A/IN'

Or you can have a look at research described in Jose Avila's Recursive DNS Cache Auditing presentation in addition to the ONZRA security research tool CacheAudit v.01, see the Research folder at ONZRA for the CacheAudit download. Scan for udp/tcp port 53 in your network and check and patch the servers asap. Even if they are internal servers.

Advice for endusers: use the DNS tool on the doxpara.com website or the webbased tool from DNS-OARC. If it appears, you are using an unsafe DNS server, switch to openDNS. Here are the instructions.

I'm also considering how this can affect hotspot users and similar mobile users in combination with tools like Evilgrade or Karmetasploit. Even without this DNS exploit, both toolkits used on untrusted LANs of WLANs can be dangerous. But that is for another post.

UPDATE: Zero Day just posted a similar article that additionally includes some interesting DNS Security Surveys from the past. Check it out.

UPDATE (30/07/2008): Brian Krebs from the Washington Post just wrote an article on Evilgrade and hotspots. It seems that iTunes and Mac OS updates were fixed in december '07. Read here for more info.

FINAL UPDATE (30/07/2008): HD Moore has put some more details in a post on Metasploit on what happened. The enemy has entered the gate now and is inside.

Previous posts:

• Poor software update mechanisms and DNS Cache Poisoning: a wicked combo by the Evilgrade Toolkit
• Did the DNS attacks begin?
• Recorded Blackhat webcast with Dan Kaminsky now online
• Microsoft Security Advisory (956187): Increased Threat for DNS Spoofing Vulnerability
• Govcert.NL publishes "The Kaminsky Code" Factsheet
• Short Review of Blackhat DNS Webinar with Dan Kaminsky
• Metasploit releases DNS cache poisoning exploit (part 2)
• Metasploit releases DNS cache poisoning exploit (part 1)
• NOW is the time to patch those unpatched DNS servers. Details have leaked. (updated)
• Dan Kaminsky Blackhat Webcast on the DNS vulnerability on the 24th of July (updated)

(Photo under Creative Commons from soldiermediacenter's Photostream)