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.
Here's the whole post (Score:1, Informative)
http://demosthen.es/post/43048623/matasano-briefly-had-a-post-up-about-the-dns-flaw [demosthen.es]
Doxpara.com also updated. (Score:5, Informative)
Doxpara.com, the blog of Dan Kaminsky who first discovered the vulnerability, has also been updated. [doxpara.com]
In case of Slashdotting, here's the full update;
Patch. Today. Now. Yes, stay late. Yes, forward to OpenDNS if you have to. (Theyâ(TM)re ready for your traffic.) Thank you to the many of you who already have.
I got this much (Score:2, Informative)
I got this much and am working on extracting more but hitting a roadblock.
Matasano Chargen  Blog Archive  Reliable DNS Forgery in 2008: Kaminskyâ(TM)s Discovery. Well the cat is finally out of the bag. I suspected this was how the
the cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan ... One of them involves mucking about with the QID in DNS packets and
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
where Mallory tells you youâ(TM)re going
Re:I got this much (Score:5, Informative)
Found this while google screwing. Someone got it!
http://pastebin.ca/1078776 [pastebin.ca]
1.
Reliable DNS Forgery in 2008: Kaminskyâ(TM)s Discovery
2.
from Matasano Chargen by ecopeland
3.
0.
4.
5.
The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat.
6.
1.
7.
8.
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.
9.
10.
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.
11.
12.
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.
13.
2.
14.
15.
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.
16.
17.
First, QIDs.
18.
19.
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.
20.
21.
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).
22.
23.
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. M
Re:No details? (Score:3, Informative)
Just another example of how you can't erase knowledge once it's been disseminated.
BTW, the method of attack really is quite clever. And pretty trivial.
Re:Here's the whole post (Score:5, Informative)
Ok, here's the gist: It's difficult to spoof a response for the right domain name, because of the random query IDs. You need too many requests and caching servers don't usually ask for the same name very often. But it's easy to get a caching server to ask for many different names in a subdomain, so do that and send your fake answers. One of them is going to get accepted sooner or later. Include spoofed glue for the real subdomain (www...) in your answers. Because the glue is for the same domain, it is accepted. Tadaa, poisoned DNS.
Ridiculous armwaving... (Score:1, Informative)
An article over at the Register [theregister.co.uk], states that this 'vulnerability' was discovered three years ago by Ian Green and published in a paper [sans.org] he wrote for the SANS Institute. While Kaminsky does deserve some credit for his organizational skills in getting people to act on this, that's about as far as his role goes. Since this has been known about for three years and we haven't seen anything 'in the wild' -until now that the media bandwagon is careening downhill on fire- just goes to show how hard this is to exploit.
The significance of the attack... (Score:4, Informative)
...is not just that you can race legit DNS servers for legit queries, is that you can request recursive resolution for bullshit DNS servers, while submitting fake answers WITH malicious informational records that let you poison second-level domains. So by requesting xxjk3j.google.com while submitting your own coolly crafted answer, you can make the victim DNS use YOUR DNS as authoritative for the future google.com replies.
THAT is the significance of the attack. THAT is what matasano pulled.
Re:Ridiculous armwaving... (Score:5, Informative)
Re:Ridiculous armwaving... (Score:3, Informative)
The responsible thing at this point would be for the vulnerability to be published. By now the bad guys surely already have the details and are in the process of selling exploit code to each other.
While the pro-security community is being left in the dark.
He may have considered new modes of attacks that had not yet been concerns.
For example... phishing wasn't such an issue back in the earlier 1990s when the original weakness was noted.
A DNS hijacker attempts to poison a particular domain on a DNS cache. That's the ordinary attack model a DNS server admin would be concerned about, right?
What if instead, the attacker doesn't care what domain they poison? Instead, they aim to attack major ISPs' DNS cache, or authoritative DNS servers' cache.
Instead of trying to poison one particular domain, they go down a HUGE dictionary of popular domain names, TLDs, etc.
And if their odds of each poison being successful are (1/2^16) based on being able to predict the source port?
They have a good chance of eventual success, by brute force, especially if they can reduce the search space for transaction id, or re-use a legitimate transaction id in an unexpected way.
The attacker doesn't care that his spoofed packets will be wrong or won't get there first for most domains.
Poisoning _just one_ popular domain with a bogus NS record may be a serious attack.
Once one poison is successful, if the future dns transaction ids/source ports are sequential, or even just pseudorandom, an attacker can possibly know that they have succeeded (By testing the success of their poison).
Knowing that they succeeded gives them the state of the RNG; they might also get that querying a domain whose authoritative DNS server is complicit to the attack (and will provide the attacker with the DNS request packet for analysis)
Re:Ridiculous armwaving... (Score:3, Informative)
The pro-security community has always been safe; DJBDNS and derivatives are immune to this attack and always have been.
Re:Long story short (Score:1, Informative)
That is not it. What you describe would have worked a decade ago, but not today.
Re:Here's the whole post (Score:3, Informative)
You don't need the address for the NS server as you're getting a result already. If you didn't ask for the information then it shouldn't be in the reply - if it is just discard the entire packet as bogus and keep listening for the real one.
Re:Been seeing this for a while (Score:3, Informative)
Re:Been seeing this for a while (Score:3, Informative)
That is different - that's just advertising and silliness off the way the wildcard matching works for WHOIS.
The issue is when you can force the target to resolve blah.google.com to poison www.google.com and then include a glue response for www. in with the blah. response which is then accepted because the domains match at to the right of that level.
url (Score:1, Informative)
Better Speculation (Score:5, Informative)
Alright, so I'm not even someone who does DNS/networking stuff even for a hobby (just a math grad who skimmed the RFCs once or twice) so if I can figure this out from what's up now then any competent bad guy can as well.
Anyway my guess is that it involves a combination of the birthday attack and the request for multiple nonexistant nameservers. That is as the attacker you trick poisontarget.com into trying to resolve the following locations.
AAA.google.com ....
AAB.google.com
XXX.google.com
Now you forge a single response packet that works for all of these requests and send many different copies with different TXIDs. Thus to succeed you need only hit ONE of the TXIDs used in the real requests.
In these forged responses you also have a forged glue record (as suggested in some of the links) which gives you control of lookups for all of google.com at poisiontarget.com after a single success.
Then again maybe I missed something basic which means this doesn't work.
Re:The push for DNSSec (Score:5, Informative)
Sorry for the threadjack (thank you for ensuring that 99% of the slashdot crowd is looking intently upon the thread), but here's soem relevant info that should be near the top.
As of the time of my post, the original text of the article (at least I -THINK- it's the original text) is available here [buanzo.com.ar]
Slashdotters may resume the lesbian thread now, thank you for your time (hope I didn't kill anyones chubber).
Re:Doxpara.com also updated. (Score:2, Informative)
do NOT blindly forward to OpenDNS
They do not return NXDOMAIN for domains which don't exist.
Dan, not all of the internet is a web-browser.
GoogleReader caching FTW (Score:5, Informative)
y 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'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's called back to get his sandwich. If you're wondering, Bob likes ham on rye with no onions.
If you'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'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'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'm Mallory and I'm attacking Bob, how can he distinguish my packets from Alice's? Because I can't see the QID in his request, and the QID in my response won'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'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's response gets to your computer before the legitimate response arrives from your ISP's name server, you will be redirected where Mallory tells you you're going.
Obvious fix: you want the QID be randomly generated. Now Alice and Mallory are in a race. Alice sees Bob'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'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'll break the RNG and be able to predict its outputs.
*
16 bits just isn't big enough to provide real security at the traffic rates we deal with in 2008.
Your computer's resolver is probably a stub. Which means it won't really save the response. You
I have the whole thing reasonably well formatted (Score:4, Informative)
See http://thefrozenfire.com/data/dnspoisoning.html [thefrozenfire.com] for the whole deal, without the pastebin RAW formatting ;)
Full Text of Article Here (Score:3, Informative)
Re:Ridiculous armwaving... (Score:4, Informative)
Just because it has "security" in the name, doesn't make it secure, Alice.
The patches make it clear that ADDITIONAL-section processing is to blame- just as it has been numerous times over the last twenty or so years. DJBDNS doesn't do ADDITIONAL-section processing and so it immune. BIND tries to do a lot of hand-waving to continue doing ADDITIONAL-section processing even though it's clearly a bad idea- in order to protect egos.
So the guy who rejects advise from the security community on src port randomization and ADDITIONAL-section handling; the guy who has had countless vulnerabilities, and the very same guy who has lied about BIND8 and BIND9's complete rewrites, that's the guy you're taking at his word regarding the security of DNSSEC?
By the way, DJBDNS supports all RR types- including those that haven't been invented yet, simply because it has an extensible data format.
Re:Even worse... (Score:3, Informative)
Well that would work, although since VeriSign's "SiteFinder" stunt some DNS servers (including bind) have an option to denote a zone as being "delegation only" zone, which would stop this attack from working. I don't know how widespread use of this option would be, though.
Assuming it's not, than poisoning .com would make it much easier: with one successful attack you could poison dozens of popular domains.
What could be interesting is combining this attack with zombies -- that way you don't need to trick a user into visiting a site with your links on it, you can just spam the ISPs name servers from one (or several) of their clients until you finally get lucky. Even better, the larger the ISP the more likely one of your randomly infected zombies will be within their network.
You could also have the ISP name server do some queries against a DNS server you control so you can look for any patterns in the query IDs and source ports, and use that information to narrow the search space for your actual attack.
I'm not really seeing any solutions to these attacks that don't simply turn it into an easy DoS. Fun times are ahead!
Re:The push for DNSSec (Score:5, Informative)
It's a hard call in some cases. There's an argument that most (any?) multihomed customers should be able to send packets asymmetrically. That said, nobody with even half a brain should be running a NAS/LNS with single-homed customers WITHOUT RPF, although the (admittedly, in .au) number of people i've crossed paths with who are doing it wrong is staggering.
Conversely, if i'm peering with you and six other guys, and happen to be carrying traffic to your network (but not advertising a route back to some of MY peers, for e.g. traffic engineering reasons) across a given link, you have no business dropping that traffic.
RPF is a good idea, but it kind of breaks one of the more fundamental paradigms of the Internets.
Re:The push for DNSSec (Score:3, Informative)
BIND supports DNSSec; DNSSec is about cryptographically signing your DNS entries so resolvers know that the response they got was from the legitimate authoritative server for the domain.
This means that it's not something you can "just patch" - it actually requires people to do some work, which means it'll take a very long time to actually be widely deployed (by "people" I mean "every single person who administers one or more DNS zones"). You also have the usual problems with crypto, i.e. establishing a "web of trust" (it's all very well if records under google.com are signed, but how do you know they're signed by Google?).
Solvable problems, but inertia is a powerful force.
Ptacek eats shit (Score:1, Informative)
And here's tptacek's grovelling retraction (which followed his drunken rant on DD at the weekend which firmly argued the public have the right to know and trying to stop public discussion is Wrong). I fear the Matasanto crew and Halvar are about to discover what happens when geeks allow their 'satiable curtiosity to run away with their sense of ethics. Halvar in particular posted a long self-justification (with mathematical functions!) trying to prove that public dissemination before BlackHat would be a good thing.
=== BEGIN PTACEK [matasano.com] ===
"Earlier today, a security researcher posted their hypothesis regarding Dan Kaminskyâ(TM)s DNS finding. Shortly afterwards, when the story began getting traction, a post appeared on our blog about that hypothesis. It was posted in error. We regret that it ran. We removed it from the blog as soon as we saw it. Unfortunately, it takes only seconds for Internet publications to spread.
We dropped the ball here.
Since alerting the Internet earlier in July about the upcoming announcement of his finding, Dan has consistently urged DNS operators to patch their servers. We confirmed the severity of the problem then and, by inadvertantly verifying another researcherâ(TM)s results today, reconfirm it today. This is a serious problem, it merits immediate attention, and the extra attention itâ(TM)s receiving today may increase the threat. The Internet needs to patch this problem ASAP.
Dan told me about his finding personally, in order to help ensure widespread patching before further details were announced at the upcoming Black Hat conference. We chose to have a story locked and loaded for that presentation, or for any other confirmed public disclosure. On a personal level, I regret this as well.
Dan did phenomenal work on this research. It was impossible to talk to him today and not know that he was sincere about coordinating a graceful disclosure and fix for the problem. That I helped detract from that work is painful both personally and professionally, and I apologize to Dan for the way this played out.
Thomas Ptacek
Principal, Matasano Security
Jul 21, 2008
Re:Even worse... (Score:4, Informative)