Kaminsky's DNS Attack Disclosed, Then Pulled 281
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.
The push for DNSSec (Score:5, Interesting)
Kinda makes you wonder what they're getting out of it.
You can play with the search query (Score:3, Interesting)
Use Google search snippets to expose little details of the document...
I'm guessing some persistent folks will eventually be able to piece the bits together.
i.e. see how much you can piece together from the summary with the result shown by google. Adjust your search by including unique words towards the end of the snippet in one search to try to get the text that follows.
1 [google.co.uk]
2 [google.co.uk]
21 Jul 2008 ... One of them involves mucking about with the QID in DNS packets and the ... The QID is the only thing protecting the DNS from Mallory (me). ...
21 Jul 2008 ... If Mallory wins, the next 10000 or so people that ask that cache where WWW.VICTIM.COM is go to 6.6.6.0. 3. Then thereâ(TM)s that other set of ...
21 Jul 2008 ... Then thereâ(TM)s that other set of DNS vulnerabilities. ... Then letâ(TM)s set up an evil server with it, and register it as EVIL.COM. ...
21 Jul 2008 ... EVIL.COM, and watch how the QIDs bounce around; eventually, sheâ(TM)ll break the .... EVIL.COM and slipping strychnine into his ham sandwich, ...
21 Jul 2008 ... This will be Bobâ(TM)s unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice â" once when ...
21 Jul 2008 ... Which sends back a response with an unexpected (evil) Additional RR. ... Weâ(TM)ll come back to it. Alice has an advantage in the race, ...
21 Jul 2008 ... Alice has an advantage in the race, and so she likely beats Mallory. NXDOMAIN for AAAAA.VICTIM.COM. Aliceâ(TM)s advantage is not insurmountable. ...
21 Jul 2008 ... Aliceâ(TM)s advantage is not insurmountable. Mallory repeats with AAAAB.VICTIM.COM. Then AAAAC.VICTIM.COM. And so on. ..
21 Jul 2008 ... Frequently, that server has to go ask another, and so on. .... And so on. Sometime, perhaps around CXOPQ.VICTIM.COM, Mallory wins! ...
21 Jul 2008 ... If Mallory wins, the next 10000 or so people that ask that cache where WWW .... COM, Mallory wins! Bob believes CXOPQ.VICTIM.COM is 6.6.6.0! ...
21 Jul 2008 ... Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. ... Because her response didnâ(TM)t just say CXOPQ.VICTIM.COM was 6.6.6.0. ...
21 Jul 2008 ... COM was: 6.6.6.0. Every resolver that points to that name server will now ... COM to 6.6.6.0. Those records are in-bailiwick: Bob is in fact ...
I thought this wasn't the X attack from Y.. (Score:2, Interesting)
Use djbdns (aka tinydns) (Score:2, Interesting)
Use djbdns which is immune to this attack. Dan Bernstein actually described this in 2002 http://cr.yp.to/djbdns/res-disaster.html [cr.yp.to]
djbdns is not prefect but has been better than BIND which had it large share of bugs and security problems.
Re:The push for DNSSec (Score:3, Interesting)
Paul is an idiot and a douchebag. He's been lying to you for a long time to cover his own ass: BGP routes are filtered everywhere which means that not only do you have to break the port, and the sequence number, you also have to break the route filtering every AS is already doing.
Meanwhile, had BIND simply gone and removed the stupid ADDITIONAL-section processing like DJBDNS did, you wouldn't be having the described vulnerability.
Re:The push for DNSSec (Score:5, Interesting)
Not to be paranoid, but the argument of "no-one can do this" is often weak in the light of it being governments or intelligence agencies who are trying to mess with your internet access.
Is he scared of his government?
Or concerned about what his government may be doing to others in the world?
The problem is not necessarily on the "some attacker half way across the world on another AS", but may be much closer to home.
You can read it here (Score:1, Interesting)
Copy of DNS exploit details (Score:1, Interesting)
http://blogs.buanzo.com.ar/2008/07/matasano-kaminsky-dns-forgery.html
Re:I got this much (Score:0, Interesting)
Reliable DNS Forgery in 2008: Kaminskyâ(TM)s Discovery
from Matasano Chargen by ecopeland
0.
The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat.
1.
Pretend for the moment that you know only the basic function of DNS â" that it translates WWW.VICTIM.COM into 1.2.3.4. The code that does this is called a resolver. Each time the resolver contacts the DNS to translate names to addresses, it creates a packet called a query. The exchange of packets is called a transaction. Since the number of packets flying about on the internet requires scientific notation to express, you can imagine there has to be some way of not mixing them up.
Bob goes to to a deli, to get a sandwich. Bob walks up to the counter, takes a pointy ticket from a round red dispenser. The ticket has a number on it. This will be Bobâ(TM)s unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice â" once when he is called to the counter to place his order and again when heâ(TM)s called back to get his sandwich. If youâ(TM)re wondering, Bob likes ham on rye with no onions.
If youâ(TM)ve got this, you have the concept of transaction IDs, which are numbers assigned to keep different transactions in order. Conveniently, the first sixteen bits of a DNS packet is just such a unique identifier. Itâ(TM)s called a query id (QID). And with the efficiency of the deli, the QID is used for multiple transactions.
2.
Until very recently, there were two basic classes of DNS vulnerabilities. One of them involves mucking about with the QID in DNS packets and the other requires you to know the Deep Magic.
First, QIDs.
Bobâ(TM)s a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0.
It is a (now not) secret shame of mine that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part of poisoning DNS. If Iâ(TM)m Mallory and Iâ(TM)m attacking Bob, how can he distinguish my packets from Aliceâ(TM)s? Because I canâ(TM)t see the QID in his request, and the QID in my response wonâ(TM)t match. The QID is the only thing protecting the DNS from Mallory (me).
QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, hereâ(TM)s a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses. Mallory sends a constant stream of DNS responses for WWW.VICTIM.COM. All are quietly discarded â"- until Mallory gets Bob to query for WWW.VICTIM.COM. If Malloryâ(TM)s response gets to your computer before the legitimate response arrives from your ISPâ(TM)s name server, you will be redirected where Mallory tells you youâ(TM)re going.
Obvious fix: you want the QID be randomly generated. Now Alice and Mallory are in a race. Alice sees Bobâ(TM)s request and knows the QID. Mallory has to guess it. The first one to land a packet with the correct QID wins. Randomized QIDs give Alice a big advantage in this race.
But thereâ(TM)s a bunch more problems here:
*If you convince Bob to ask Alice the same question 1000 times all at once, and Bob uses a different QID for each packet, you made the race 1000 times easier for Mallory to win.
*If Bob uses a crappy random number generator, Mallory can get Bob to ask for names she controls, like WWW.EVIL.COM, and watch how the QIDs bounce around; eventually, sheâ(TM)ll break the RNG and be able to predict its outputs.
*16 bits just isnâ(TM)t big enough to provide real security at the traffic rates we deal with in 2008. Your computerâ(TM)s resolver is probably a stub. Which mean
Re:The push for DNSSec (Score:1, Interesting)
Too bad DNSSEC sucks and causes new problems, like listing all the records in your entire zone whether you like it or not through a linked list of NSEC records. Don't forget to have a cron job to sign your keys every 15 days (they expire every 30 days), and then have another cron job on a separate machine check your keys for expiration if the first cron job fails. If you forget to do this, DNSSEC validating cache servers will give an NXDOMAIN as if your site doesn't exist.
I'm trying to implement cryptography everywhere I possibly can, but DNSSEC is just a boondoggle. Sorry ISC, I'm avoiding it like the plague until a real workable solution emerges.
It's okay... (Score:3, Interesting)
Even worse... (Score:3, Interesting)
Re:I thought this wasn't the X attack from Y.. (Score:2, Interesting)
Yes that's the right idea, but it seems that just changing this concept of a "balliwick" would solve the issue.
There's no legitimate need for your bogus "www.bankofamerica.com" RR to be accepted when you're asking about "xxffgg.bankofamerica.com."
It makes sense to accept it when you're simply asking about "bankofamerica.com"; that's how normal glue works, but you already have the information you need regarding the domain itself, so accepting more unsolicited information doesn't provide you with anything.
Servers only need glue when they're traversing the chain. Once they're at the level they need to be at, they should ignore any other records (glue or otherwise) that are sent.
Re:The push for DNSSec (Score:3, Interesting)
To be blunt, "the government" can crack your DNSSEC keys as well.
LAN security doesn't enter into it- if your cache is on the same machine, and you're using switched ethernet to the border, any remaining attack vectors "close to home" remain on the same level as transparent proxies and whatnot.
Where is your god then?
Subject lines tell me how to mod (Score:3, Interesting)
Interesting you say that. Whenever I get mod points, the subject line is one of the things I look at to see where to grant my mod points.
Reading every posting to see which ones are worth modding up would be too much work. I look for replies in a thread where the author has taken the effort to change the subject line from "Re:Re:Re:Re:Unoriginal First comment" to something relevant; these have a much higher chance of being insightful or interesting. The more concise and pithy the subject, the more I make sure I click on it to read; a subject line like "Not true: ABC is counterexample" conveys more information than "You're wrong!" and is correspondingly more likely to be modded up.
I'm not saying that a catchy subject line is enough to get mod points from me, but those are the ones I will read first.
Okay quick question. (Score:3, Interesting)
Okay, I don't dabble deep in DNS but I have a few quick questions. The RR thing is nasty because sub-domain authority implies domain authority. That's just silly and I'm stunned that something so simple is still true. I imagine there are a million and one "good" reasons for it, but it appears to be a gaping hole that could easily have been removed.
However, on the "let's spoof a DNS response" front - if a DNS server/client is being sent lots of spoof reponses, how long until they are picked up by a filter and blacklisted, tarpit'd or similar at the ISP end? This is the solution surely, even if you can send millions of packets with incorrect QID's and similar identifiers at a DNS server, like any other service at some point it has to say "you're trying to be naughty" and blacklist any packets, sound an alert, get the upstream filters to block such traffic etc. (This is, of course, assuming that there are at least some systems in place to stop or limit source-IP forgery in the first place). It might even be a good idea, at this point, for such servers to not trust their data, and constantly compare their copies with those available from the nameservers. If "fluctuation" of the data (between real and spoofed responses) is detected, then sound an alert on that domain.
How many responses does an average DNS server get that are invalid because of purely accidental causes (e.g. corrupted packets, mis-configured routers etc.)? Surely it's so few that it can instantly blacklist any suspicious activity, like trying to poison recursive caches in this manner.
I imagine that most home routers are extremely stupid and can't stop such things because they rely almost exclusively on the ISP's DNS servers to do their job and a flood of fake packets will not be picked up (this is, however, one of the reasons that I've always used "DMZ" or PPP half-bridge settings on ADSL routers to throw all external packets towards a real server rather than relying on some VxWorks firmware to handle IP-based attacks). But the servers? They *should* be filtering, cleansing and blacklisting packets even before you get into whether they have the most up-to-date patches, and a security fix to enhance the randomness of X etc.
It seems that the DNS servers are too trusting of "correct" packets that come as part of packet-floods of incoming data that is *obviously* false. DNS clients accepting data appearing to come from a trusted host is not nice, I agree, but recursive DNS servers should know better.
Or have I missed something incredibly obvious here?
I don't really care because my ISP wasn't vulnerable to this attack when I first tested it about 10 minutes after the first posting about its potential on the blog, and I'm pretty sure that they wouldn't have had any more advanced warning than anyone else.
Having said that, the DNS servers provided by LGfL's broadband supplier are, apparently, vulnerable. (London Grid for Learning, a London-wide schools extranet that virtually every London school, of which there are hundreds, use for their Internet connection, DNS servers, content filtering, etc. as well as their external content host). But, knowing LGfL and the way UK IT operations that are in any way involved with government work, that's not surprising at all.
Re: Authoritarian Followers suck (Score:1, Interesting)
"If DNSSEC is such ajoke, then how do you explain it being the standard? Or do you propose that the IETF is a joke also?"
Please, DJB and others have written extensively on how the DNS related RFCs are pushed through by a bunch of BIND supporters and how poorly thought out and product-centricly they have been written. DNS SEC RFCs are primary examples, how many times are they going to put out new DNS SEC standards after they are shown to be deeply flawed? Let's stop going down the DNS SEC road to satisfy Paul's ego and start from a clean slate. He and his succubuses have been proven wrong on dns security issues time and times again by the guys they have fought a PR war against - DJB and others.
Nothing would wound Paul's ego more than to list the ways in which DJB has been shown to be right and he has shown to be wrong over the years.
Even on an issue as seemingly obvious as running an auth and a caching dns server as separate processes, the ISC related attack dogs hounded DJB relentlessly until Nominum said "the performance of BIND 9 (which we at Nominum wrote, BTW) sucks. So our server that we wrote after learning from our mistakes that we made on BIND 9, uses a separate process for auth and caching dns servers, just like DJB did all those years ago."
http://home.cc.umanitoba.ca/~altemey/
Re:Here's the whole post (Score:3, Interesting)
Malory wants to poison the server ns.polya.com
Malory sends NS requests for ulam00001.com, ulam00002.com ... to ns.polya.com.
Malory then sends a forged answer from the .com server, saying that the NS for www.ulam00002.com is ns.google.com *AND* puts a glue record saying that ns.google.com is 66.6.6.6
Because the glue records corresponds with the answer record, (same domain) the targetted nameserver will cache or replace it's curent record of ns.google.com to be 66.6.6.6
Hmmm, can't be that simple, can it ?