The Backstory of the Kaminsky Bug

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.

Comments

Slashdotted

[Vertana]

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

[socsoc]

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

[Vertana]

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

[nicolas.kassis]

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

[socsoc]

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

[snowtigger]

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

[socsoc]

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

[SanityInAnarchy]

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

[Vertana]

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

[Anonymous Coward]

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

Re:Slashdotted

[Vertana]

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

[nicolas.kassis]

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

[Vertana]

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

[Effugas]

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

[SanityInAnarchy]

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

[SanityInAnarchy]

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

[Garridan]

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

Re:Slashdotted

[ArsenneLupin]

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 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

[ArsenneLupin]

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

[ArsenneLupin]

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 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

[lloydchristmas759]

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

[vidarh]

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

[ArsenneLupin]

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.

Re:Slashdotted

[peter]

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).

Re:Slashdotted

[theaveng]

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."

Re:Slashdotted

[tepples]

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

[Theoboley]

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

Re:Slashdotted

[SanityInAnarchy]

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

[SanityInAnarchy]

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

[Anonymous Coward]

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

[SanityInAnarchy]

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

[MikeBabcock]

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

[SpiritOfGrandeur]

But you can take over the whitelist also, I mean the extension does update over the INTERNET using DNS names!

DNS is Not Secure

[Anonymous Coward]

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

DNSSEC

[chrome]

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

Re:DNSSEC

[Anonymous Coward]

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

Re:DNSSEC

[rabbit994]

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.

Do I not understand?

[pavera]

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?

[prockcore]

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?

[cleatsupkeep]

They have to update their cache at some point.

Re:Do I not understand?

[cencithomas]

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?

[Anonymous Coward]

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?

[ArsenneLupin]

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?

[bpkiwi]

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?

[peter]

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?

[peter]

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 linked from http://www.isp-planet.com/equipment/2008/nominum+vantio.html

  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?

[MikeBabcock]

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).

Re:Do I not understand?

[pavera]

That's fine and all... but why does DNS cache the "extra" info at all? I can understand sending it along in an RR, as that saves a trip, but I would say the "rule" should be, no DNS server should cache anything it didn't explicitly ask for. That change alone eliminates this problem completely, and yeah it will increase some traffic because things can't be cached that are being cached now, but, it wouldn't be hard for the server to be set up if it gets a CNAME back, to then query specifically for that name if it wants to cache it.

Re:Do I not understand?

[pavera]

I see that the glue is useful, if only in decreasing transaction volume. But my real question was "why do we cache the glue". I would say the rule should be "if it isn't exactly what I asked for, I won't cache it". This would stop someone being able to poison the cache through a response to a different question.

We could make the DNS servers smarter... IE if I ask for www.example.com and the root replies with a list of NS servers for .com, well I can use that answer including the glue IN THIS TRANSACTION only to then skip the extra request to get the IPs of the NS servers, if I want to cache the IPs of the .com NS servers, then I need to make an explicit request asking for the A record of the NS.

Seems like this would be a pretty simple change in the DNS server software itself, and it would only increase traffic initially to the root servers, or periodically when caches expire, DNS servers would then not overwrite their cache with anything from the glue, which to me seems like the root of this problem

Re:Do I not understand?

[Wowlapalooza]

No, that's not it. If the perp controls the domain.com domain, they don't need to play any CNAME tricks, they can spoof www.domain.com directly.

In simple terms, the Kaminsky exploit fools a caching nameserver's notion of what addresses are associated with example.com's nameservers, by eliciting a bunch of doomed-to-failure queries of names underneath example.com (e.g. a.example.com, aa.example.com, xyz.example.com) along with fake, source-address-spoofed answers to those queries. Eventually the query ID # matches, the caching nameserver accepts the response, including the NS records and associated A/AAAA records (collectively called "glue") in the response identifying the example.com nameservers, and subsequent queries of all example.com names -- including the omnipresent www.example.com -- are redirected to the bad guy's nameservers, until the TTL on the glue records expire.

The reason for not just querying the same name under example.com is because negative caching would substantially drive up the number of packets required for a successful attack. That's the innovation that Kaminsky brought to bear on the scenario; using a series of doomed-to-failure subdomain queries instead of the same name over and over. That makes the attack much faster, and thus far more likely to be successful in the limited-time windows that hackers have available to them for source-address spoofing.

The long-term fix is something like DNSSEC to crypto-authenticate the packets. In the meantime, randomizing the source ports of queries adds enough entropy, in addition to randomizing the query ID #, that the packet volume of a would-be attacker is (hopefully) detected and their attempt blocked before it succeeds

You might want to check out http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html, which appears to be a fairly good "beginner's guide to iterative DNS resolution and its vulnerability to the Kaminsky attack" document. Lots of pretty diagrams...

Re:Do I not understand?

[ArsenneLupin]

Actually, the example I chose (CNAMEs) was not the place where this "extra information" is the most necessary. For CNAMEs, it's only an optimization. However, in another case, namely NS it is more fundamental.

Indeed, when resolving test.mydomain.lu, the client nameserver first has to find out which server is responsible for mydomain.lu. In order to do so, it first asks the servers responsible for .lu to find out who is responsible for mydomain.lu. In most cases, the answer will be ns.mydomain.lu or somesuch (NS record). Like a CNAME, this will have to be resolved to an IP. However, if this NS-to-IP resolution went the normal way, we'd have a chicken and egg problem. Indeed, ns.mydomain.lu lies within the mydomain.lu domain itself, an the client DNS does not yet know who is the authoritative server for mydomain.lu. Fortunately, also in this case, "extra" information is sent along with the first response, allowing the query to proceed.

Switching off this feature (or making it uncachable) would basically make any delegation way less efficient, and much harder on the roots, or it would force to make the NS record point to a server out of the domain it serves (which is not common practice nowadays).

Re:Do I not understand?

[pavera]

well... could you not condense the "baliwick" to say in this case the NS record is ns.mydomain.lu, so I can cache things in the glue that pertain to ONLY THAT exact host name?

To me the fundamental problem is that in the DNS system as it currently stands, the "client" can ask one question and get back an unrelated answer (IE I asked for the nothere.mydomain.com address, and got back an answer for www.mydomain.com (in the glue), so I'll happily cache that...) when I should only be caching things I asked for... In the chicken and egg problem, if I ask for an authoritative source of info, I'm expecting an NS record and some glue with the A record for that NS, that would in my mind be a valid thing to cache, it is what I asked for, if the glue also contains an A record for www.mydomain.com, well tough, I can't cache it www.mydomain.com does not match the name in the NS record... I just can't see how limiting the caching to that level of exactness would necessarily completely break the system.

Granted, someone could try to use this to still take over the whole domain (IE, I ask for who's authoritative for a domain, and then I get blasted with responses saying "attackers site!") but that attack would be much less likely to succeed, because you wouldn't have the opportunity to keep asking for unknown hosts, once the server asked once for the domain, it would cache the NS, and no longer ask on each successive query for a non-existent A record for the authoritative NS for the domain... until the TTL on the NS record was reached...

Re:Ant

[Ethanol-fueled]

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.

Totallylookslike

[Dirtside]

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

why do people consider this hype?

[circletimessquare]

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?

[he-sk]

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?

[spandex_panda]

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?

[Onymous Coward]

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?

[Anonymous Coward]

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?

[Effugas]

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.

Re:why do people consider this hype?

[Onymous Coward]

Glue distrust isn't that big of a deal.

Well, technically, glue trust is a big deal. It enables corruption of existing domains. That's a big deal. I think your point is that there are other, overshadowing problems. That may be the case; I am only familiar with this aspect of how DNS poisoning is a big deal. What specific problems arise from being able to add arbitrary subdomains in a browser context?

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.

Port randomization helps. I don't think there's any offense to be had on DJB's part; port randomization was never said to be sufficient. Defense in depth means doing what you can where you can, "practical mitigation". DJB advised port randomization (and non-colliding queries) at least seven years ago. The CERT advisory came out a year later.

Re:why do people consider this hype?

[kayditty]

apart from the stupidity and uselessness of your post, doesn't your "example" rely entirely upon one's conception of "self?" maybe children are onto something. if my eyes are [the] window into me, then you cannot possibly see me if I can't see you.

Re:why do people consider this hype?

[Effugas]

Well, for one thing, 1.www.google.com has access to the www.google.com cookie. It's also a really good place to phish from. In some circumstances, document.domain is even set up such that 1.www.google.com has script level access to www.google.com. Not good.

At this point, BIND, Nominum, Unbound, and Microsoft all suppress colliding queries. The only name server I know of that doesn't is DJBDNS, and it drops its security level noticeably.

Re:why do people consider this hype?

[he-sk]

By your logic, if I wear sunglasses then I can see you, but you can't see me, right?

And no, the children are most definitely not onto something. This behavior is a classic tell-tale that the child's cognitive development is in a pre-operational phase and that it cannot distinguish between itself and the world around it. It supposes that every person sees the world just like the child itself does and has access to the same data. That assumption is obviously wrong, because the child, just like every other person, has a unique perspective on its own thoughts and feelings.

Some further reading: http://en.wikipedia.org/wiki/Theory_of_cognitive_development and http://en.wikipedia.org/wiki/Jean_Piaget

But thanks for playing.

Re:why do people consider this hype?

[Onymous Coward]

Well, for one thing, 1.www.google.com has access to the www.google.com cookie. It's also a really good place to phish from. In some circumstances, document.domain is even set up such that 1.www.google.com has script level access to www.google.com. Not good.

That makes sense. Nonexistent, subdomain host poisoning is also a serious problem.

Taking over existing domains is a superset of that serious problem, and can be done with the same style attack, just by adding glue. Because existing hijackable domains include nameserver domains, you could take over all DNS for google.com, from webservers and mail servers to SPF and DKIM records.

Anyway, it's all bad. Yes, poisoning is bad.

At this point, BIND, Nominum, Unbound, and Microsoft all suppress colliding queries. The only name server I know of that doesn't is DJBDNS, and it drops its security level noticeably.

DJB was the first to point out that Source Port Randomization would help, years ago, and he gets no credit? Why not concede any? And how many of those servers you named have been open to an easily feasible 32,000 max packet poisoning attack for the eight years that djbdns was requiring a TXID + SPR packet attack? And now you're trying to ding djbdns, characterizing it as a less secure outlier, for allowing 200 simultaneous queries, which opens the space by not quite 8 bits? TXID + SPR for djbdns is still 24 bits. TXID + SPR is only 27 for Microsoft (2500 source ports).

Scheier:

The real lesson is that the patch treadmill doesn't work, and it hasn't for years. This cycle of finding security holes and rushing to patch them before the bad guys exploit those vulnerabilities is expensive, inefficient and incomplete. We need to design security into our systems right from the beginning. We need assurance. We need security engineers involved in system design. This process won't prevent every vulnerability, but it's much more secure -- and cheaper -- than the patch treadmill we're all on now.

What a security engineer brings to the problem is a particular mindset. He thinks about systems from a security perspective. It's not that he discovers all possible attacks before the bad guys do; it's more that he anticipates potential types of attacks, and defends against them even if he doesn't know their details. I see this all the time in good cryptographic designs. It's over-engineering based on intuition, but if the security engineer has good intuition, it generally works.

Kaminsky's vulnerability is a perfect example of this. Years ago, cryptographer Daniel J. Bernstein looked at DNS security and decided that Source Port Randomization was a smart design choice. That's exactly the work-around being rolled out now following Kaminsky's discovery. Bernstein didn't discover Kaminsky's attack; instead, he saw a general class of attacks and realized that this enhancement could protect against them. Consequently, the DNS program he wrote in 2000, djbdns, doesn't need to be patched; it's already immune to Kaminsky's attack.

That's what a good design looks like. ...

I'm not a DJB fanboy. I concede that I think the 200 simultaneous identical queries is a big loss of security. But I also recognize that DJB was doing the right thing nearly a decade ago, and warning people, while everyone else took until now, after disclosure of a specific, very bad vuln, to clean up their acts. I find it distasteful that people are reluctant to publicly acknowledge DJB's right thinking, or even to acknowledge it to themselves. That's the other face of fanboyism, just inverted from fan to detractor.

Re:why do people consider this hype?

[kayditty]

By your logic, if I wear sunglasses then I can see you, but you can't see me, right?

what logic, exactly? but sure. that's right. you're welcome??

It was much lower than 2^16

[gebi]

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.

Scaremongering works wonders

[Anonymous Coward]

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

[Anonymous Coward]

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.

Overhyped?

[gxv]

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?

[Ilgaz]

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 ) impressed me.

Re:Overhyped?

[mrsbrisby]

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?

[OneSmartFellow]

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.

We've been ARP cache poisoning for years...

[fibrewire]

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...

[Effugas]

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.

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

[bogie]

If you would bother to read the article you'd see that this bug was extremely serious and had the potential to easily hose much of the internet. Yes much of the Internet. Nothing your talking about would ever come close to what he figured out. If you really are interested in the way networks work then you'll find the article quite amusing to say the least.

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

[fibrewire]

We've been looking for you, Mr Anderson...

Well done, very well done!

[Anonymous Coward]

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!

[David Gerard]

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!

[Ilgaz]

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!

[Anonymous Coward]

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?

Re:Well done, very well done!

[Anonymous Coward]

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? That's actually rather impressive.

Re:Well done, very well done!

[Effugas]

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

It's a shame

[Anonymous Coward]

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

[peter]

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

[mr100percent]

Go check out Kaminsky's powerpoint 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

[klui]

"...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

[Anonymous Coward]

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"?

[jkbull]

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"?

[Effugas]

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

Why not use 64-bit key?

[dmesg0]

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?

[Anonymous Coward]

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.

Powerpoint

[mr100percent]

Here's Kaminsky's powerpoint 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

[ZenDragon]

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

[eyal0]

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

Yes and yes.

The Backstory of the Kaminsky Bug

[POTSandPANS]

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.

Well, yeah.

[Grendel Drago]

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 (a very exploitable situation), 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 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. But we're not there.

Re:Well, yeah.

[socsoc]

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.

[Onymous Coward]

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?

Why we don't have DNSSEC yet

[billstewart]

A few things have changed since my 2003 /. post 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 Ru

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

[Grendel Drago]

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, 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 (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.

Yes, that's the cool part of the attack

[billstewart]

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.

Vixie Celling Out

[fm6]

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.

Kaminsky had credibility already

[billstewart]

Kaminsky wasn't an unknown - he'd spoken at a couple of Codecon 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...

The fix or DJB's immunity's is still not enough

[billstewart]

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

[mrsbrisby]

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.

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

[MikeBabcock]

"What she said" or +1 Insightful

dnscache (the relevant part of djbdns) is pretty smart, and pretty paranoid, and when things like this come up, DJB deserves a good round of "I told you so."

The problem here is that some people don't understand how anyone expects to attack these banking sites without also replicating their SSL certificates for secure login. The issue is that most banking sites and others with secure logins don't have a signed page for the login but for the target page of the login, and most browsers don't indicate that the submission of a given login form goes to a secure server or not (until after clicking, and only IF the user hasn't disabled that notice).

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

[mrsbrisby]

The problem here is that some people don't understand how anyone expects to attack these banking sites without also replicating their SSL certificates for secure login.

Eh, I think it's a big problem that there is a motivating force saying let's trust the guys that caused this problem in the first place. DNSSEC is a replacement to the DNS infrastructure, and the best they've got is we weren't really trying to make something good, when we made DNS. I'd think it pitiful, but look around slashdot: Look at how many people are saying DNSSEC would've fixed this problem.

Anyway. The attack is pretty straightforward. It looks like this:

1. Register a bogus domain name: nvuoqtnvoeqnvkoqekofqe.com
2. Sign up for a certificate for that domain. Answer the email verifying you own the bogus domain.
3. Log your nameservers! The things that connect to you are the things you want to attack.
4. Brute-force poison those caches until you can direct your target.com's domain name to your own servers. Congratulations, as far as the SSL vendor is concerned, you control target.com's mail and web site.
5. Sign up for a certificate for that target.com - this will not be questioned.
6. Congratulations, you have an SSL certificate for target.com! Time to MITM your victims with an SSL-encrypted site. Have a beer, you earned it big guy!

It's not complicated, and if the SSL vendor uses BIND (a safe bet: many vendors are deploying DNSSEC support so that they can start selling more snake oil), it's fairly easy.

It's too deeply embedded in the packet format

[billstewart]

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.

Re:It's too deeply embedded in the packet format

[kayditty]

I don't know what you're talking about. the fix, at least in BIND, was to employ source port randomization, which it should have done years ago (and for which it was chided by people like djb). djdbns wasn't "vulnerable" (technically, all implementations are, since it's a function of computing power + race condition) to this to begin. maybe PowerDNS and some others were also -- I don't really remember. of course you're right, though, that TXIDs have always been 16 bits and always will as long as we're using DNS as we know it. the same can be said for IPv4+UDP. that's already 32 bits, and, as far as I know, almost every DNS cache implementation out there was already checking both port + TXID. it's just that with shitty software, like BIND, it didn't really matter, since source ports (even in 9.0) were pretty horrendously predictable. supposedly now they aren't, so we have approximately 32 bits of "entropy."

what am I missing?

Subscription

[Anonymous Coward]

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

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

[Effugas]

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

[SanityInAnarchy]

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/ 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

[Effugas]

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

[SanityInAnarchy]

Is this true of PayPal, specifically?

Re:They make him sound like some sort of James Bon

[Ungrounded Lightning]

He had a lot to be modest about.

Seems to me he earned the right to brag.

Some "bad guys" are governments

[Ungrounded Lightning]

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.

Not all "bad guys" are individuals. Some are governments.

We already KNOW the NSA can tap any GSM phone they want, anywhere, from satellites. Any bets on whether the Russians can, to? Or whether the Russian Mafia can get the info from them? Or whether there are other players with the capability.

IMHO Vixie did exactly the right thing. Better to secure against a leak that doesn't really exist (when that security doesn't immobilize you) than not secure against one that does.

Re:Some "bad guys" are governments

[fm6]

According to the story "Vixie knew how easy it was to listen in on cell calls". Doesn't sound like he was thinking of the NSA at all. More like all the casual cell eavesdroppers that used to be common when most people were still on analog.

But suppose the NSA is an issue. They never taps landlines? If you're going to be that uptight, you don't fixate on one particular vulnerability. You need a general security strategy. The includes never using any third party channel without securing it first.

What's particularly laughable is this bit:

Vixie began the conversation by reading aloud a series of numbers--a code that would later allow him to authenticate Gustafsson's emails and prove that he was communicating with the right person.

I wonder what that "series of numbers" was? Vixies public key? He could have sent that via any insecure channel (and email is an easier way to copy it without error) and anyway it would certify Vixie to Gustafsson, not vice-versa.

Perhaps the story got garbled in the telling, but it sounds to me like Vixie was sending Gustafsson a symmetric key. That would mean that anybody who was listening in on the conversation would have been able to read every encyrpted email sent between the two of them.

simple countermeasure

[gebi]

Switch to a tcp connection after a few packets with wrong parameters, for the dns querry.

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

[Effugas]

It's everyone with an EV cert.

Green bar is a great marketing ploy, but it really should be an httpsev:// URL handler if we wanted it to be secure. Collin Jackson's done some really good work around this, go google him.