Kaminsky provides the why of attacking DNS

LAS VEGAS--Speaking before a packed audience, researcher Dan Kaminsky explained the urgency in having everyone patch their systems: virtually everything we do on the Internet involves a Domain Name System request and therefore is vulnerable.

Expectations were running high before Wednesday morning as Kaminsky, director of penetration testing for IOActive, had revealed little about his DNS vulnerability up till then. That didn't stop others from trying to figure it out. But that actually helped Kaminsky in the end; it meant during his speech, he was able to skip the what and go directly to the why.

Security researchers always thought it was hard to poison DNS records, but Kaminsky said to think of the process as a race, with a good guy and bad guy each trying to get a secret number transaction ID. "You can get there first," he said, "but you can't cross finish line unless you have the secret number."

The question is why would someone bother? Well, Kaminsky talked about how deeply embedded DNS is in our lives. Kaminsky said there are three ages in computer hacking. The first was attacking servers (for example FTP and Telnet). The second was attacking the browsers (for example Javascript and ActiveX). We're now about to enter the third age, where attacking Everything Else is possible.

We know that if we type a name.com into a browser, the DNS resolves it to its numerical address. But what we don't realize is that same process occurs when we send e-mail or when we log onto a Web site. These also require DNS lookup.

Kaminsky then detailed how various security methods on the Web can be defeated if one owns the DNS. For example, if a site wants to establish a Trust Authority Certificate with the Certificate Authorities, they use e-mail to confirm the identity of the requester. He also said that it's possible to poison Google Analytics and even Google AdSense, which also rely on DNS lookup.

Prior to the patch, the bad guy had a 1 in 65,000 chance of getting it because the transaction ID is based, in part, on the port number used. With the patch, the chances decrease to 1 in 2,147,483,648. Kaminsky said it's not perfect, but it's a good enough start.

Click here for full coverage of Black Hat 2008.

[One Mark Bliss]

Actually, the chances decrease, since the one is divided by the increased number. Consider that the concept of chance being used in the article represents the random likelihood that someone will guess the secret code in one attempt.
It seems that a similar confusion exists in another concept nothing to do with chance, namely turning the air conditioning up, or down. Which makes the room colder? In that case it depends on whether the concept being referred to is the amount of the flow of cold air, in which case it would be up, or the numerical representation of temperature, in which case it would be down.
The only way a similar confusion can arise with chance is whether it is couched as the chance of guessing something randomly, or the chance of not guessing it. So, in the article, the chance would only increase if it were the chance of a hacker randomly NOT getting the secret code.

[Invisobel]

Ummmm Ok. Good to know.

[conobs]

instead of giging them on symantecs
WHERE IS THE MEAT?
how dos it work?

this would qualify more as a story about a story, not an actual news story
take it up a notch
thx
bob

[conobs]

i dont know maybe i am wrong and overly harsh

[frazmann]

@conobs - the crux of the hack are that you send a DNS request to a server, knowing that the server will send a request to it's DNS master server to obtain the translation, and then bombard the server with fake responses, hoping to guess the transaction id that it used when making the request. If you get it right before the master server's response arrives then you have planted a fake DNS entry in your server, and the real response is thrown away. If you do this from your comcast account then you can re-direct all your neighbors to a fake google.com that sits on your PC. Seems so simple I'm surprised no-one tried it before....

[benjaminstraight]

Good article.

[Seaspray0]

I will still add the following... Poisoning the DNS is only part of the battle. Almost everyone knows not to transmit any kind of information unless you are on a secure website. That requires a digital certificate from a trusted certificate authority. Malicious websites won't be able to simply "hack" a fake certificate. So, while it may be possible to poison the DNS, the malicious site won't be able to provide the SSL. This is atleast some good news.

[The_Decider]

There is really no such thing as a secure web site, mainly because 99.9999999% of the population wouldn't know how to know or why they should care. The fact that many https implementations are flawed is another important factor.

Especially on Windows, users are so used to just clicking yes, that they just keep clicking yes, not that they would no if the right answer is yes or no.

I can make a web application with a self-signed certificate and it will inherently be as secure as one with a "digital certificate from a trusted certificate authority".

Your almost anyone knows argument flies in the face of the fact that the majority of forms on web pages use no encryption at all. Even web sites with millions of users.

[ghostwalkers12]

The means Kaminsky sought to address is a little more involved. It is also not news to many very familiar with the IP suite of algorithms and DNS. The patches do not solve the problem. The patches are feel-good sauve. The only means to avoid this script kiddie attack is to not query over the client facing NIC. The entire hack hinges on knowing the NIC (associated IP) over which a DNS will recursively query. The hack involved using additional records in the response, which the patches seek to address. Randomization of port number and sequence number accomplishes nothing. One can flood via the internet a network segment to which a DNS is attached with all possible combinations. It is a little more advanced a purpose than the usual script kiddie DDoS attack. Faking certificates for servers is not particularly difficult considering the only thing one needs is a CA the target will accept as valid to validate the certificate. Most users are little more than "click-monkeys" at a keyboard.

[Fil0403]

I assume that this only affects Windows, because Mac and Linux are 100% perfect and secure, and, thus, have no security problems, right?

[Vurk]

Of course they are. And we know that the criminals who would try this can only use Windows boxes.