Slashdot Mirror
Kaminsky On DNS Bugs a Year Later and DNSSEC
L3sPau1 writes "Network security researcher Dan Kaminsky has had a year to reflect on the impact of the cache poisoning vulnerability he discovered in the Domain Name System. In the time since, Kaminsky has become an advocate for improving security in DNS, and ultimately, trust on the Internet. One way to do this is with the widespread use of DNSSEC (DNS Security Extensions), which essentially brings PKI to website requests. In this interview, Kaminsky talks about how the implementation of DNSSEC would enable greater security and trust on the Net and provide a platform for the development of new security products and services."
I have never met a bigger group of shysters and con-artists than "security consultants" in all my life.
Kaminsky talks about how the implementation of DNSSEC would enable greater security and trust on the Net and provide a platform for the development of new security products and services
that says it all, right there. This isn't about securing your assets, this is about generating fear so an army of security consultants can sell you an entirely new class of products you don't need.
Kaminsky is incredibly enthusiastic about DNSSEC. ... to the point where someone not too knowledgeable (like I am) wonders if DNSSEC really is that amazing or if he was just high.
Do you even know what DNSSEC is? It is nothing he is trying to sell, it is him trying to completely take care of the flaw he found in DNS last summer. A flaw that could have seriously fubared the net if he didn't go through massive patching with internet providers and large companies. So you know, just about all DNSSEC software is opensource, meaning it is free. He isn't a conartist and it is pretty ignorant to call him one, he spent countless hours last summer trying to get the patch out which he didn't make money off of since he released it for free.
Just because you are wrong and I called you out on it doesn't mean I am a Troll.
.. hit yet.
Security is a tricky thing. You say security people sell you things "you don't need". But if you wait until you NEED security, it is already too late because you have a breach.
Security is not an ER visit, it is a regular preventative exam with your physician. It is something you have to take a pro-active approach with. Yes, this oten means investing time and money in something that has no immediate ROI. But that is the nature of the problem you are dealing with.
http://it.slashdot.org/comments.pl?sid=1134339&cid=26924561
So, did Kamisky find a flaw in dns, or just bind? He's a blowhard.
(I'm not #1311235)
I haven't deployed DNSSEC yet on my external domains because of cost/complexity. When I looked into it, my options for DNSSEC were:
1) implement BIND and do the key management and rotation from the command line
2) spend $10,000 or so for an appliance from secure64 or nixu
3) spend $1k/month for a hosted DNS provider like neustar or verisign
4) install Win2008R2 RC and use it in producition
I work in a windows shop, so I'll probably go with option 4, but I'm surprised there aren't more set-it-and-forget-it tools out there for DNSSEC deployment. I'm open to recommendations.
No, but he did get tons of publicity for a design bug that has been known about since the early 2000s. http://cr.yp.to/djbdns/forgery.html
OK, since Mr. Kaminsky is following this thread, I figured this would be a good place to open up some questions and a discussion between a DNS implementor and Mr. Kaminsky.
Let me introduce myself: My name is Sam Trenholme and I am the implementor of MaraDNS, a recursive and caching DNS server. Right now, I am in the slow process of re-writing the recursive DNS resolver. While MaraDNS has always been as secure as non-DNSSEC can be against Mr. Kaminsky's bug (DJB knew about the problem back in 1999 and I implemented his solution to randomize both the query ID and the source port back in 2001), I am wondering:
How hard is it to implement DNSSEC in my recursive cache? How many RFCs am I going to have to toil over to understand DNSSEC well enough to implement it? About how long will it take me to code MaraDNS to have full DNSSEC support?
I have a bad feeling that DNSSEC is a monster to implement and that we will not see many independent implementations of it; right now BIND and Unbound appear to be the only DNS servers to support it. DjbDNS doesn't support it, of course, and probably never will. My own MaraDNS and PowerDNS also don't support.
What are your thoughts? Has a reasonable effort been made to make DNSSEC easy to implement?
Wow an acronym explained was explained in a slashdot story posting... "DNSSEC (DNS Security Extensions)". Oh, the DNS part wasn't :)
Yeah, I know its a very common acronym.
The kaminsky attack is an attack on a client that is dumb enough to allow to make thousands of dns requests to subdomains of a domain. If the solution is changing to DNSSEC the clients will have to change to DNSSEC too, so we may as well prevent the attack by making the DNS clients smarter. For example a rule could be added that says that if there were more than 10 invalid responses for subdomains of the same domain then when a valid response arrives only to cache the IP for the subdomain requested and not for additional domain names included on the response.
> Do you think the existing system, of X.509 certificates, of SSL CA's, of private PKI's, is at all working? I sure don't.
;) ) even though the cert is valid the browser should give a warning. Wouldn't you want to know if your bank's cert's CA was suddenly changed from one CA to another CA even though the original cert still had 1+ year left to go? But as far as I know, none of the browsers do that.
;).
I don't, IMO they are just a way for Verisign and Friends to collect toll.
But I don't see how DNSSEC fixes that at all, it just makes it easy for Verisign et all to collect yet more toll.
If people were really interested in security they would have the https cert stuff behave a bit more like ssh does, e.g. if the browser notices the cert for myfavbank.com has changed, and now signed by a different CA (from Elbonia
In practice there really is little difference between a self signed cert and one signed by a CA. Like you said - crappy passwords everywhere, and CA's signing stuff blindly. Self signed certs are vulnerable on the "first time", or if/when the cert expires. CA signed certs as currently implemented are vulnerable to the "some idiot CA being tricked/hacked" attack.
Hardly anyone cares, they leave scores of CA certs (30+?) in their browsers, CAs that they don't know at all. And all the certs are left there because people don't want the browser to pop up warnings and "inconvenience" users. And that's the same reason why people pay the CA's money to sign their server certs. It's not about security at all.
Call me cynical, but I feel the same about DNSSEC. Just looking at the complexity and the way it works. It's for collecting toll ala CAs, and it's for making things more complicated so that people can make $$$ from consultancy and support.
But on the bright side I might return to that line one day
Hi Dan,
Stupid question: can whoever holds the root key forge requests from all domains?
e.g. if I am the US government, can I spoof an .ir domain?
Thanks.
I've got verizon and when I look up non-existent TLDs I get back a records of 8.15.7.117, 63.251.179.13, and 67.63.55.15.
Now, maybe that would be cool if I were using their DNS servers but I'm using dnscache running on localhost, so they're hijacking requests to root servers.
So, WTF, and will DNSSEC make any difference in this?
I was actually thinking about this the other day.
Http has absolutely no security at all built into the protocol. It is all hacked together with cookies and the server remembering sessions etc.
The protocol itself is dumb. Make a request... get a response, thats it. Any security is on top of that.
If there was a standard for secure HTTP, all of these gimmicks and schemes could be removed from the hundreds of web frameworks and implemented in the browser / http server.
Cache Poisoning has been around for years, using in the manner he did has not.
Just because you are wrong and I called you out on it doesn't mean I am a Troll.
That's kind of the point. Dan has found a flaw in the basement of your house.
The entire house is in jeopardy, no matter how well built. Every house affected.
Do you :
A: Call Kaminsky a damn liar, denounce his snake oil, sip your turpentine.
B: Stucco and paint every 10 days, whistling to yourself forcefully.
C: Try to jackhammer out the flaw and form up some new foundation meantime
D: Nuke the house from orbit, start from scratch, total web tech re-over in IPv6
I think Dan proposes C and eventually D. Most people stuck on A and B.
But hey, when the internet fails, just think of all the free time you'll have.
But since I don't claim to understand DNSSEC I'll ask it: how secure is DNSSEC against abuse by governments?
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
DNSSEC must be the most wildly overrated technology to ever come out of the internet.
Seriously, it's just terrible from a system administrator's perspective.
It's been a year since I listened to a speech about DNSSEC (from an official ISC representative) at a Linux User Group meeting, so I don't have every last detail on the tip of my brain. However, it provides a little more security in some ways, while making other things worse.
Among the highlights:
- You need to sign your DNS zones every thirty days or so, because the crypto in DNSSEC isn't really that good for speed optimization reasons
- If the signatures on your DNS zones expire, any validating DNSSEC resolver will pretend like your zone doesn't exist (since it was too late to use anything other than NXDOMAIN to indicate signing problems to keep backwards compatibility)
- You therefore need to set up a cron job on a second server to make sure that the DNS zones were signed properly. At the time this bug was published, there weren't any tools to do this in a sane manner, so you'd have to write your own scripts
- If you are an ISP, running a validating DNSSEC compatible resolver will likely end in more customer complaints, since it treats signed-but-expired DNS zones as NXDOMAIN, whereas a standard DNS setup would continue to work. Paul Vixie himself ran into this problem with one of his domains, forgetting to sign the zone in time and having it fall off the internet for anyone using a DNSSEC enabled resolver.
- As one of the new requirements of DNSSEC, it is now impossible to not publish a list of every single subdomain on your DNS zone. This is because every record in the zone has a pointer to the next record, kind of like a circular linked list. ISC maintains that this is no big deal, but there are plenty of people (myself included) that feel otherwise.
- The root and second level DNS providers are probably not going to support DNSSEC, or at least that was the feeling a year ago. As a result, ISC came up with something called DLV, or Domain Lookaside Validation (RFC 5074). This essentially sets up ISC as the official arbiter of which second level DNS zones (like google.com, microsoft.com, etc) are official and can sign their own zones.
ISC may not be selling anything, but they stand to gain significantly if they become the de facto authority on which internet domains are valid, and the presentation was more full of FUD than anything I had ever heard come out of Microsoft. Seriously.
I got the strong feeling that DNSSEC in general really feels half baked and rushed out, rather than something simple and well thought out. I would advise everyone to avoid it like the plague, and hold out for a better solution.
You don't host anything for real paying customers do you?
Let me give you a summary of how interaction with "security consultants" usually goes:
1. Customer gets cold called or sees some FUD on local TV, or portscans or the "consultant" has some dude in Malaysia digging around to find the sites hosted for pennies an hour.
2. Customer gets bilked out of a couple hundred dollars for a 'security audit' (a scan using a common tool with default settings usually)
3. Customer fails to understand any of it.
4. Passes a FUD report on to my desk, and proceeds to piss and moan or wring hands.
5. I have to stop what I am doing and examine the bogus report, then make a time consuming write up, explaining why having port 80 open is not a big deal and that it's typically not possible to be running both IIS and AIX (Unix) on the same box.
6. "security consultant" either tries to sell the user a open source program, Barracuda box (puke) or just laughs all the way to the bank, or even better yet starts bugging me about being honest with the customer (who is now unhappy about the fee charged).
This sequence repeats with every new BS bug, news story, or any time the economy is flush with IT money.
The "security consultant" is never really concerned about security, only money. Most of the time they don't know anything, sometimes they are outright brain-dead stupid and want to do things like put a notice "Please do not hack our web site" on every page because they think it won't be illegal to deface if the notice is not there. (Yes, that's really what they wanted.)
Replace the "security consultant" with the following types; "copyright protection scanning" and "defacement warning monitoring" (THAT is a bullshit scam) and "version back ups" and you have a whole world of suck. Thankfully the economy has been bad for a while so mom&pop shops are slamming the door on a two hundred dollar expense for an audit.
Maybe Kimansky himself won't be doing this, however a legion of other folks will be following shortly behind that will. The dream to update DNS is nice, but it's a stupidly impractical thing to be demanding everybody do right now. Aside from a few articles here and there, the "real world exploits" for this stuff, where someone actually gets harmed... well, where are THOSE reports?
Well, I think you've done a GREAT job, & the fools that are attempting to "put you down" here are only botmasters/malware makers/"hacker-cracker" types were I to judge they (& yes, I am with that statement)... so, so much for them.
From my side of the playing field, & in regards to your efforts + findings?
Well - Your findings have helped me strengthen the case(s) I have that favor customized HOSTS files in fact!
I say that, because until you really CAN fully trust DNS servers & their returned data over port 53 udp requests (the case for most folks, as most do not have DNS servers of their own doing zone transfers over tcp)?
Your findings + efforts to stop that have opened MY EYES & those of others as well, as to problems in the Domain Name System... & thus, this IS a case (not just the added speed) for doing hardcoded IP-to-URL equations in a HOSTS file, so you don't HAVE to perform those types of queries (& who knows if they CAN be trusted, & are not DNS poisoned misdirects)...
I also believe it can stop/stall what is going on over in Germany lately, per this article here from the other day -> A Black Day For Internet Freedom In Germany
http://slashdot.org/comments.pl?sid=1270901&cid=28364263 as well, & per my comments there in that url?
In fact, in regards to the points I put up there? You're JUST THE GUY I WOULD LIKE TO SEE HIS VIEWS ON THAT & THE POINTS I BROUGHT UP THERE IN IT...
Thanks!
Sincerely,
APK
P.S.=> Keep up the good work, as cliche as that sounds... you're doing great, & for what appears to be solely for the good of others, & out of the kindness of your own heart - if the world had more folks in it of THAT nature? It'd be a better place! apk
Aside from a few articles here and there, the "real world exploits" for this stuff, where someone actually gets harmed... well, where are THOSE reports?
Since Dan Kaminsky is active in this thread, I'd love to see him answer this question. I'm guessing he's probably bound by non-disclosure agreements and can't give us any details, but I'd like to know if he's seen succesful, real-world attacks out "in the wild" that resulted in real damage done.
Thanks, Sam, I appreciate your taking the time to keep us annoying users informed!
The DNS cache poisoning attack was used the same week it was put into metasploit on a Verizon DNS in Texas where the attacker was forwarding people to a fake Google page with malware on it. Just one I can recall from when this first came out.
Just because you are wrong and I called you out on it doesn't mean I am a Troll.
Security is a process... not necessarily a product or a deployment of a new technology.
DNSSEC has the ability help, but its no substitute for proper design, management, and the continuing upgrade/improvement roadmap thereto. Anything and everything eventually is found to have weaknesses. True security is the ability to stay at least one step ahead of the bad guys.
Q: Why is starting a comment in the Subject: line incredibly annoying?
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
"He's not going to let you suck his cock, no matter how much asslicking you do." - by Anonymous Coward on Thursday June 25, @03:28PM (#28470615)
Sorry to diappoint you, but I am not a homosexual - so, go find another dish: I'm NOT on the "menu"...
APK
P.S.=> Trolls - TOO easy to "put in their place", lol... apk
The slashdot discussion is focussing on the implications for DNS itself, when DNS is the least interesting benefit from DNSSEC.
Kaminsky, FTA:
Yes, this oten means investing time and money in something that has no immediate ROI. But that is the nature of the problem you are dealing with.
Not only that, but if you invest and it actually works, you get the impression you wasted money, because nothing happens. :P
It's the same thing with Global Climate Change. If we actually fight it tooth and nail, the best we can hope for is no change from the present. Hardly a reward! ;)
I think my comments to the NTIA on DNSSEC hit the point on Kaminsky and the DNS scam. As others pointed out, this is a group of shysters. MIT's "Technology Review" picked up the "Media Hack" aspect of the Story in December. That article is a good read if someone has a link.
Here are my NTIA comments which detail the Kaminsky/Vixie scam aspects and expose problems with DNSSEC:
http://www.ntia.doc.gov/dns/comments/comment027.pdf
One of the things not detailed in my NTIA comments is that Kaminsky tells people to move to OpenDNS.ORG, run by Vixie associates David Ulevitch and Bill Fumerola. Fumerola is also a friend of Chris Neill. IADL has a page on Neill and his connection to spam-abuse at
http://www.iadl.org/cn/cn-story.html
On .ORG Signing
While the .ORG TLD was indeed recently signed, I could not get .ORG TLD officials to respond to questions about whether there was regulatory approval for their actions. It is also telling that Vixie is involved with .ORG TLD. The .ORG signing appears to be an effort at "persuasion"--Sort of 'See, we did it'. But as my NTIA comments spell out, there are two serious DDoS attacks created by DNSSEC. While one perhaps might block .ORG servers during an attack, one cannot block the root DNS servers.
(This is Dan)
Trust me, I'm raising more hell than you can imagine about the deployment issues of DNSSEC. Here's the truth:
1) You don't actually need to do all that resigning stuff. When best practices involve increasing your costs 100x, something is wrong. .org is signed. .com is coming, as is the root itself. Things have changed.
2) You don't actually need to have your signatures expire.
3) You don't actually need that cron job.
4) They fixed that zone walking problem with NSEC3. If you have online keysigning, which I expect everyone to have, you don't even need that.
5)
Standby. Seriously, this is coming, and it's not going to be miserable by the time you actually need to deploy it.
(This is Dan)
There's lots of shysters in every field. Doesn't change the fact that there are problems out there that need fixing. Security is in fact a problem.
In concrete terms, just for my vuln, about 1% of one of Brazil's largest bank's customers had their info taken by my bug. That wasn't fun. And China Netcom got hit pretty hard too, go Google that. Of course, there's a lot of data we're missing, because nobody needs to report. But anecdotally, this was a problem, but not the end of the world. Good! I didn't exactly set out to end the world :)
In terms of what I see fixing, I see a lot of technologies repeatedly sold as "and then you get certificates", and nobody does, because it's just such a cross organizational nightmare to manage. Certs aren't working, and it's holding back auth technology after auth technology. Verizon Business' data says that 60% of vulns aren't implementation flaws -- they're authentication flaws, with passwords at the heart of them.
Why so many passwords? Because they work. Well, DNS works too. Maybe we can use it to make all the better things scale across organizational boundaries.
- If you are an ISP, running a validating DNSSEC compatible resolver will likely end in more customer complaints, since it treats signed-but-expired DNS zones as NXDOMAIN, whereas a standard DNS setup would continue to work. Paul Vixie himself ran into this problem with one of his domains, forgetting to sign the zone in time and having it fall off the internet for anyone using a DNSSEC enabled resolver.
False. The recursor will also return SERVFAIL.
- As one of the new requirements of DNSSEC, it is now impossible to not publish a list of every single subdomain on your DNS zone.
False. Look up NSEC3.
- The root and second level DNS providers are probably not going to support DNSSEC, or at least that was the feeling a year ago.
Yeah, that was a year ago. Search Slashdot for announcments of TLDs and even the root that they support DNSSEC or will do so in the close future.
In BIND and a few others. But others again, like powerdns, already did the suggested randomization.
The flaw is really in DNS - the only authentication field in a DNS request is a 16-bit query id, plus the implicit authentication of a 16-bit port number, and IIRC correctly you could also birthday-attack the query-id. Kaminsky's changes to DNS implementations such as BIND (which was build into djbdns etc. since the beginning) get you a few more bits of protection against an attack, but that just means that DNS is "still pretty weak" as opposed to "really really weak".
And unfortunately, IPv6 DNS is no better - it keeps the same basic header for compatibility, adds some new longer record types, and adds some 128-bit addressing, but the QueryID's still the same old 16 bits.
DNSSEC gets to the root of the problem, with cryptographic signatures on the data. It may be overkill compared to just putting in a 128-bit or 256-bit Query-ID field, but basically it's something that's possible actually get deployed, because it's a set of additional data transported in DNS, not a replacement for DNS's transport protocols. The reasons it wasn't done years ago have a lot to do with the NSA/FBI anti-crypto policies of the 90s, and Verisign's reluctance to do a huge amount of work nobody cares about to protect .com, but we're finally getting the root signed.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
DNS doesn't take up a lot of network bits - at the beginning of a data flow, you typically look up a DNS name to find the IP address, then start doing things, and even if all you're doing is a small text email or fetching a small text html page, the protocol headers alone are a lot bigger than the DNS query, and usually the data's a lot bigger. Changing to DNSSEC adds a few hundred bytes to that query, but it's almost always a drop in the bucket.
Of course, if you're a big name server, like one of the root or .com authoritative servers, or a big ISP's caching name server, that's different, since almost all your traffic is DNS. But that's not a lot of servers, though the overall load on them will obviously increase for a variety of reasons. On the other hand, if they get rid of DNS name kiting, a lot of the junk traffic will go down.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Some parts of the DNSSEC process invite clean UI connections - setting the keys, running human-oriented query tool, etc. It's far easier if you include registering the key as part of the process of registering the name, of course. But that's not how most people use DNS.
So you type a URL into your browser, and the browser hands it to a a resolver client, and the resolver client does a query. With Vanilla DNS, if the query fails, the client tells the browser it fails, and the browser either gives you some "can't find bad.example.com" message, or all too commonly hands your query off to a search engine which gives you a page of "Bad Examples For Sale!!" With DNSSEC, there's another possibility which your browser designer had not considered, and which your DNS client may or may not have considered, which is that it gets a DNS response back, but the response's signature is bad, or the response doesn't have a signature even though it should. What does the client tell the browser, and what does the browser tell the user? And does the user have a bloody clue what to do about it?
Another popular misbehaviour today is that the DNS server your resolver client talked to couldn't find the domain, so _it_ gave you the IP address of an HTTP server that responds to URL requests with queries for Bad Examples. This is an annoying behaviour if you're using a browser, but it's much more annoying if you weren't doing HTTP at all - you were trying to send email or telnet/ssh or connect to an IRC server or doing HTTPS on Port 443 or doing HTTP but on Port 8080, etc., and in most of those cases the DNS service's http server doesn't have those other services. Also, you might have been checking the IP address because you got mail from random-junk-dadfsadfdsaf.com, and your mail handler is trying to find out whether it exists (if not, it's guaranteed to be spam.) Will DNSSEC force ISPs to stop using that kind of DNS service/server? Or will you get even more incomprehensible responses, like a bad DNSSEC signature on the original query getting replaced by a valid signature on a DNS response from misbehaving-DNS-service.com's http server?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I occasionally see posts by Dean Anderson at av8.net on the North American Network Operators' Group (NANOG) - almost always obsessive flames about Paul Vixie.
I'm not sure if this post fails the "Don't feed the trolls" test or not, but it sort of needs to be said.
Nothing's perfect, but the DNSSEC signature process is mostly out in the open - you can see the public keys for the name servers, and you can check the signatures on the keys for yourself, and you can also get yourself domain names almost anywhere in the world if you don't like a given registrar/registry. So while a government _could_ probably bully a registry into signing a forged certificate for your domain name, it would at least be publicly visible that "your" key had changed.
Also, the government foot-dragging that's delayed DNSSEC deployment and root/com signing for so many years has led to the development of "Trust Anchors", which are a mechanism for getting DNSSEC keys and validation independent of the upper DNS hierarchy, and they provide an extra mechanism for verifying keys.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
here! here!
(This is Dan)
To be fair, I don't see much of a difference between NXDOMAIN and SERVFAIL except possibly impact on negative caching. Stuff doesn't work.
DNSSEC planners have been way, way too willing to let things break in order to protect non-critical features. DNS is not allowed to just return SERVFAIL. Luckily, the protocol itself is flexible enough to allow much more stable deployments.
See my subject-line above, & you get, what you get is all...
APK
I forgot that the subject line