Is the Kaminsky bug still a problem for sites without DNSSEC?

Question

I have read about the Kaminsky bug, but I don't fully understand how easy it is to use this vulnerability for an attacker.

Are DNS-software updated now so it's not that easy to use this vulnerability for an attacker? or does a secure site need to use DNSSEC to be secure?

E.g. think of an Internet bank. Does it need to use DNSSEC in combination with SSL/TLS to be secure? or is there other ways to be secure for the kaminsky bug?

In august 2010, SecurityWeek listed the Kaminsky bug as the worst DNS security incident in The Top Five Worst DNS Security Incidents

1. “The Kaminsky Bug” puts the whole Internet at risk

Often regarded as possibly the greatest security threat the Internet has ever faced, the so-called “Kaminsky Bug” emerged in July 2008, creating great unease and even greater hype. Researcher Dan Kaminsky discovered that it was easy to exploit a weakness in the DNS and built the software to do it. This weakness would enable malicious hackers to transparently imitate any Web page or e-mail account by poisoning the DNS information cached by Internet service providers.

...

Today, DNSSEC, the new standard security extensions for the DNS protocol, offers the best way of preventing the kind of cache poisoning attack that Kaminsky's findings would have enabled.

Answer 1

Kaminsky isn't the first person to find a DNS cache poising vulnerablity. In fact many of these vulnerability have been found and that is why DNSSEC is important. DNSSEC is a defense in-depth strategy against this attack pattern. However responsible software vendors patch vulnerabilities, and when you find a DNS cache poisoning attack in BIND, it will be fixed immediately.

Answer 2

Does it need to use DNSSEC in combination with SSL/TLS to be secure?

In theory, no. The whole point of SSL/TLS (and cryptography in general) is to guaranty that you talk to the right guy (no matter what, even if DNS is corrupted).

Also, SSL/TLS is mostly useful where your connexion can easily be intercepted; in this case, someone does not need to mess with DNS at all. (Messing with DNS is only useful if you don't have the correct DNS answer cached; messing with the TCP connexion works no matter what.)

It is still possible to come up (to contrive) with a theoretical case such as DNSSEC would be necessary to protect:

1. an adversary does not have the ability to fully control your Internet connexion, and can only inject fake packets (IP packets with a source IP address that does not belong to the adversary);
2. but he knows a weakness of your DNS resolver, and can convince you of an incorrect DNS statement (that bank.com resolves to bad.I.P.address);
3. bad.I.P.address belongs to him, and he runs a web server above SSL/TLS there (known as HTTPS server);
4. either: a) he knows a weakness of your SSL/TLS client such that it can convince your browser that the SSL/TLS server at bad.I.P.address really is "bank.com", or b) he has obtained a SSL/TLS certificate for "bank.com" from a recognized Certificate Authority, by deception (he showed up at their desk claiming to represent "bank.com", by hacking (he knows a weakness in the certificate checking process), by coercion (including legal correction), or by other mean you can think of.

In this case, DNSSEC would still protect you; without DNSSEC, you would connect to the wrong guy with no warnings.

It is extremely unlikely that anyone would make these efforts just to get your bank details, when he can easily get so many account numbers by technically lame means (apparently the lamest fishing fraud still works - or they would stop do it) - unless your bank secret code are much more valuable than the average bank secret code (maybe you have a lot of money, and the ability to transfer any amount to anyone, with just your normal bank account password, and not additional step - a terrible idea in any case).

It seems even less likely that anyone would bother with the interception of credit card number protected by some crypto (any crypto) when they get can plenty at once by hacking the system that stores them (and last I heard, they can still get plenty of numbers at a reasonable price).

But SSL/TLS is used to protect something much more critical than payment data: software downloads. Many downloaded software, notably automatic updates, are only trusted by virtue of being downloaded over a "secure" link (the software package either is not signed or the signature is not checked automatically or by the user, who does not know he can check the package cryptographic signature, or even that there should be a signature).

Unless you run under a strictly segregated environment, downloaded software has the ability to read not just your bank details, but all your personal files, and any data you send over "secure" SSL/TLS links.

Answer 3

Effective defenses against the Kaminsky attack. At risk of over-simplifying, the Kaminsky attack can be used to attack DNS clients that do not use source port randomization. The immediate defense against the Kaminsky attack is to turn on source port randomization. These days, most modern DNS software does perform source port randomization.

(If you haven't done so in a while, I highly recommend that you update your DNS software, on both clients and servers, to get the benefits of this defense.)

The current state. Fortunately, most of the Internet has already upgraded its DNS software to more recent versions that incorporate defenses against the Kaminsky attack. These defenses make the Kaminsky attack quite difficult. (They are not 100% impossible, but they would require a lot of resources: billions of packets.) Therefore, most sites today are likely to be reasonably well protected against the Kaminsky attack. For instance, odds are very good that your ISP and your bank are protected.

If there are any laggards out there who haven't updated their DNS software to a recent version that incorporates defenses against the Kaminsky attack (e.g., source port randomization), then they are likely to be very vulnerable. The Kaminsky attack is quite easy to mount and highly effective, if the server doesn't incorporate defenses against it.

What about DNSSEC? DNSSEC is a separate deal. It is designed to provide security, even in situations where your DNS servers are compromised or where a man-in-the-middle is attacking your network traffic. Therefore, in theory, DNSSEC would provide an acceptable alternative defense against the Kaminsky attack.

However, in practice, relying upon DNSSEC to protect you from the Kaminsky attack would be a lousy idea. There are two problems:

• First, DNSSEC is not widely deployed today. Today, very few domains are signed with DNSSEC. This makes it impossible to deploy DNSSEC with strict validation. Instead, in current DNSSEC implementations, if a response for an unsigned domain is received, the response is accepted without performing any cryptographic checks. This means that a client that is vulnerable to the Kaminsky attack can still be attacked, even if it uses DNSSEC.

• Second, source port randomization is so easy to deploy, whereas DNSSEC is more challenging (operationally and logistically) to deploy. You'd have to be crazy to continue using old vulnerable versions of DNS software. Deploying source port randomization is easy enough (just upgrade to the latest version of your DNS software, in most cases) that it'd be nuts not to take advantage of the source port randomization defense.

DNSSEC is still a very good idea, and the Kaminsky attack underscores the importance of deploying DNSSEC widely. So, don't misinterpret me. I do encourage you to enable DNSSEC on your machines. Just don't view it as a substitute for source port randomization.

In conclusion. Everyone should be using source port randomization. It's a no-brainer, and it is currently the most effective defense against the Kaminsky attack. Fortunately, my impression is that source port randomization is already very widely used, so most of the Internet should be reasonably well defended against the Kaminsky attack.

Taking a longer view, DNSSEC is important because it provides robust protections against a large class of possible attacks against DNS -- even ones we haven't thought of or aren't aware of, but that might be discovered in the future. It is the best prophylactic we have, to proactively prevent future incidents like the Kaminsky attack. Therefore, it would be best for network operators and others to do what they can to deploy DNSSEC with all deliberate speed.