Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Backstory of the Kaminsky Bug

kdawson posted more than 5 years ago | from the no-good-deed-goes-unpunished dept.

Security 122

Ant recommends a Wired piece on the background story of the Kaminsky DNS bug and its (temporary) resolution, decreasing the odds of a successful breach from 1 in 2^16 to 1 in 2^32. We've discussed this uber-hole a number of times. Wired follows the story arc from before Kaminsky's discovery of the bug to his public presentation of it in Las Vegas.

Sorry! There are no comments related to the filter you selected.

Ant (-1, Offtopic)

socsoc (1116769) | more than 5 years ago | (#25971833)

Who is Ant? And is his site aqfl.net already slashdotted?

Re:Ant (0, Offtopic)

Ethanol-fueled (1125189) | more than 5 years ago | (#25972287)

I bought the print Wired and read that same article last week. Ho Hum.

Much more exciting was the comic about the robotic poker player and the description of the AI methods it uses to win.

Slashdotted (4, Interesting)

Vertana (1094987) | more than 5 years ago | (#25971869)

The site linked in the article is indeed slashdotted, but the bug in question has been overhyped in the media and, although it must be fixed to prevent future problems, it currently does not present a big obstacle for the current Internet...

Re:Slashdotted (4, Interesting)

socsoc (1116769) | more than 5 years ago | (#25971903)

No kidding it has been overhyped.

From TFA The vulnerability gave him the power to transfer millions out of bank accounts worldwide.
How so?! I don't have millions, but I do run djbdns...

Re:Slashdotted (3, Insightful)

Vertana (1094987) | more than 5 years ago | (#25971927)

Also From TFA, "Or, for the sheer geeky joy of it, he could reroute all of .com into his laptop, the digital equivalent of channeling the Mississippi into a bathtub." ... right.

Re:Slashdotted (4, Insightful)

nicolas.kassis (875270) | more than 5 years ago | (#25971969)

that one did make me laugh. From my understanding of the hole, he would have to attack all dns servers requesting information from the root .com server AND do so for every domain requested. No small feat.

Re:Slashdotted (3, Insightful)

socsoc (1116769) | more than 5 years ago | (#25972003)

I also liked A good hacker could reroute email, reset passwords, and transfer money out of accounts quickly.

Any financial institution that resets a password based solely off of an e-mail deserves to be raped. Most do forgotten password link -> sends e-mail to reset the pass with a unique URL -> user clicks on unique URL and answers additional verification questions

Re:Slashdotted (5, Insightful)

snowtigger (204757) | more than 5 years ago | (#25972133)

Any financial institution that resets a password based solely off of an e-mail deserves to be raped. Most do forgotten password link -> sends e-mail to reset the pass with a unique URL -> user clicks on unique URL and answers additional verification questions

Right, but that's not the problem here. You don't even need the "recover password" feature. If a website that looks like the bank and has the url of the bank, most users would just buy it and type in their username and password. Or you could easily set up a proxy kind of webserver to make it look like everything is working as usual.

Re:Slashdotted (1)

socsoc (1116769) | more than 5 years ago | (#25972145)

True, but I thought that part of the article was trying to illustrate the dangers of e-mail being delivered to the wrong host. I could, and am probably, mixing up the article.

Re:Slashdotted (1)

ArsenneLupin (766289) | more than 5 years ago | (#25972985)

dangers of e-mail being delivered to the wrong host

If you can cause the bank's email being delivered to your own server, you can get an RapidSSL [rapidssl.com] certificate for the bank delivered to you, so as to avoid those pesky "bad certificate" warnings that would otherwise pop up on your mark's computer if they visited your phishing site or password-logging proxy. Technically, this is a "domain-validated" certificate, and an astute surfer could still tell the difference (it doesn't have the name of the organization in), but who manually doublechecks certificates that your browser accepted?

So, indirectly, e-mail is still relevant.

Re:Slashdotted (2, Insightful)

Vertana (1094987) | more than 5 years ago | (#25972193)

Or you could easily set up a proxy kind of webserver to make it look like everything is working as usual.

This possibility has always been there. The matter of a MITM proxy-based atttack is not what is in question here, it is the possibility of a DNS poisoning attack which would redirect the user to a non valid website, which is appearing as valid, and the additional verification questions on sensitive websites (i.e. banks and such) would prevent this from happening (at least from a DNS redirect of the email standpoint).

Re:Slashdotted (3, Insightful)

SanityInAnarchy (655584) | more than 5 years ago | (#25972325)

If a website that looks like the bank and has the url of the bank, most users would just buy it and type in their username and password.

Which is why banks should do as PayPal does. If I ever see anything under the URL of http://www.paypal.com, I'll immediately suspect foul play, because PayPal uses https://www.paypal.com for everything.

In fact, it makes me wonder if a whitelist might be better than a blacklist, for phishing -- if a page looks suspiciously like my bank's page, but doesn't have the exact URL I'm expecting (https and all), raise a giant warning. No need to expose private info to Google, just a simple Firefox extension would do the trick...

Re:Slashdotted (2, Insightful)

Garridan (597129) | more than 5 years ago | (#25972633)

Right... but somebody MITM's both the CA and PayPal, they can run an encrypted server "at" https://www.paypal.com/ [paypal.com] -- and you just got phished, despite whatever precautions you thought would save you.

Re:Slashdotted (2, Informative)

tepples (727027) | more than 5 years ago | (#25973961)

Right... but somebody MITM's both the CA and PayPal

They would have to MITM Mozilla and Opera first, as the CAs' root certificates get distributed with the browser.

Re:Slashdotted (1)

SanityInAnarchy (655584) | more than 5 years ago | (#25978419)

All sane browsers and OSes that I know of distribute root certificates ahead of time, only to be updated via already-secure channels. The only way to make this work is to subvert that chain somewhere -- either convince an SSL vendor to trust that you are paypal, or somehow convince one of Microsoft, Apple, Mozilla, Opera, etc to distribute your new cert.

The first seems unlikely. You could use RapidSSL, in which case I'd be surprised and concerned to see the green bar go away, and I'd likely check my connection, try from a different location, and get in touch with PayPal to see WTF happened.

All of which assumes you can fool RapidSSL -- not hard, but then, you're trying to impersonate PayPal. It's very likely a human will do a double-take and wonder why you're not getting an EV cert.

The latter seems even less likely. Good luck.

Re:Slashdotted (1)

MikeBabcock (65886) | more than 5 years ago | (#25980427)

Yahoo! has a nice login verification image that the user chooses that displays near the login credentials. If the image you chose isn't displayed, you're on a forged page.

Re:Slashdotted (1)

theaveng (1243528) | more than 5 years ago | (#25973953)

The additional verification questions are ridiculously easy:

- click "I forget my password"
- capture that email using the Kaminsky's DNS error by pretending to be Customer@xyz.com
- click on emails' weblink
- answer "What is your mother's maiden name?" and then reset password to whatever.
- start withdrawing money from hacked account.

Repeat over-and-over until you have a few million withdrawn and then quietly retire. "The beauty of the Kaminsky attack, as it was now known, was that it left little trace. A good hacker could reroute email, reset passwords, and transfer money out of accounts quickly. Banks were unlikely to announce the intrusions--online theft is bad PR. Better to just cover the victims' losses."

Well, yeah. (1)

Grendel Drago (41496) | more than 5 years ago | (#25976313)

It's a bit depressing how nobody takes the security implications of the internet seriously, and acts surprised when they're reminded of them.

Email is not secure. Using SSL for your POP/SMTP/IMAP connections secures your login to the server, but the mail itself is still transmitted in the clear. And people act surprised when you tell them that people can and likely do scan their email?

Then again, given that our financial institutions actively train their users to ignore security indicators [mail-archive.com] (a very exploitable situation [cr.yp.to] ), we shouldn't be surprised at that sort of nonsense.

I noticed the following in the article:

It got worse. Most Internet commerce transactions are encrypted. The encryption is provided by companies like VeriSign. Online vendors visit the VeriSign site and buy the encryption; customers can then be confident that their transactions are secure.

But not anymore. Kaminsky's exploit would allow an attacker to redirect VeriSign's Web traffic to an exact functioning replica of the VeriSign site.

I was going to write about how clearly the built-in CA certs in the user's browser would throw up a flag and note that the cert wasn't actually signed by the folks at Verisign or whatever... but then I realized that, hey, given the abysmal state of security compliance, it's probable that nobody would even notice.

And an article on cache poisoning that doesn't even mention that Dan Bernstein had foreseen and fixed the lack of source-port randomization while pointing out that it's still only a stopgap [cr.yp.to] seven years earlier is an article that should have been edited a bit more thoroughly. Kaminsky made the attack much more dangerous, but the possibility should never have existed in the first place.

In a more ideal world, we'd all exchange encrypted and signed email and access any site that involved a login using valid SSL certificates and secure-only cookies [gossamer-threads.com] . But we're not there [auckland.ac.nz] .

Re:Well, yeah. (1)

socsoc (1116769) | more than 5 years ago | (#25976503)

I like your ideal world, but it's become a bear at my small business to teach people how to get Firefox to accept the self-signed SSL certs on our employee-only applications. Their new warning roadblock is annoying.

I use SSL to make it secure, but because I don't shell out to the major CAs on something that no customers use and where self-signed should be good enough, it is frustrating (and I am talking about when they use machines that I don't control).

I do wish that most e-mail clients, including web, did some encryption but that doesn't seem to be coming anytime soon. It's still something that only geeks have the knowledge of how to implement.

Re:Well, yeah. (1)

Onymous Coward (97719) | more than 5 years ago | (#25977081)

Is there no better way to get those certs approved?

Is it possible to install Firefox with your own CA cert? Or maybe the employees install their own Firefox at your site?

Re:Slashdotted (2, Informative)

Effugas (2378) | more than 5 years ago | (#25972303)

The idea was that you'd target individual ISP or Enterprise name servers, which would be trivially reachable via a simple ad network. You'd hit com, then use basic caching to grab what you liked.

Re:Slashdotted (0)

Anonymous Coward | more than 5 years ago | (#25978241)

A simple botnet or trojan/worm on network leaves could trivially compromise most major ISP's servers. Once you poison dns.aol.com, dns.comcast.net, dns.verizon.net, dns.optonline.net, etc., you've pretty much pwned 90% of ordinary home or mobile users in the continental US. ...and while attacking [from] leaves makes finding the most popular upstream servers convenient (just attack whatever the host is using), you don't even have to be in the domain. So attack dns.every_domain_in_the_host's_address_book.suffix while you're at it, just in case they're commonly used too.

Re:Slashdotted (1)

Theoboley (1226542) | more than 5 years ago | (#25975491)

wouldn't that in essence... overload his laptop and crash it, rendering it useless?

Re:Slashdotted (1)

SanityInAnarchy (655584) | more than 5 years ago | (#25972185)

If that is true, I am even more terrified than I was for the safety and security of our banks.

You're telling me none of these banks properly implemented SSL? It never occurred to any of them to educate their users, and thus make their uber-expensive SSL certificates have a point?

Re:Slashdotted (0)

Anonymous Coward | more than 5 years ago | (#25972211)

No, you just didn't read the article or lack an imagination. Hard to tell which.

Re:Slashdotted (2, Insightful)

Vertana (1094987) | more than 5 years ago | (#25972239)

It never occurred to any of them to educate their users...

Both secure websites AND browsers have been educating users on security since the early days of the Internet. Nobody can stop a stupid and/or ignorant user from being redirected and not realizing that SSL is not implemented or invalid. SSL is properly implemented, however, the attack in question was redirecting the DNS. For instance, you create your own website and your own certifications and then trick the DNS into thinking your site is from Verisign and was created by them as well (since the source address would be the same according to DNS). Everything looks legitimate, but it's not. This is not something that someone could look at say... banks for and blame them for incorrect security implementations, it's how DNS is (was) widely implemented at a fundamental level by ISP's and such.

Re:Slashdotted (1)

SanityInAnarchy (655584) | more than 5 years ago | (#25978191)

For instance, you create your own website and your own certifications and then trick the DNS into thinking your site is from Verisign and was created by them as well (since the source address would be the same according to DNS).

Which would still require you to update Verisign's root certificate, which still requires you to have Verisign's old root certificate key.

If not, well, you're popping up a security notice, which will be very difficult to get past in Firefox.

Re:Slashdotted (1)

nicolas.kassis (875270) | more than 5 years ago | (#25972245)

How many people would blindly type in their password without looking for the nice little lock. If you can fake the url in the top bar you are probably able to get a few passwords yielding enough to make a good attack. The question is, how do you transfer all that money without it being traceable. I'd like to know that please :P

Re:Slashdotted (3, Insightful)

Vertana (1094987) | more than 5 years ago | (#25972301)

It's always traceable, but the answer in short is to use proxies. If somebody steals from a bank in the US and routes it through Sweden, some anti-US countries, and then China to boot, do you think everyone will be so willing to help the US government? Probably not. And of course, you could do the same to your IP address through proxies.

Re:Slashdotted (1)

ArsenneLupin (766289) | more than 5 years ago | (#25973003)

how do you transfer all that money without it being traceable

Money mules. You pretend that you are operating a business in Russia, and hire "agents" in the US or Europe (the "money mules") to collect payments from customers, and forward them to you via Western Union.

In reality, the "customers" are your victims. Rather than wiring the money directly to your own account, you wire them to your mules, who collect and send it to you via Western Union. Western Union is untracable, as you can collect the money using a pre-agreed password, without showing any kind of id.

A couple of days later, police shows up at your mules' doorsteps, but you have disappeared...

Re:Slashdotted (1)

lloydchristmas759 (1105487) | more than 5 years ago | (#25973105)

Western Union is untracable, as you can collect the money using a pre-agreed password, without showing any kind of id.

Not true. Last (and only) time I used it, I was required to provide an ID. And so was the recipient of the transfer. The password was an extra security.

Re:Slashdotted (1)

vidarh (309115) | more than 5 years ago | (#25973155)

In fact anything else would be a gross violation of money laundering laws in most countries, at least for international transfers above very low limits.

Re:Slashdotted (1)

ArsenneLupin (766289) | more than 5 years ago | (#25973197)

Not true. Last (and only) time I used it, I was required to provide an ID. And so was the recipient of the transfer. The password was an extra security.

The option used to be available, and probably security was tightened in response to exactly these kinds of frauds. In any case, this fraud is sufficiently real that Western Union themselves warn about it [westernunion.com] .

Re:Slashdotted (1)

SanityInAnarchy (655584) | more than 5 years ago | (#25978217)

How many people would blindly type in their password without looking for the nice little lock.

Shouldn't be too hard to write a Firefox extension which does exactly that -- warn you when you seem to be attempting to login to your bank, on a site that isn't the exact same URL as your bank.

Re:Slashdotted (1)

SanityInAnarchy (655584) | more than 5 years ago | (#25972305)

To answer my own question, It looks like TFA mentions SSL, in a roundabout way:

But not anymore. Kaminsky's exploit would allow an attacker to redirect VeriSign's Web traffic to an exact functioning replica of the VeriSign site. The hacker could then offer his own encryption, which, of course, he could unlock later. Unsuspecting vendors would install the encryption and think themselves safe and ready for business.

In other words, you're telling me that it's worse -- even VeriSign doesn't know how to use SSL properly. You'd think, if you were downloading a new certificate, that you'd get it via SSL?

But thanks to journalists trying to dumb this down, I don't even know whether they're talking about SSL, let alone certificate distribution -- there are just some vague references to "encryption".

And then there is the part about catching return emails -- this problem feels a bit more real to me, mostly because everyone does this "forgot my password" shit, and no one uses PGP for those messages.

If a DNS vulnerability really is this serious, that tells me that the rest of the infrastructure is the problem, not DNS itself. With properly implemented encryption at the protocol level, this wouldn't be a catastrophic security failure, it would just be an irritating DoS, easily circumvented.

Re:Slashdotted (2, Interesting)

ArsenneLupin (766289) | more than 5 years ago | (#25973029)

In other words, you're telling me that it's worse -- even VeriSign doesn't know how to use SSL properly. You'd think, if you were downloading a new certificate, that you'd get it via SSL?

Encryption of the certificate is not the problem... the problem is el-cheapo "domain-validated" certification authorities [rapidssl.com] whose only "proof of domain ownership" is your ability to receive email at root@yourtarget.com and a phone number (any phone number will do). If you can spoof DNS so that this email really goes to your computer, and if you know where to buy a prepaid mobile plan, you can get a "valid" certificate for yourtarget.com .

It's a little bit like identity theft: rather than emptying your existing account, the perp just sets up a new account in your name...

Re:Slashdotted (1)

peter (3389) | more than 5 years ago | (#25973759)

ArsenneLupin, this topic must be right up your alley, since you've stolen your name from a master thief. :)

  I was going to say, don't browsers have copies of the root certificates locally, and require a chain of signatures from them to anything they're going to accept without complaint. But I didn't realize that one could potentially get another cert for a domain without anyone checking with the people who have the first cert.

  Now I understand how the pieces could fit together to play man-in-the-middle with a bank. Otherwise I couldn't see how you could get a valid SSL certificate for yourtarget.com. Which you _need_ if people are going to access your fake site with SSL, and you're not just proxying the traffic to the real yourtarget.com without decrypting it.

  Even with the low-validation certs you mentioned, where you just need to be able to receive mail at the domain, and have a phone, I would have hoped they wouldn't issue certificates for domains that they (or another cert authority) have already issued or signed a previous cert for.

  BTW, the article makes this sound way easier than this, esp. since it's talking about the cert vendors selling encryption, when they actually sell trust. The encryption is free (and easy). Trust is hard, and can be worth paying for. The article was a real mixed bag: painfully bad technical sections, but I loved reading about Vixie's response, calling people and telling them to fly to the west coast without telling them why. That's serious paranoia about even traffic analysis of email (assuming you could trust PGP).

You're correct, but that's not the vulnerability. (1)

Grendel Drago (41496) | more than 5 years ago | (#25977249)

No bank is going to get a cert from RapidSSL or the like. (At least, I hope not--given the security practices I've seen at banks, I'd be surprised if they didn't

This is, supposedly, what EV certificates provide, apart from a fat new revenue stream for selling those expensive bits (quick, someone explain why wildcard certs cost a single damned penny more than single-domain certs) and making anyone who can't afford them into second-class citizens.

There is, however, an attack which goes around that; as Dan Bernstein proposed in 1999 [cr.yp.to] , if you set up your fake server for hugebank.com, and have it serve up redirects to your newly registered (and certified!) hugebank.secure-banking.dom site, then the user will see a validated site that they got to by typing in their bank's address or following an email link.

Given that my current bank requires me to accept javascript served from akamai.net in order for me to pay bills, and other banks use plenty of weird domains for user interaction [auckland.ac.nz] (see pages 11--13), I don't believe that this would set off any alarms.

I complained to my bank back in August about the site requiring javascript from untrusted domains--I didn't even get to complaining about their use of various domain names. Unfortunately, there's no better alternative where I live, and they seem completely uninterested in responding to me.

Re:You're correct, but that's not the vulnerabilit (1)

Effugas (2378) | more than 5 years ago | (#25978185)

Regarding EV, https://www.yourbank.com (EV cert) == https://www.yourbank.com (domain validated cert) -- as far as the browser's Same Origin Policy is concerned. So the attacker passes through enough EV for the bar to turn green, then switches over to DV for JS to come in. Not good.

Re:You're correct, but that's not the vulnerabilit (1)

SanityInAnarchy (655584) | more than 5 years ago | (#25978351)

This is, supposedly, what EV certificates provide

The real question is, then, can obtaining an EV cert also prevent RapidSSL from then issuing you another cert? Unless you've thoroughly trained your users to look for that green bar, they could still intercept https://yourbank.com/ [yourbank.com] using a brand-new RapidSSL cert for that same domain.

if you set up your fake server for hugebank.com, and have it serve up redirects to your newly registered (and certified!) hugebank.secure-banking.dom site, then the user will see a validated site that they got to by typing in their bank's address or following an email link.

There's no reason for a bank to send out a non-https link in an email. I am in the habit of typing https for several sites -- gmail being the main one.

And if it wasn't for the banks (including my current bank) which are Doing It Wrong (sending me to a third-party site for the actual banking), I would be very suspicious seeing anything other than hugebank.com in the URL, validated or not. In fact, the first time this happened, I called them and asked what was going on -- they confirmed that they outsource this stuff.

Re:You're correct, but that's not the vulnerabilit (1)

Effugas (2378) | more than 5 years ago | (#25978713)

Since the non-green-bar site has Javascript access to the green-bar site, the green bar doesn't actually mean anything.

Re:You're correct, but that's not the vulnerabilit (1)

SanityInAnarchy (655584) | more than 5 years ago | (#25979573)

Is this true of PayPal, specifically?

The Backstory of the Kaminsky Bug (2)

POTSandPANS (781918) | more than 5 years ago | (#25974919)

No kidding it has been overhyped.

From TFA The vulnerability gave him the power to transfer millions out of bank accounts worldwide. How so?! I don't have millions, but I do run djbdns...

Overhyped? are you kidding? "Kaminsky Bug" is going to be a major hit once it hits movie theaters!

Seriously though, The problem is major and we have found a pretty good workaround for it, can we move on? Most sysadmins will patch for it and then wait for the full fix and then install that. With something like blaster, you get a few users that patch and the rest just letting it go. I was doing a packet capture a few months ago (I work for an ISP) and I still see some systems out there that seem to be infected.

Scaremongering works wonders (0)

Anonymous Coward | more than 5 years ago | (#25972859)

Because one of the implications of this bug is that an US state agency can push for taking complete control of the global DNS system for "security".
Something like when a person who sees invasion into Pakistan as a possibility gets elected, the evil Pakistanis cause a major terrorist incident.

Re:Scaremongering works wonders (0)

Anonymous Coward | more than 5 years ago | (#25974765)

Even more interesting: that someone visited Pakistan in the early 80s. At the time, US citizens weren't allowed. Not a problem for him: He had an Indonesian passport.

DNS is Not Secure (2, Funny)

Anonymous Coward | more than 5 years ago | (#25971889)

For recursive acronym, see message subject. Also see the nearest mirror for an example of assmonkey.

DNSSEC (1)

chrome (3506) | more than 5 years ago | (#25971957)

Should we be scrambling to figure this shit out now, or can it wait til everyone else gets the kinks worked out?

Re:DNSSEC (0)

Anonymous Coward | more than 5 years ago | (#25972135)

You can scramble all you want, but until the root is signed it's just for tinkering.

Re:DNSSEC (1)

rabbit994 (686936) | more than 5 years ago | (#25972233)

Of course if you can implement it, go for it but like anything with security, it adds additional level of complexity to entire system which may or may not be worth it. I'm not going to be signing any of my domains since they are just personal domains but I hope banks and such will.

Why we don't have DNSSEC yet (1)

billstewart (78916) | more than 5 years ago | (#25976887)

A few things have changed since my 2003 /. post [slashdot.org] which I've attached below, but the main difference is that Kaminsky's attack has made people realize that DNSSEC matters, and that it's time to get the ICANN and Department of Commerce to sign the root and have the registries sign .com and other major domains. (It's fun watching the Feds panic about it, because much of it's their fault.) And while widespread IPv6 deployment is closer, IPv6 DNS just uses the same packet format as IPv4 DNS with some new record types, so it has the same vulnerabilities.

=============== Political Problems with DNSSEC =====

Some of the problems with DNSSEC are technical - most of them have to do with making things fit inside 512-byte packets and not breaking too many server implementations. But the big problems have been political, including politics implied by the protocol structure and politics that's separate from it.

  • Old US Fed Attempts to Stifle Crypto - Back in 1993, when DNSSEC was drafted, the US government was still doing the Cold War thing of pretending that there were Commies who shouldn't be allowed to have Crypto because their Spies could send Unbreakable Messages, and the FBI was encouraging them to maintain this charade because crypto might make illegal wiretapping difficult and mass wiretapping expensive. So Open Source publishing of DNSSEC code on the Internet or export to other countries was threatened by all the rest of the anti-crypto Export Law stuff, even though it only needed digital signatures and not encryption - because RSA digital signature code is also usable as encryption code, and because good digital signatures make forgery impossible. At one point, John Gilmore got approval for exporting a "bones" version of DNSSEC (with the crypto code removed) and then the approval got yanked shortly afterwards, in spite of their being no adequate legal justification for it. DNSSEC was pretty much stillborn because of those politics, which was too bad because we could have had a DNSSEC in place when the Web thing was taking off.
  • Hierarchical Nature of DNS - For many security and political applications, a hierarchy is a Bad Thing, because it means that somebody's in charge, and that there's one big weak point to attack it with. That doesn't seem to be much of a problem for DNSSEC, because it's piggybacking on DNS, which is inherently hierarchical. Sure, there's all that ugly politics about who gets to sell the name example.com and who gets to resolve conflicts if multiple companies want to be the One True Owner of the domain name example.com, but getting the folks who manage official assignment of the name example.com to sign the DNS record is a simple technical implementation, just as getting them to put the IP address in the DNS server is - it's *much* simpler than getting them to send the bill or the renewal notice correctly.
  • ICANN Ugliness - Of course, all this was mired in political ugliness, and the ICANN Name Gods fundamentally weren't interested in doing the right thing technically - they were interested in doing the power-grab thing on the intellectual property trademark space, not in technical administration. And the people who fight about name space ownership and collect your registrar money aren't really the people who run the physical root and .com DNS servers, many of whom worked for organizations funded by the US Government, who weren't going to push for crypto protection.
  • Multiple Name Registrars, Single Keys - There's a big ugly gap in the DNS hierarchicalness, which is that multiple registrars can sell you the name example.com, but there's only one DNS Signature Key for .com - does that mean that 50 random companies around the world can all be trusted to own those keys and not leak them? Fat chance! But the protocol wasn't designed for that kind of sharing.
  • One Root To Rule Them All, again - If there's only one Root, and they don't get it to buy in to the plan, which they didn't, and it doesn't sign the keys for com, edu, etc., or the country codes, then there's no clean way to bootstrap the system. Sure, there were all the alternate-root guys trying to compete, and any country-code TLD administrator (e.g. Tonga's .to) could have created a key for their TLD and started signing keys, but without The One True root key, eventually it falls apart. Tonga or Norway or someone could declare themselves to be the head of the Cabal, issue a Root Key, sign other TLD's domain name with it, and start selling more DNS names to people who wanted them, and maybe they'd get buy-in from enough TLDs to make it fly, but it's a tough political game.
  • Conflict of Interest between SSL Key Certs and DNSSEC Key Certs - SSL keys certify something, usually about the "owner" of a given key, and let you have some trust in whoever possesses that key, often trusting a connection to a particular web server. DNSSEC keys certify the connection between a key and a domain name, which can also be used to establish trust in a web server (with a bit of browser development work.) There's a BIG market conflict! Generating SSL PKI certs is a trivial expense, and doing some level of identity verification isn't too expensive, and you can sell them for a respectably large amount of money to companies that want to do commerce on the net, and several companies made big bucks by doing that (either directly from customers or by selling themselves to the market-leader company.) Generating DNSSEC keys is a trivial expense, and since you're doing it along with selling the domain name, you don't need to verify any sort of personal or company True Name - you're giving the key to the same person you give the name, and it may even simplify that administrative function, and it's hard to justify charging much of any money for that. If you're the one company who runs the DNS master database, and make lots of money selling SSL keys to people who won't need them if they've got DNSSEC, how much financial incentive do you have to get the IETF and IANA and ICANN and root-servers.net to really really make up their mind and agree on implementing any particular version of DNSSEC?. None. I'm not faulting them for it, but they still have a negative financial interest in deploying DNSSEC.

My guess is that the biggest political problems with DNSSEC were the Anti-Crypto Feds at first and the Verisign conflict of interest today. But none of the big players really care.

The other problem is that, while DNSSEC is one way to solve some of the world's business and communications security problems, there are other ways to solve some of them, and there are problems it doesn't solve. SSL works ok for web commerce, mostly. The FreeSWAN free Linux IPSEC folks have done some cool stuff with DNSSEC, but it's mostly usable only when you control your reverse DNS service as well as your forward DNS service (because VPN tunnel servers only see your IP address, not your DNS name, so deciding whether that's somebody you want to talk to is a reverse lookup, not a forward lookup), and far fewer people control their reverse DNS space. Corporate VPNs don't need DNSSEC - they can use shared secrets or token frobs internally, while DNSSEC is more useful _between_ entities. People are gradually starting to use SSL authentication and encryption for SMTP, which again doesn't need DNSSEC, and except for that and inside corporate VPNs, most email is either unencrypted or encrypted at the message level using PGP or equivalent.

===============

mod 0p (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#25971991)

worse a8d worse. As mechanics. So I'm There's no

Do I not understand? (1)

pavera (320634) | more than 5 years ago | (#25972279)

So, this is the first I've read in depth about this attack (its been 3 years since I was in IT, and in charge of DNS servers, patches, and all the rest...)

So the attack works by asking for a non-existant domain (ie nothere.domain.com), then blasting the DNS server with response packets that have a RR for www.domain.com, and then the DNS server caches the www RR because it passes the "baliwick" test...

So, uh... why not just turn off caching of everything besides the *ACTUAL* request? What would that break? Seems like that would be a very very easy fix, and would eliminate the problem completely wouldn't it?

Unless what is happening is that the spoofed response packets are actually responses for www.domain.com, and then still why is the DNS server asking for something (nothere.domain.com) and caching a response for something else (www.domain.com)? It really seems stupid to me, and I don't see any reason why DNS should be caching info that it didn't ask for.

Any DNS gurus out there care to explain the rational for that? Or do I have the attack wrong?

Re:Do I not understand? (1)

prockcore (543967) | more than 5 years ago | (#25972345)

I don't quite understand it, but I was under the impression that he was asking for a non existant sub.domain.com, and then blasting "I am in charge of .domain.com".

But that doesn't seem to make sense to me since the ISP would've already cached the DNS for .domain.com

Re:Do I not understand? (2, Informative)

cleatsupkeep (1132585) | more than 5 years ago | (#25972657)

They have to update their cache at some point.

Re:Do I not understand? (3, Informative)

cencithomas (721581) | more than 5 years ago | (#25972767)

Basically right. The attacker forces a cache miss by using a bogus subdomain.example.com that is guaranteed not to exist in the ISP's DNS cache, and then tries to get his own response in before the real response comes in. If he succeeds, the the ISP will cache his spoofed packets as real, and his packets will include new NS1.example.com server IP info, causing the ISP to automatically go to his servers for any future request for example.com. He puts a TTL field with a super-long expiration date and voila! The cache doesn't expire and the ISP won't be asking for new DNS updates for that domain.

Re:Do I not understand? (1)

bpkiwi (1190575) | more than 5 years ago | (#25973261)

So, the dirty fix is to always request a random bogus sub-domain before making the real request?

That way you cause your own cache miss, and the dns server goes away and updates itself again, but this time the hacker isn't busy bombarding it with fake responses.

Obviously not a scalable solution, since it would kill dns caching.

This also makes me wonder if widespread attacks of this kind would be self-defeating. hackers x, y, and z are busy attacking the same server, and every cache miss is wiping out the last successful poisioning.

Re:Do I not understand? (1)

peter (3389) | more than 5 years ago | (#25973785)

So, the dirty fix is to always request a random bogus sub-domain before making the real request?

No, cache misses for A records don't make a recursive resolver go back to the parent domain for an updated NS record. If a cache was poisoned so it thought .bank.com queries were handled by w.x.y.z (the attackers IP), a request for nonexistant.bank.com would cause it to send an A request for the name to w.x.y.z, but not go back to the .com servers to find out which server is authoritative for .bank.com. (It will do that once the cached NS record for .bank.com expires, which could be weeks. Or until another black hat re-poisons that cache.).

Re:Do I not understand? (1, Informative)

Anonymous Coward | more than 5 years ago | (#25972793)

You got most of it...except for a couple of important bits.

The attack involves asking for *multiple, changing* nonexistent subdomains. That is important because the NXDOMAIN response might be cached, depending on the DNS server you are attacking.

You then blast the server with responses for the non-existent record, also including the RRs you want to hijack in the glue section of your forged response. That additional RR is in-bailiwick, and therefore put into the cache and treated as true.

Now, your important question: What's the point of glue records at all?

Glue records help solve a chicken-and-egg problem that is at the core of DNS. Say I want to resolve www.example.com. How does that DNS transaction go with glue?

(The following assumes TLD servers are not cached for illustrative purposes)

local -> root nameserver: "Who has www.example.com?"
root -> local: "list of .com NS records along with glue A records"
local -> .com servers @ IPs listed in glue: "who has www.example.com?" .com servers -> local: "list of NS records for the example.com domain w/ glue"
local -> example.com servers @ glue IPs: "who has www.example.com?"
example.com -> local: "www CNAME whatever, glue whatever A 1.2.3.4"

Without glue:
local -> root: "who has www.example.com?"
root -> local: "list of NS records for .com servers"

NOTE: now we need to resolve A.GTLD-SERVERS.NET (a .com server)

local -> root: "Who has A.GTLD-SERVERS.NET?"
root -> local: "list of .net NS RRs"

NOTE: the list of .net servers is the same as the list of .com servers, but it wouldn't matter if it was different. The point is, NS records have to reference a NAME, not an IP. TCP/IP requires an IP, not a name. chicken and egg. Glue solves that problem. Why do NS records require a name? Heck if I know, ask someone smarter.

I can see someone thinking: Ok, well what if we only accepted glue records from TLD servers? Two problems: First, this attack could be used to hijack the DNS entry of a TLD server just as easy as for any other. Second, you'd probably at least double the DNS transaction volume for other authoritative DNS servers. Probably more, actually (without glue, that CNAME we returned at the end of the first query would result in ANOTHER transaction to resolve whatever.example.com).

So glue is useful for a number of reasons.

Re:Do I not understand? (4, Informative)

ArsenneLupin (766289) | more than 5 years ago | (#25973061)

So, uh... why not just turn off caching of everything besides the *ACTUAL* request?

Actually, as far as I understood, the attack is making the information "appear" to be relevant. For instance, DNS may contain aliases (CNAMEs) that do not directly resolve in an IP address, but rather into another name.

So, www.yourcompany.com may point to houdini.yourcompany.com, which itself resolves into 137.142.13.14.

When a client queries for www.yourcompany.com, the DNS server not only answers that query, but "helpfully" supplies the second leg, in order to save one round-trip.

Same thing with NS queries.

So, all the perp has to do is have nothere.domain.com pretend to be a CNAME for www.domain.com, and "helpfully" supply a mapping from www.domain.com to an IP under your control. Because the "unsolicited" mapping appears to be relevant, the client DNS server will cache it.

Re:Do I not understand? (1)

peter (3389) | more than 5 years ago | (#25974023)

I was as confused as you were by all this, since the article didn't say what the actual attack is. I eventually found something that explains it.
http://www.doxpara.com/DMK_BO2K8.ppt [doxpara.com] linked from http://www.isp-planet.com/equipment/2008/nominum+vantio.html [isp-planet.com]

  See slide 17 in the presentation. But the trick is, your forged reply to a query for 83.foo.com is:

83.foo.com IN NS www.foo.com (83.foo.com is a subdomain, whose name server is www.foo.com)
www.foo.com IN A 6.6.6.6 (glue)

  So I guess I still agree with you, that BIND must be trusting more than it needs to. Caches could distrust any glue except when it has to. (I think the glue is only necessary when the name server is part of the domain it's serving. e.g. The glue would be needed if the name server was ns1.83.foo.com. Otherwise why not ask the .foo.com server for www.foo.com's A record, or use a cached one, instead of trusting the glue?)

  IIRC, djbdns is skeptical of glue. I remember reading a big rant about glue on DJB's web site years ago. I'm not sure if that's why it's not vulnerable, or if it's because it already did source-port randomization.

  Anyway, that presentation seems to cover a lot of what I wanted to know. In the worst case, you have a cache that trusts glue, and you can poison it by guessing a 16bit ID. In the even worse case, multiple requests for the same name leave the cache willing to accept more than 1 ID for a single response, leading to a birthday attack.

    The trick is to generate lots of DNS queries for names you choose when the server isn't run by idiots (accepting recursive queries from the whole Internet). Web log analyzers are one possible vector. Otherwise if you can feed HTML to something that will resolve names for IMG tags, or presumably javascript could go nuts...

Re:Do I not understand? (1)

MikeBabcock (65886) | more than 5 years ago | (#25980491)

As I remember it, DJB thought glue was a bad idea, and dnscache always recursively gets its information starting with the root servers, caching only the data it fetched itself recursively.

This of course is not the case when run in caching-only mode where it queries a parent DNS server which may be faulty (and DJB doesn't recommend this usage).

Totallylookslike (2, Funny)

Dirtside (91468) | more than 5 years ago | (#25972371)

Is it just me, or does Paul Vixie look like the Terminator?

why do people consider this hype? (5, Insightful)

circletimessquare (444983) | more than 5 years ago | (#25972599)

yes his attack only involves one dns server, but it is devastating and quick and effective. you can attach yourself vampirically to one dns server, sniff for bank info, redirect google, look at email, or whatever, and then quit shop before anyone raises alarm, and set up shop somewhere else, easily and quickly and invisibly

yes, you won't be able to take over ALL dns servers, but why is doing that the only thing that qualifies in your mind as truly threatening? kaminsky's attack, as described, is a hell of a scary hard core hack. its not hype, its the genuine frightening article. its the creme de la creme of hacks: simple, elegant, and as devastating as they come. any yahoo can move in, take over a dns server, victimize users downstream, and move on unnoticed and set up shop somewhere else. hardcore. devastating. frightening

is it some sort of ego thing? you have to belittle the validity of someone else's discovery? why do people consider this hype?

Re:why do people consider this hype? (3, Interesting)

he-sk (103163) | more than 5 years ago | (#25972637)

Same reason why people don't believe in climate change. The potential risk is so mind-boggling, it's psychologically healthier to pretend it's not there.

Think of kids that cover their eyes and then reason that you cannot see them, because they cannot see you.

Re:why do people consider this hype? (1)

spandex_panda (1168381) | more than 5 years ago | (#25973269)

Surely this isn't troll? I too am sick of the climate change doubters. Maybe all this DNS drama will finally put those carbon doubters in their place!

Re:why do people consider this hype? (0)

Anonymous Coward | more than 5 years ago | (#25977881)

I don't know anyone who doesn't believe in climate change. I know plenty of scientifically minded people who believe that there is clear obvious scientific proof that there is climate change without man, who when given that initial fact are not then willing to take a leap of faith that man is the cause of all climate change. Why do you belittle them for it? Or do you think that man driving cars around caused the ice age to come and go 20,000 years ago?

Re:why do people consider this hype? (1)

Onymous Coward (97719) | more than 5 years ago | (#25977723)

yes his attack only involves one dns server

I think this is better said as "the attack undermines any vulnerable caching DNS resolver".

People need to distinguish between DNS servers and caching resolvers.

...invisibly

To be effective you need to redirect people to a machine under your control. Some "downstream" resolvers would log the poisoned results, thus getting you the IP of such a machine and a step closer to the perpetrator.

As far as hype, there are a lot of people out there who are quick to judge a situation based on perceived personalities rather than details of the facts or are quick to think about things emotionally (i.e., what they want or fear). This vuln is very big and very important and very scary. Some of the media around it sensationalize this, which doesn't help.

If more folks ran DJB's dnscache then more folks wouldn't be as scared and would probably be more inclined to nodding at the importance of the vuln. (And less inclined to thinking Kaminsky's discovery was unprecedented.)

DJB's dnscache (half of the djbdns suite): Randomizes source port, distrusts glue.

Re:why do people consider this hype? (1)

Effugas (2378) | more than 5 years ago | (#25978265)

Glue distrust isn't that big of a deal. It's sufficiently damaging to the browser security model just to inject arbitrary subdomains into extant domains.

And, no offense to DJB, but port randomization is not by itself a sufficient response to the birthday attack. Come on, we've known not to have simultaneous outstanding requests for the same name for the last six years.

It was much lower than 2^16 (1)

gebi (1422759) | more than 5 years ago | (#25972783)

As we can send multiple replies with guessed transaction IDs, we are way off from the original 1 in 2^16. If we send 100 replies we are down to 1/655 and _not_ 1/65535.

Yes, that's the cool part of the attack (1)

billstewart (78916) | more than 5 years ago | (#25977251)

DNS has two things that identify a UDP request - the transaction ID and the request's port number. 16 bits of ID seemed like plenty back in 1983, and many DNS versions didn't randomize the port number (since it's easier to just use 53 both ways through your firewall) before Kaminsky forced them to fix it. By requesting lots of bogus subdomains, you can birthday-attack the system, so you need ~256 guesses instead of 65536, and it's a lot easier to win that race against a real query.

But even the port-number fixes don't get you solid protection - they just raise the attack difficulty by a factor of a few thousand, so the attacker has to be a bit more determined. But an attacker doesn't need to be successful on every target or every DNS server to make money - there are lots of banks, and lots of users, and sending a few billion packets costs less than the amount he can steal if he's successful.

Changing the protocol would work just as well as deploying DNSSEC - a 128-bit ID would protect against birthday attacks - but that'd be much harder to get deployed. The port-number-randomization approach is at least a stopgap.

Overhyped? (4, Insightful)

gxv (577982) | more than 5 years ago | (#25972941)

Come on. It was really a giant effort to synchronize all the DNS vendors to release patches at the same time. And somehow I don't belive they did that just to boost Kaminsky ego. Give him a credit where credit is due. He discovered a bug that was considered critical by everybody and forced almost everybody on the Internet to upgrade their software. That really is something.

Re:Overhyped? (1)

Ilgaz (86384) | more than 5 years ago | (#25973919)

The issue is so big that people from the entire IT industry, people driving the entire Internet can sit in same room at MS HQ which I believe was chosen for maximum security against espionage and agree on something and simultaneusly release updates without backstabbing eachother.

It must be one of the first in history.

That detail in page 3 ( http://www.wired.com/techbiz/people/magazine/16-12/ff_kaminsky?currentPage=3 [wired.com] ) impressed me.

Re:Overhyped? (1)

mrsbrisby (60242) | more than 5 years ago | (#25974133)

All the DNS vendors except those who were already immune to the attack, you mean: djbdns always randomized port numbers, and never accepted answers to questions it didn't ask (glue).

Meanwhile, we're listening (DNSSEC) to the people who made and support broken (affected) nameservers, instead of to the people who made compatible, but unaffected and unbroken nameservers. This never ceases to bewilder me.

Re:Overhyped? (1)

OneSmartFellow (716217) | more than 5 years ago | (#25975295)

Meanwhile, we're listening (DNSSEC) to the people who made and support broken (affected) nameservers, instead of to the people who made compatible, but unaffected and unbroken nameservers

I thought that was SOP.

The fix or DJB's immunity's is still not enough (1)

billstewart (78916) | more than 5 years ago | (#25977583)

Yes, there were some DNS systems that randomized port numbers already, so they're safe against birthday attacks on the 16-bit ID. DJB's obsessively careful, and at times like this it shows. But the ID's still only 16 bits long, and port numbers only get you another ~16 bits, so a ~2^24 packet attack can still succeed. That's not always going to work, but attackers don't have to win every time to be dangerous - they don't need to attack your account at your bank, as long as they can rip off somebody's account at some bank.

There are two basic approaches to fixing the problem - make the transaction ID enough longer that it can't be spoofed, or add a separate signature mechanism like DNSSEC. The first approach is unrealistic, because you'd need to deploy a new version of the DNS protocol, not just new implementations (even IPv6 keeps the same DNS version and transaction ID, and just adds more record types, which DNS is designed to support) - so good luck with that. The second approach has its difficulties as well, and there are other ways that digital signatures could be added, but DNSSEC is the closest to deployable that we've got.

Re:The fix or DJB's immunity's is still not enough (1)

mrsbrisby (60242) | more than 5 years ago | (#25978055)

You missed the part where djbdns ignores answers to questions it didn't ask.

That means that in addition to getting the 16-bit port number and the 16-bit transaction id, they have to do it after the TTL expired for the record in question, but before the legitimate content server has sent the new (refreshed) information.

That's ridiculously unlikely.

It's intellectually dishonest to say the only way to resolve it is DNSSEC or long XIDs. Furthermore, XIDs and DNSSEC require a similar amount of work to deploy- being as how both are incompatible with DNS, with XIDs being slightly cheaper being as how they are simpler to implement.

Kaminsky had credibility already (1)

billstewart (78916) | more than 5 years ago | (#25977457)

Kaminsky wasn't an unknown - he'd spoken at a couple of Codecon [codecon.org] conferences, doing increasingly heinous things to DNS. One year it was tunnelling SSH over DNS, which lets you break out of any firewall you're behind (and potentially lets malware do the same.) Another year it was the video-over-DNS hack referred to in the article. Codecon's not a big conference, but it's had a lot of high-quality presentations, and when I saw the announcement that Kaminsky had found a serious problem, it had to be more serious than merely breaking through firewalls...

We've been ARP cache poisoning for years... (1)

fibrewire (1132953) | more than 5 years ago | (#25973099)

Everyone I knew in IT in 2004 knew how to do it, even showed me how to do it - thats also the year I started taking Linux seriously, and actually learned how vastly interconnected everything is. Nowadays I have an exponentially greater knowledgebase on inter-networking and how all this stuff actually works, and just NOW it's important that "There is a bug in the Internet?" So if I list a bunch of really hush-hush secrets about how screwed up things REALLY are with the internet, will i get credited with exposing the internet as the "butthole of planetary networks?"

Re:We've been ARP cache poisoning for years... (1)

Effugas (2378) | more than 5 years ago | (#25978289)

Oh come on, ARP cache poisoning is trivial :) There's also a good dozen ways on LAN to hijack all traffic, so you're never fixing that.

Well done, very well done! (1, Insightful)

Anonymous Coward | more than 5 years ago | (#25973165)

Kaminsky, I just think that there are 2 types of flamers out there. One sort is the people who are jealous and wish they had found the bug and the other ones are the type who are angry that it didn't got leaked so fast and they didn't have the chance to use the security hole. I would say that Kaminsky has credit well earned, I cant even imagine what I would have done with that info. "Power tends to corrupt people, and ultimate power tends to corrupt ultimately" don't forget.

Re:Well done, very well done! (1)

David Gerard (12369) | more than 5 years ago | (#25973343)

The thing is: most people are actually honest and wouldn't abuse stuff like this for monetary gain. (Social points, I'll grant you.) This includes security researchers. Note that Kaminsky is an actual security researcher of the sort with an income, not some l33t kid who thinks calling himself a "security researcher" is cooler than what everyone else calls him, an "annoying blight."

Re:Well done, very well done! (1)

Ilgaz (86384) | more than 5 years ago | (#25973885)

The money involved is billions. Lets not forget it. The Kaminsky flaming seems to come from jelousy, the .edu "mafia" and the fact that guy found some kind of security hole that it is there for 3 decades. It is a human thing really.

Working on multi billion Vista pre-release security should have give him enough credit already in professional terms and real life.

He deserves some kind of IT medal, that is what I thought while reading that excellently written article on my 320x200 phone screen and as I know he is an actual Slashdot user (saw his posts), I think he is clever to understand what slashdot comments/flaming are.

Re:Well done, very well done! (0)

Anonymous Coward | more than 5 years ago | (#25975047)

The money involved is billions. Lets not forget it. The Kaminsky flaming seems to come from jelousy, the .edu "mafia" and the fact that guy found some kind of security hole that it is there for 3 decades.

It's just another DNS cache-poisoning attack. I see no need to flame Kaminisky, but deifying him for being able to read an RFC seems a bit much.

If you want to hero-worship Kaminsky, may I point out that he wrote pakketto keiretsu? [doxpara.com] That's actually rather impressive.

Re:Well done, very well done! (1)

Effugas (2378) | more than 5 years ago | (#25979887)

Technically, everything in Paketto comes from a rather evil reading of TCP RFC's :)

Re:Well done, very well done! (0)

Anonymous Coward | more than 5 years ago | (#25974885)

What about the other type of flamer, that realizes it wasn't Dan Kaminsky who 'discovered' this 'bug' and was in fact suggested as a security risk in the early 2000's by a number of other programmers?

It's a shame (0)

Anonymous Coward | more than 5 years ago | (#25973345)

It's a shame how they emphasized everything done in secrecy. I'm for open-ness and full disclosure. Also the media gets false stories when people speculate.

painfully non-technical (0)

peter (3389) | more than 5 years ago | (#25973419)

I wasn't familiar with the attack, and this article isn't really helping much. I guess I'll just look it up elsewhere. I know its not for a technical audience, but I wish people wouldn't say things that are more or less wrong. Since when is a hostname = a web page? This is so wrong that it makes the article painful to read. (Which is unfortunate, because the personal story is somewhat interesting.) And the article has a few more-technical bits later, so why stoop to being so wrong at the start?

a couple examples from the main article:

... He used a software program called Scapy to fire random queries at the system. He liked to see how it would respond and decided to ask for the location of a series of nonexistent Web pages at a Fortune 500 company. Then he tried to trick his DNS server in San Diego into thinking that he knew the location of the bogus pages.

If I didn't understand DNS and HTTP, I might be thinking this had something to do with HTTP 404 errors. Most people have seen the difference between a bad page on a good server and a server that doesn't exist at all.

Suddenly it worked. The server accepted one of the fake pages as real. But so what? He could now supply fake information for a page nobody would ever visit. Then he realized that the server was willing to accept more information from him. Since he had supplied data about one of the company's Web pages, it believed that he was an authoritative source for general information about the company's domain. The server didn't know that the Web page didn't existâ"it was listening to Kaminsky now, as if it had been hypnotized.

Hypnotized? WTF? This sounds like hollywood-hacking to me. Just a case of misplaced trust. Otherwise this paragraph isn't so bad. (except for saying pages instead of names. He already made a directory assistance analogy, why not continue with DNS = phonebook metaphors. e.g. computers need a number to call another computer, but people like to use names... Or don't people understand that web servers are just computers like their own?)

Re:painfully non-technical (0, Redundant)

mr100percent (57156) | more than 5 years ago | (#25974125)

Go check out Kaminsky's powerpoint [doxpara.com] of the whole thing. It's actually a very, very serious bug. I warn you, its 107 slides, but a few dozen into it and you'll see the danger he uncovered.

The part that leaped out (3, Interesting)

klui (457783) | more than 5 years ago | (#25973529)

"...a complete description of the exploit appeared on the Web site of Ptacek's company.... The DNS community had kept the secret for months. The computer security community couldn't keep it 12 days."

Re:The part that leaped out (1, Insightful)

Anonymous Coward | more than 5 years ago | (#25974253)

It's a cliche to say that incompetence, greed and jealousy defines the security industry culture. But no other words can describe the leak. One group worked with operators and quietly patched the world's DNS servers, and went about their jobs. The other group, who demanded information about the vulnerability because they were "security professionals" and therefore deserved to know, promptly instead wrote blog articles and then "accidentally" released them.

It makes you wonder. If that security firm stores "critical secrets" about vulnerabilities in a draft blog post and then accidentally posts them, how do they treat the secrets and confidences of their clients? Do they have a similar careless handling of client data?

It's just unbelievable what the screwed up culture of the infosec community will do to otherwise smart people who know better.

If you're a security professional, and someone gives you a secret, and you find a need to write it down, you'd think encrypted storage would be the way to go, instead of the draft article features of wordpress.

Why "authoritative source for the domain"? (1)

jkbull (453632) | more than 5 years ago | (#25973681)

Since he had supplied data about one of the company's Web pages, it believed that he was an authoritative source for general information about the company's domain.

If this were changed the problem would be considerably mitigated: foof.google.com would be compromised, but www.google.com wouldn't.

So why not do this?

Re:Why "authoritative source for the domain"? (1)

Effugas (2378) | more than 5 years ago | (#25978329)

See http://www.doxpara.com/DMK_Neut_toor.ppt to see why this is still a problem.

Why not use 64-bit key? (1)

dmesg0 (1342071) | more than 5 years ago | (#25974009)

I don't get it, why did they increase the key from 16 to 32-bit, if 32-bit attack is still feasible? Why not use 64-bit (long long) key, which makes the attack practically impossible?

Re:Why not use 64-bit key? (1, Informative)

Anonymous Coward | more than 5 years ago | (#25974163)

Because they didn't increase the the key. They decreased the likelihood of success of the attack through other means, and they did so by enforcing source-port randomization. Now, not only does the attacker have to guess or know the TXID, they have to guess or know the source port of the request.

At least, that's my understanding of it.

It's too deeply embedded in the packet format (1)

billstewart (78916) | more than 5 years ago | (#25977771)

Go read the RFCs for DNS and look at the packet format picures- if you were writing DNS from scratch, that'd be an obvious thing to change (though I'd recommend 128 bits.) But the Transaction ID isn't one of the fields that you get to pick a size for, or one of the record types that you can replace with a newer record type such as IPv6's AAAA records instead of IPv4's A records or the various record types that DNSSEC uses. It's one of the early fields in the packet, always the same size, always 16 bits. Fixing that would require rolling out a whole new version of all the DNS tools in existence, and that's probably harder than getting IPv6 deployed.

What the fixes do is to also use the UDP port number that the query comes from for verification, so your DNS resolver won't accept a response for www.example.com on port 12345 unless it sent the request on that port (many DNS implementations used to send all the requests from UDP 53, and it made firewalling easy.) This was especially easy to implement, because DNS servers already send the response to the port where the request came from, so it only required changing the client end.

The fixes still aren't enough - an attacker now needs to send ~2^24 attack packets, since the transaction ID can still be birthday-attacked, but it's a lot safer the older versions where ~2^8 packets was enough. So we still need something extra, and DNSSEC solves a range of other problems.

Powerpoint (4, Informative)

mr100percent (57156) | more than 5 years ago | (#25974103)

Here's Kaminsky's powerpoint [doxpara.com] given at the Black Hat conference. (106 slides but thorough) This Wired article and the powerpoint is enough to make me panic. He literally broke the internet; unlock any website and spoof any logs. Now I see why there was so much panic in the article.

Re:Powerpoint (1)

ZenDragon (1205104) | more than 5 years ago | (#25976695)

The dude may be tech savvy, but his presentation looks like it was written by a 10 year old.

They make him sound like some sort of James Bond (0, Troll)

eyal0 (912653) | more than 5 years ago | (#25974565)

From the article: "Was the massive patching effort justified, or was Kaminsky just an arrogant, media-hungry braggart?"

Yes and yes.

Vixie Celling Out (1)

fm6 (162816) | more than 5 years ago | (#25977385)

Is it just me, or does it seem like Vixie sometimes gets pretty stupid? He can't be a total idiot, considering all that he's accomplished. But insistence on using landlines for discussions of this issue are pretty laughable. It's true that analog cell conversations were open to anybody with the right kind of radio receiver. But by 2002, nobody who lived in an urban area was still using analog. I believe it's actually harder to tap a digital cell than it is a landline. After all, landlines are analog between the phone and the switch. You can, of course, pull digital conversations of the air with a lot of expensive equipment, but anybody with the resources to do that not somebody you can hide from anyway.

I seem to recall other incidents of weird Vixie fixattions, though I can't remember specifics.

Subscription (0)

Anonymous Coward | more than 5 years ago | (#25977811)

Why do I subscribe to Wired when they post all their print articles online.....

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?