Attack Code Published For DNS Vulnerability 205
get_Rootin writes "That didn't take long. ZDNet is reporting that HD Moore has released exploit code for Dan Kaminsky's DNS cache poisioning vulnerability into the point-and-click Metasploit attack tool. From the article: 'This exploit caches a single malicious host entry into the target nameserver. By causing the target nameserver to query for random hostnames at the target domain, the attacker can spoof a response to the target server including an answer for the query, an authority server record, and an additional record for that server, causing target nameserver to insert the additional record into the cache.' Here's our previous Slashdot coverage."
Re:The Book Of Internets, Chapter Three, Verse Twe (Score:5, Informative)
Re:The Book Of Internets, Chapter Three, Verse Twe (Score:5, Informative)
unpatched websites
Have you been following this story. It's not sites that need the patch, it's DNS servers. Site owners are powerless if the ISPs fail to protect their domain name from the an entry leading to the spoof site's IP address.
DNS Glue poisoning was already known... (Score:2, Informative)
The interesting thing, DNS glue (additional) poisoning WAS known, just not widely. EG, the SECOND hit for "dns glue poison" in Google gets http://lists.oarci.net/pipermail/dns-operations/2006-May/000537.html [oarci.net].
Quoting Emin Gun Sirer:
Incidentally, the client should be wary of trusting glue records unconditionally, as they are non-authoritative. A well-known cache poisoning attack works by tricking clients to believe glue records for all time and for all queries. Glue should be trusted for only the lookup in question for only the duration of that lookup. We'll assume that the clients treat glue properly (even though many do not).
Thus it was already known, two years ago, that trusting Glue records is "well-known cache poisoning attack". Just apparently, not well known enough by the authors of Bind, Microsoft's DNS server, Cisco, etc.
Re:Here we go... (Score:5, Informative)
There's nothing new about this. DNS cache poisoning attacks have been found before, and the internet hasn't melted down yet. If you're paranoid, run your own caching resolver.
See if you're vulnerable (Score:5, Informative)
There's a tool on the site below that apparently checks if the DNS you're currently using is vulnerable to such an attack. I checked my work DNS and my home DNS - both were fine. Apparently OpenDNS is secure as well, so there's probably nothing to worry about.
http://www.doxpara.com/ [doxpara.com]
Re:I can't contact ftp.debian.org this last 2 days (Score:4, Informative)
try http://ftp.debian.org/ [debian.org]
for a bit more info:
http://wiki.debian.org/ftp.debian.org [debian.org]
Re:See if you're vulnerable (Score:5, Informative)
The DNS OARC (http://dns-oarc.net) has an improved version:
http://entropy.dns-oarc.net/test/ [dns-oarc.net]
Re:See if you're vulnerable (Score:2, Informative)
Re:See if you're vulnerable (Score:4, Informative)
So.. What's their IP?
It looks like 66.240.226.139 to me...
More edifying than TFA's script (Score:3, Informative)
Re:DNS Glue poisoning was already known... (Score:5, Informative)
It only works because the DNS server caches the result of the glue record, against the recommendation of the above writer.
The glue record is necessary if, say, you need to provide the address of a nameserver when you provide the name of the authoritative nameserver for a query. You should use that glue record for that query only.
What happens is that an attacker queries lbixds.google.com (or some other nonexistent domain) and then sends the server he issued that request to a response to that query that also has a glue record giving a false address for ns.google.com. If the DNS server only used that false address for resolving lbixds.google.com, cached lbixds.google.com, and left it at that, then lbixds.google.com would be the only entry the attacker could poison -- basically useless. However, the DNS server caches the glue record giving the address for ns.google.com, too.
Re:Here we go... (Score:3, Informative)
You can run your own recursive resolver which only talks to authoritative DNS servers. You can configure it to use random source ports if you want to make this attack much more difficult. Then an attacker would have to send you billions of spoofed packets to poison your DNS. That seems a little excessive for exploiting just one user. You could make it even more difficult by rate limiting your resolver (you're its only user after all).
BIND is not a demon (Score:3, Informative)
it's an acronym for "Berkeley Internet Name Daemon"
Actually, BIND stands for "Berkeley Internet Name Domain". Berkeley did the seminal work for the original DNS implementation, and that's what they called their idea. BIND is a suite which includes a stub resolver, some utilities, and named (name daemon). (Along with some other stuff, now.)
If you want to get fancy, "ISC BIND named" is the proper name of the software we're talking about. ISC is the company, BIND is the product, named is the program.
See: http://www.isc.org/sw/bind/index.php [isc.org]
Re:Here we go... (Score:3, Informative)
Re:Here we go... (Score:3, Informative)
Use OpenDNS if your ISP is vulnerable (Score:5, Informative)
I used one of the tests below and found that my ISP's DNS servers were vulnerable. Now I am using the OpenDNS [opendns.com] servers on all of my clients instead:
208.67.222.222
208.67.220.220
Their servers are not vulnerable, and you can create an account to enable things like antiphishing at the DNS level (much better idea then a browser plug-in).
If you find that your ISP's routers are vulnerable, your best bet is switch to OpenDNS...or just run your own caching server.
Microsoft's hamfisted "patch" (Score:5, Informative)
In case anyone is dumb enough to use a Microsoft DNS server as a authoritative internet DNS server -
MS has released two lovely patches -
KB951746 and KB951748
The problem with this fix is that it turns the DNS.EXE daemon into a UDP socket grubbing whore.
After the patch, the DNS.EXE daemon grabs no less than 2500 freaking UDP sockets.
This wreaks havoc on anything that - you know - needs UDP sockets on the same server.
So far Zonealarm, Blackberry BES and Sphericall VOIP software all break with this "patch"
Stay tuned for more fun to come ...
Re:Here we go... (Score:4, Informative)
Yes - go read Amit Klein's papers on trusteer.
Sending only a handful of more carefully calculated responses is also more likely to succeed if the victim is using mitigation techniques such as rate throttling.
Even using source port randomization doesn't help as much as a lot of people think. You don't get one 32-bit PRNG, you get 2x 16-bit PRNGs. Each of these can be attacked separately. If you could narrow each of these down to 10 likely guesses, you only have to send 100 replies.
Re:help all the SOHO router people (Score:3, Informative)
Generally the proxy on a SOHO router runs as a forward-only cache (or even just a simple proxy) to your ISP's DNS. As such it's really your ISP's DNS that is or isn't vulnerable, because you aren't ever going to see records from anyone else, nor will anyone else know you're asking for them.
The test listed above -- http://entropy.dns-oarc.net/test/ [dns-oarc.net] -- will let you know what the rest of the world sees as your DNS source address, and whether or not that source is sufficiently randomized.
NAT routers (Score:4, Informative)
Simply patching your DNS server may not be enough.
Re:Here we go... (Score:5, Informative)
Where I work, we run the servers through a proxy firewall with a DNS proxy service, and the DNS service on the firewall has been patched for this vulnerability. For traffic run through it, it doesn't preserve source port from the DNS servers, and from a quick glance, the source ports on requests seem to be randomized, so I think from that perspective, we may well be safer even for unpatched servers. However, our setup seems to be the exception, and we may have a couple of other networks (physically and logically separated from the primary) that do not have the benefits of this arrangement.
Re:DNS Glue poisoning was already known... (Score:5, Informative)
So, first part. An attacker is trying to poison a DNS cache. Generally, he'd be interested in poisoning a DNS server that's a caching server for a group of people, like one run by a regional ISP. An efficient way of getting a poisoned record into its cache is to issue a request to that server, and then immediately send a forged response to the server. So, for example, I issue my local nameserver a request for abcd.google.com. It doesn't have this cached (you don't say!), so it starts trying to resolve it. I quickly send it a forge response for abcd.google.com, and it believes me. Transaction IDs make this a slim chance that it'll believe me, but it's still a chance, and I can issue a ton of requests to different fake addresses.
The answer to the second part is tricky. Basically, say I want to resolve mail.google.com. I have nothing about google.com in my cache. So I contact the nameserver for .com. It isn't authoritative for the google.com domain, but it knows who is, and it tells me so. (Say that it's ns.google.com.) Knowing ns.google.com is the nameserver for that domain is useless without its IP address, so it tacks on a glue record that gives me the address of ns.google.com. Now I can contact ns.google.com to ask it the IP of mail.google.com.
Originally, these records were just accepted. This is a huge security hole: I could request bob.domainiown.com, send a legitimate response (I control domainiown.com), and tack on a record telling them where ns.google.com is, even though I'm not authoritative for that. Now, such a record can only be attached to a request that is in the same domain, so I need to ask for bob.google.com to attach an ns.google.com record, which requires me to forge a response.
There are a number of situations where these auxiliary records are necessary, so they can't just be ignored. However, they shouldn't be cached -- they should be used only for the one request that generates them.
Re:help all the SOHO router people (Score:4, Informative)
Most of these routers don't run caching, recursive resolvers -- they just forward the request to your ISP's DNS server. As such, they are immune.
Test your own server (Score:5, Informative)
A Google search revealed this way to test specific DNS servers from the command line (in case you're using a DNS server other than the one that's authoritative for the netblock you're in):
Good:
$ dig +short @208.67.222.222 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.
"208.67.222.222 is GOOD: 26 queries in 0.1 seconds from 26 ports with std dev 17746.18
Poor:
$ dig +short @206.13.28.12 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.
"206.13.28.13 is POOR: 26 queries in 0.2 seconds from 1 ports with std dev 0.00"
More discussion on this method here:
http://www.dslreports.com/forum/r20759262-CERT-VU800113-DNS-Cache-Poisoning-Issue~start=20 [dslreports.com]
Re:DNS Glue poisoning was already known... (Score:3, Informative)
Maybe it wasn't clear, but I was going to echo nweaver's reply:
djbdns's total lack of support for glue records (IIRC) is one of the reasons it's one of the few old dns software not vulnerable. And that's the point I was trying to drive: the glue records feature made the cache poisoning possible -- I just read the exploit code, and it uses Additional Section to inject the malicious entry. Without this feature, like in djbdns, the exploit wouldn't work.
Yeah, I should have said "don't cache glue records", not "make it stricter" mea culpa.
Re:Microsoft's hamfisted "patch" (Score:3, Informative)
ZoneAlarm breaks in the sense that it thinks Microsoft's new DNS resolver is behaving like malware and should therefore not be trusted. ZoneAlarm has a ridiculous little slider with three security levels marked "High", "Medium" and "Low"; if you set it to "High" (as recommended), you can't resolve DNS.
ZoneAlarm has released a patch to work around the problem. You can set your security setting to "Medium" while you download the update.
Re:Here we go... (Score:5, Informative)
Different vulnerability, that tool checks for non-random TXID, not this exploit.
This exploit changes the game in letting other exploits work well.
It's not so much a new class of attack, as a way to give you infinite chances to use the old attacks. If you don't have a IPS checking for this, an attacker who can submit recursive queries to your resolver and wants to poising your DNS will eventually be successful. Publicly available tools work in one minute, Dan says coding in C on a fast connection he's able to do it in 10 seconds.
Has DNS been broken this badly before? Yes, multiple times. However, the will and knowledge of how to use DNS cache poising for further evil is much higher now then it was in the past. Also, we are becoming increasingly dependent on the Internet, and attacks on the infrastructure do more then just keep us from our news sites.
As Dan says, "Patch. Today. Now. Yes, stay late."
Re:Here we go... (Score:3, Informative)
The best known unpatched attacks really had no upper bound. You got one chance to attack, then had to wait for the records to timeout before you could try again.(usually set from 1 hour to 1 week, depending on the service)
What this vulnerability does is give you infinite chances to attack with no delay, so you can try 1000 times a second if your connection is fast enough. If you can do that, you will win, and quickly.
The attacks themselves have not really changed, we can just use them much faster.
Re:Here we go... (Score:3, Informative)
Re:help all the SOHO router people (Score:3, Informative)
Mod parent up! Home broadband/WiFi routers may well be vulnerable unless you've specifically checked.
Unless you've checked the internals of your home router and whether it's using the wrong sort of DNS proxy/cache, I recommend *everyone* with a home router switches their client computers to using OpenDNS, so it's Windows/Mac/Linux directly requesting DNS services from OpenDNS. (If you have DHCP for your clients at least you only need to change the router, but any laptops should also explicitly use OpenDNS in case a WiFi hotspot has unpatched DNS.
Then you can take your time about updating the router firmware. I happen to run DD-WRT and this doesn't yet have a patched version of dnsmasq - for some reason the author of dnsmasq wasn't included in the insider group that patched non-embedded OSes, Cisco/Juniper routers, DNS servers, etc.
Re:And the "fix" isn't (Score:3, Informative)
"DNSSEC is a steaming pile"...
Yes! Unfortunately this is completely and utterly true. Unlike many of the great crypto tools we have available to us (ssh, pgp, https), DNSSEC increases complexity by an order of magnitude.
Watch as you lose the ability to effectively block full zone transfers from your domain name since DNSSEC requires NSEC records, which are essentially a linked list of all your zone entries!
Be amazed when you find out that you need to run a cron job to sign all of your zone files every 15 days!
Become aghast when you find out that you then need a second cron job, running on an alternate server, that runs a script that checks all your zone files for signature expirations.
Become horrified when you find out that a properly validating DNSSEC caching server will block domains with expired signatures with NXDOMAIN, since there were only four choices in the existing DNS protocol and that response was the least bad.
Smirk as you find out that virtually no one at all is using DNSSEC. Run `dig nsec $DOMAIN` against some well known DNS zones, and find that practically no one (except for the ISC) is using it.
Since there are political problems with the key signing heirarchy, ISC is setting up an alternate place to put your higher level keys in their DLV registry. .com and .net are not going to be implementing DNSSEC.
I have gone through and encrypted everything I could on my servers recently. I attended a presentation by ISC about how great DNSSEC is. I came away convinced that it was a lot of hot air, and that ISC was trying to sell the Internet a bill of goods. DNS isn't perfect, but DNSSEC is a half baked solution that virtually no one wants, and I frankly can't ever see it ever becoming popular in anything approaching its current form. Not ready for prime time... back to the drawing board guys!