It seems the cat might be out of the bag regarding Dan Kaminsky's upcoming presentation at Blackhat.

Since this now means the bad guys have access to it at will -I found the speculations using Google, I'm sure they have done so already-, the urgency of patching your recursive DNS servers just increased significantly. There seems to be some effort underway to put the cat back in the bag, but I strongly doubt that'll work.

To describe it for defensive use by those operating recursive DNS servers: The descriptions I found would make you look for signs of attack using this technique in DNS queries for significant amounts of nonexistent subdomains that try to poision the parent using a glue record.
Those operating authoritative servers should be able to monitor for increased/excessive queries into nonexistent names from a single source, but there's little they can do beyond trying to warn the operator of the recursive server.

Since I wasn't briefed by Dan Kaminsky, I've no way of knowing if the theories that are out there are in fact what was going to be presented at Black Hat, so it might still be different.

Still, while fixing this might not be so trivial, an upgrade or patch of all recursive DNS servers is what's really needed at this point. So if you were still waiting for an excuse, this one is it: PATCH NOW.
Take care as performance issues exist in e.g. BIND with some of the patched versions, and e.g. ISP operated recursive servers do take quite a bit of load ...

UPDATE 1:

• Please, do not jump to conclusions for every DNS problem out there, many more things can and do go wrong beyond this problem.
• The CVE name for this has many more links:  CVE-2008-1447
• There is a problem with recursive servers behind a NAT gateway: a good caching nameserver hidden behind a firewall or a router that's undoing the port randomisation leaves your server vulnerable.
• A test for nameservers is available, you can test those you run yourself or those given to you by your ISP to use as forwarders (if they are GOOD, use them!)
  e.g.:
  $ dig @IP-of-GOOD +short porttest.dns-oarc.net TXT
  z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
  "IP-of-GOOD is GOOD: 26 queries in 2.0 seconds from 26 ports with std dev 17685.51"
  
  $ dig @IP-of-BAD +short porttest.dns-oarc.net TXT
  z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
  "IP-of-BAD is POOR: 26 queries in 4.0 seconds from 1 ports with std dev 0.00"
   
• If seeking good forwarders when your ISP doesn't provide them, consider those of OpenDNS. Be aware it comes with other features as well.
• Using SSL (e.g. HTTPS) can be beneficial as it can detect man-in-the-middle but you must teach and train users to NEVER accept bad certificates, not even after they "validated" them manually (most of them won't be able to do the math to verify a digital signature in mental math (well at least I can't), and verifying the readable part isn't worth anything as that's the part where the signature failed on ...)
  The only "validation" to be done is to contact the other side out of band and verify the fingerprint of a self-signed certificate, but most users will just press "next" ... and feel the false sense of comfort by a lock and/or green bar.

UPDATE 2:

• Jacob mentioned dig might not be the easiest on windows users. They can use nslookup from the command line to do the test of e.g. their ISPs servers:
  
  $ nslookup -type=txt -timeout=30 porttest.dns-oarc.net
  $ nslookup -type=txt -timeout=30 porttest.dns-oarc.net IP-of-SERVER
  
  The output will be a bit more messy, just look for the word GOOD, FAIR or POOR (the statistics are still right behind that)

UPDATE 3:

• Increasing the urgency to patch even more: There is now a publicly available metasploit module that appears to be capable to exploit this vulnerability.
  
  Thanks to all who wrote this in.

UPDATE 4:

• A second module has been released for domains, which replaces the nameservers of the target domain. Unlike the first module which will not replace a cached entry, this exploit will do cache overwrites.
  
  See http://blog.wired.com/27bstroke6/2008/07/dns-exploit-in.html

UPDATE 5:

• Matt wrote in to announce Emerging Threats is offering a freely available snort signature for DNS servers. As always, test before using in critical production environments.

UPDATE 6:

• A reader wrote in regarding the signature from Emerging Threats: "For some reason it conflicts with the emerging-exploit fgdump rule so it was removed from the repo. Snort errors with a message about a conflict in a previous rule of a different protocol." So do take extra care ...
• A snort rule should already be available to those who subscribe to Sourcefire's VRT.

--
Swa Frantzen -- Section 66

Couple of readers wrote in to tell us about various different things they've noticed on their servers. While the attacks are "plain old" SQL injection attacks we've been writing multiple times about (see http://isc.sans.org/diary.html?storyid=4645) the latest development in those attacks definitely looks suspicious. Here's what's going on.

First of all, it appears that the attackers expanded their target list of applications so they try to attack Cold Fusion applications now as well (previously they tried to attack ASP scripts only). If you are running Cold Fusion applications, this should be a wake-up call for you – make sure that you are not vulnerable to SQL injection. If I remember correctly, Cold Fusion does have some built-in protection against SQL injection attacks but there are clearly cases when that does not work (otherwise the attackers would not be attacking it).

The logs to look for look like this:

GET /shared/cfm/image.cfm?id=125959';DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C…)

Notice that they changed the CAST()-ed string as well so it's not Unicode any more (works fine with CAST), but I'll get back to that later.

The other attack we got information about actually looked more interesting. The log file submitted by couple of our readers contained the following SQL injection command:

declare @q varchar(8000) select @q = 0x57414954464F522044454C4159202730303A30303A323027 exec(@q) --

This caught our attention since the encoded part was much shorter than previously. Anyway, as this is plain hexadecimal, it's easy to decode this. Just take the part after 0x and pipe it to the following perl command:

$ echo "57414954464F522044454C4159202730303A30303A323027" | perl -pe 's/(..)/chr(hex($1))/ge'
WAITFOR DELAY '00:00:20'

Interesting! So they are issuing the WAITFOR DELAY command. For those of you not into SQL, the WAITFOR DELAY command simply blocks the execution of the command for the period of time specified after the DELAY keyword (20 seconds in this case).

So what does this do? It's actually a very common way that is used by hackers when they are exploiting blind SQL injection attacks. The idea is to create a condition that, if satisfied, will delay the execution of the script for a certain time period. So, the attacker watches the response time and if it was delayed, he knows that the SQL command was executed successfully.

Here we're not talking about the blind SQL injection, but just a way to check if the script is vulnerable to SQL injection in general. So, the bot issues this command and checks the response time: if the reply came immediately (or in couple of seconds, depending on the site/link speed) the site is not vulnerable. If the reply took 20 seconds then the site is vulnerable.

This gives them an easy way to detect vulnerable sites and (probably) create a list of such sites that they might attack directly in the future. And the site owner will not notice anything (unless he/she is checking the logs).

Something big coming? I guess we'll have to wait and see.

Thanks to Justin and Tony for sending reports.
--
Bojan