Slashdot Log In
Attack Code Published For DNS Vulnerability
Posted by
samzenpus
on Wed Jul 23, 2008 06:38 PM
from the protect-ya-neck dept.
from the protect-ya-neck dept.
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."
Related Stories
[+]
Kaminsky's DNS Attack Disclosed, Then Pulled 281 comments
An anonymous reader writes "Reverse engineering expert Halver Flake has recently mused on Dan Kaminsky's DNS vulnerability. Apparently his musings were close enough to the mark to cause one of the Matasano team, who apparently already knew of the attack, to publish the details on the Matasano blog in a post entitled 'Reliable DNS Forgery in 2008.' The blog post has since been pulled, but evidence of it exists on Google and elsewhere. It appears only a matter of time now before the full details leak."
Reader Time out contributes a link to coverage on ZDNet as well.
Submission: Attack Code Published for DNS Vulnerability by Anonymous Coward
[+]
Patch DNS Servers Faster 145 comments
51mon writes "Austrian CERT used data from one of their authoritative DNS server to measure the rate at which the latest DNS patch (source port randomization) is being rolled out to larger recursive name servers. While about half the traffic (PDF) they receive is now using source port randomization, their data suggest that this is due to ISPs who roll out such fixes immediately. The rate of patching has fallen to disappointingly low levels since. If your ISP isn't patched, perhaps it is time to switch." After details of the DNS vulnerability leaked, researchers |)ruid and HD Moore released attack code; ZDNet's security blog has an analysis.
[+]
Apple Still Has Not Patched the DNS Hole 296 comments
Steve Shockley notes an article up at TidBITS on Apple's unexplained failure to patch the DNS vulnerability that we have been discussing for a few weeks now. "Apple uses the popular Internet Systems Consortium BIND DNS server, which was one of the first tools patched, but Apple has yet to include the fixed version in Mac OS X Server, despite being notified of vulnerability details early in the process and being informed of the coordinated patch release date."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Here we go... (Score:4, Interesting)
This has to be the worst time ever to be a web surfer. How long until we see the major networks broadcasting the legit IP quads of sites we want to reach?
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.
Parent
Re:Here we go... (Score:5, Interesting)
You may still not be safe. If someone can fire off a XSS attack through your browser, it could do enough lookups to make you vulnerable. Combine this with a periodic other run to a controlled server to grab your source port for guessing (presuming that you have not patched), and you may have a problem.
Granted, it's unlikely that you would explicitly be targeted, and things like NoScript help defend against it, but there are still possible gaps. In fact, there are several tens of million of systems which will remain vulnerable for some time to come; I haven't seen many SOHO router firmware fixes released so far, and a lot of people point to their routers for their DNS.
Parent
Re: (Score:3, Informative)
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.
Parent
Re:Here we go... (Score:5, Insightful)
Yes, there was. Before there was bailiwick filtering, spoofing was even easier. Back in the days, DNS servers would even accept "responses" with bogus data out of the blue. We've come a long way and we don't stop here. A patch of bad weather is ahead, but the sky is not falling.
Parent
Re:Here we go... (Score:4, Insightful)
I guess this is just a wake up call that if you find such large flaws in network systems that could possibly affect millions, if not billions of users, that you should try to get the word out and get the products fixed beforehand.
Parent
Re: (Score:3, Informative)
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."
Parent
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.
Parent
Re: (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).
Re: (Score:3, Insightful)
This has to be the worst time ever to be a web surfer.
Ummm... No. Today I can easily surf the 'net with just about every ad blocked, have Flash blocked when I want it to, but re-enable it for say, YouTube, all at the click of a mouse. I can use an OS and browser that is free and open source. I can surf 100% anonymously easily. I can download every video game I played as a child in less than an hour. And I can hear just about any song I ever would want to hear in less than a minute.
Sure, some things suck today, BT throttling, the ISP's "No-Usenet" crusade
Re:Here we go... (Score:5, Funny)
"And I can hear just about any song I ever would want to hear in less than a minute."
Shit, you should check out some of the songs that are longer than a minute, there's some good ones out there, but, yes...those quick little punk ditties are good too.
Parent
Re: (Score:3, Funny)
Re:Here we go... (Score:5, Interesting)
lol... you should try it, then you wouldnt think so... I just did (in Sound Forge)... cut it down to 1:08, its just noise... cutting it down to 50% is alright though (4:35)... but somewhere around 65% (5:57) is about right, sounds kinda "proper".
Parent
Re:Here we go... (Score:5, Funny)
kthxbye
Parent
Re:CONFIRMED: Steve Jobs has AIDS !! (Score:4, Funny)
Parent
Google (Score:5, Funny)
The Book Of Internets, Chapter Three, Verse Twelve (Score:5, Funny)
Re:The Book Of Internets, Chapter Three, Verse Twe (Score:5, Informative)
Parent
Re:The Book Of Internets, Chapter Three, Verse Twe (Score:4, Insightful)
Um... even if you run your own caching server, if your ISP runs a "transparent" web proxy it will do its own dns. You may in fact run DJB which is immune from this bug, but if your ISP runs an unpatched dns server you'll still be scrod despite running your own caching server.
Slick huh?
They need to take the dns lookup out of the web proxies.
Parent
Re:The Book Of Internets, Chapter Three, Verse Twe (Score:4, Insightful)
They need to take the dns lookup out of the web proxies.
The problem with doing that would be that it would then be impossible (at least using current DNS software, as far as I know) to allow clients on an internal network to have limited internet access without allowing them to perform DNS tunneling (and thereby upgrade their internet access to "full").
Once someone (anyone?) releases a DNS package that allows firewall-style rules (e.g. "client on this range of IPs may only resolve subdomains of the following domains...", "clients may only look up X distinct subdomains each of Y domains every Z hours" then the picture would probably change.
Parent
BIND 9 named views for access control (Score:4, Interesting)
Once someone (anyone?) releases a DNS package that allows firewall-style rules (e.g. "client on this range of IPs may only resolve subdomains of the following domains..."
I think you might be able to do that with the "views" feature of ISC BIND v9 named, although I've never tried. I know you can define ACLs for clients and control how they see the DNS using the ACL. You should be able to define forwarding zones for the domains you want to work, and blackhole everything else. I think.
http://www.isc.org/sw/bind/arm93/Bv9ARM.ch06.html#view_statement_grammar [isc.org]
Parent
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.
Parent
Re: (Score:3, Insightful)
Yes, DJB "recognized" the problem by lobotomizing DNS, and he refuses to consider what will solve the problem once and for all, DNSSEC. Right...
I know (Score:4, Funny)
I exploited this and let a huge cache of people visit my site(127.0.0.1) in stead of the site they wanted to go. It was kickass.
Re: (Score:3, Funny)
HAHA, fool! now that I know your ip address, I shall soon hack you into oblivion!
Re:I know (Score:5, Funny)
Don't worry, I just disabled his intern
[CARRIER LOST]
Parent
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: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]
Parent
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]
Parent
Re: (Score:3, Interesting)
Re:See if you're vulnerable (Score:4, Informative)
So.. What's their IP?
It looks like 66.240.226.139 to me...
Parent
More edifying than TFA's script (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 ...
help all the SOHO router people (Score:3, Interesting)
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.
Parent
NAT routers (Score:4, Informative)
Simply patching your DNS server may not be enough.
Re:And the "fix" isn't (Score:4, Interesting)
The fix is DNSSEC.
Parent
Re:And the "fix" isn't (Score:5, Interesting)
DNSSEC is a steaming pile, though after thirteen years, many RFCs -- each of which read "This Time For Sure!" -- it may in fact be workable.
It is _a_ fix to this problem, but there are many simpler fixes that seemingly are being discarded for reasons I don't quite understand -- perhaps more full threat models are the target problem, but securing DNS doesn't make sense if we're then going to use HTTP to the addresses resolved! On the flip side, if we were using TLS everywhere, then dicking with DNS amounts to a DoS, which is much less powerful than the arbitrary redirection attacks we have now.
One such simpler fix is using EDNS0 to add a nonce RR (goes out in the Query, comes back in the Additional section). And while EDNS0 is subject to rollback attacks, DNSSEC depends on EDNS0. So that's not an excuse not to use it.
Parent
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]
Parent
Re: (Score:3, Funny)
Re: (Score:3, Insightful)
No, but it's a "feature" that makes the attack possible. Turn it off, or make it stricter, and the attack falls apart.
Re:DNS Glue poisoning was already known... (Score:5, Insightful)
Congratulations, you confused the mods. Bailiwick checking was added to all DNS resolvers in response to glue poisoning and made cache poisoning through spoofed glue records very difficult. The current problem is that the typical filter rules are insufficient for stopping a glue poisoning attack which appears to come from the authoritative server: Kaminsky found a way around the glue poisoning countermeasure. This means that a very dangerous kind of attack which was thought to be defeated is now possible again.
Parent
Re: (Score:3, Insightful)
Read the quotation again...
Emin Gun Sirer: "Glue should be trusted for only the lookup in question[Emphasis added] for only the duration of that lookup.
This says "No Bailiwick checking at all": glue (additional) records should NEVER be cached. Period.
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.
Parent
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.
Parent
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]
Unclear on the concept (Score:3, Insightful)
Oh noes, the world is going to crash down around us! Just saying, why overreact?
A problem you ignore will have full impact. A problem you prepare for and take counter-measures against is prevented from having a serious impact. That's the whole point.
We spent great effort fixing Y2K bus, thus prevented the bugs from causing serious damage. Therefore, you conclude, we should not have fixed the Y2K bugs.
I guess, since seat belts have saved lives, we should not wear them.
Get it now? :-)