Slashdot Mirror
Kaminsky's DNS Attack Disclosed, Then Pulled
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.
Q: Why is starting a post in the Subject: line annoying?
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
Doxpara.com, the blog of Dan Kaminsky who first discovered the vulnerability, has also been updated.
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.
Found this while google screwing. Someone got it!
http://pastebin.ca/1078776
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
Support my political activism on Patreon.
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.
Fame? Notorioty? Unstoppable attractiveness to women?
Hey, you all are laughing now, but I tell you, there's a whole throng of us women just waiting for the right guy to secure our DNS!
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
Whereas us lesbians can secure our own DNS just fine, but would still prefer to have some nice girl do it for us. :)
Hottest. Slashdot Thread. Ever!
"Freedom Through Vigilance"
This is sad.
Rudd-O - http://rudd-o.com/
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
Slashdotters may resume the lesbian thread now, thank you for your time (hope I didn't kill anyones chubber).
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