Slashdot Log In
The Backstory of the Kaminsky Bug
Posted by
kdawson
on Wednesday December 03, @12:20AM
from the no-good-deed-goes-unpunished dept.
from the no-good-deed-goes-unpunished dept.
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.
Related Stories
[+]
Massive, Coordinated Patch To the DNS Released 315 comments
tkrabec alerts us to a CERT advisory announcing a massive, multi-vendor DNS patch released today. Early this year, researcher Dan Kaminsky discovered a basic flaw in the DNS that could allow attackers easily to compromise any name server; it also affects clients. Kaminsky has been working in secret with a large group of vendors on a coordinated patch. Eighty-one vendors are listed in the CERT advisory (DOC). Here is the executive overview (PDF) to the CERT advisory — text reproduced at the link above. There's a podcast interview with Dan Kaminsky too. His site has a DNS checker tool on the top page. "The issue is extremely serious, and all name servers should be patched as soon as possible. Updates are also being released for a variety of other platforms since this is a problem with the DNS protocol itself, not a specific implementation. The good news is this is a really strange situation where the fix does not [immediately] reveal the vulnerability and reverse engineering isn't directly possible."
[+]
Technology: Paul Vixie Responds To DNS Hole Skeptics 147 comments
syncro writes "The recent massive, multi-vendor DNS patch advisory related to DNS cache poisoning vulnerability, discovered by Dan Kaminsky, has made headline news. However, the secretive preparation prior to the July 8th announcement and hype around a promised full disclosure of the flaw by Dan on August 7 at the Black Hat conference has generated a fair amount of backlash and skepticism among hackers and the security research community. In a post on CircleID, Paul Vixie offers his usual straightforward response to these allegations. The conclusion: 'Please do the following. First, take the advisory seriously — we're not just a bunch of n00b alarmists, if we tell you your DNS house is on fire, and we hand you a fire hose, take it. Second, take Secure DNS seriously, even though there are intractable problems in its business and governance model — deploy it locally and push on your vendors for the tools and services you need. Third, stop complaining, we've all got a lot of work to do by August 7 and it's a little silly to spend any time arguing when we need to be patching.'"
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Slashdotted (Score:4, Interesting)
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...
Reply to This
Re:Slashdotted (Score:5, Interesting)
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...
Reply to This
Parent
Re: (Score:3, Insightful)
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 (Score:5, Insightful)
Reply to This
Parent
Re:Slashdotted (Score:4, Insightful)
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
Reply to This
Parent
Re:Slashdotted (Score:5, Insightful)
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.
Reply to This
Parent
Re: (Score:2)
Re: (Score:2, Insightful)
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 (Score:4, Insightful)
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...
Reply to This
Parent
Re: (Score:3, Informative)
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: (Score:3, Informative)
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: (Score:2)
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: (Score:3, Insightful)
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: (Score:3, Interesting)
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 existi
DNS is Not Secure (Score:2, Funny)
For recursive acronym, see message subject. Also see the nearest mirror for an example of assmonkey.
DNSSEC (Score:2)
Totallylookslike (Score:3, Funny)
Is it just me, or does Paul Vixie look like the Terminator?
Reply to This
why do people consider this hype? (Score:5, Insightful)
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?
Reply to This
Re: (Score:3, Interesting)
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.
Overhyped? (Score:4, Insightful)
Reply to This
The part that leaped out (Score:4, Interesting)
Reply to This
Powerpoint (Score:5, Informative)
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.
Reply to This
Re:Do I not understand? (Score:5, Informative)
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.
Reply to This
Parent
Re: (Score:3, Informative)
They have to update their cache at some point.
Re: (Score:3, Informative)