Slashdot Log In
The Backstory of the Kaminsky Bug
Posted by
kdawson
on Wed Dec 03, 2008 12:20 AM
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.'"
This discussion has been archived.
No new comments can be posted.
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...
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...
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)
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
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.
Parent
Re: (Score:2)
Re: (Score:2)
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
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...
Parent
Re: (Score:2, Insightful)
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: (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:2)
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.
Well, yeah. (Score:2)
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 exploitabl [cr.yp.to]
Re: (Score:2)
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,
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:2, Insightful)
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 addre
Re: (Score:2)
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:2)
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
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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 e
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
Re: (Score:2)
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 Backstory of the Kaminsky Bug (Score:2)
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 infec
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)
Re: (Score:2)
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 (Score:2)
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
Do I not understand? (Score:2)
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?
Re: (Score:2)
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: (Score:3, Informative)
They have to update their cache at some point.
Re: (Score:3, Informative)
Re: (Score:2)
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 anot
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.
Parent
Re: (Score:2)
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 sti
Totallylookslike (Score:3, Funny)
Is it just me, or does Paul Vixie look like the Terminator?
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?
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.
Re: (Score:2)
Overhyped? (Score:4, Insightful)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
I thought that was SOP.
The part that leaped out (Score:4, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
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