Exploit for DNS Cache Poisoning - RELEASED

Now, there is an exploit for it.

http://www.caughq.org/exploits/CAU-EX-2008-0002.txt

Maybe I'm missing it, but this looks like a fairly standard DNS exploit.

Keep asking questions and sending fake answers until one gets lucky.

It certainly matches closely with my memory of discussions of the
weaknesses in the DNS protocol from the '90's, with the primary difference
being that now networks and hardware may be fast enough to make the
flooding (significantly) more effective. I have to assume that one other
standard minor enhancement has been omitted (or at least not explicitly
mentioned), and will refrain from mentioning it for now.

So, I have to assume that I'm missing some unusual aspect to this attack.
I guess I'm getting older, and that's not too shocking. Anybody see it?

... JG

Actually you are not missing anything. It is a brute force attack. I think
you had the right concept when you indicated that "networks and hardware
may be fast enough". It is not maybe, it is; and every script kiddie on your
block has the power in his/her bedroom. Then you add the college crowd
sitting on 10Gig pipes to the Internet and the threat is real. But other
than just muck things up where is the motivation for a poisoning?

Robert D. Scott Robert@ufl.edu
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services 352-392-2061 CNS Receptionist
University of Florida 352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL 32611 321-663-0421 Cell

Joe Greco wrote:

So, I have to assume that I'm missing some unusual aspect to this attack.
I guess I'm getting older, and that's not too shocking. Anybody see it?

AFAIK, the main novelty is the ease with which bogus NS records can be inserted. It may be hard to get a specific A record (www.victimsbank.com) cached, but if you can shim in the NS records of your ns.poisoner.com authority, then getting the real target A record is trivial since you'll be asked directly for it (and can wait for the legit clients to ask for it for you).

Mike

Hi,

Actually you are not missing anything. It is a brute force attack.

I haven't looked at the exploit code, but the vulnerability Kaminsky found is a bit more than a brute force attack. As has been pointed out in various venues, it takes advantage of a couple of flaws in the DNS architecture. No, not simply the fact that the QID space is only 16 bits. That's part of it, but there is more. Really. I'm sure you can find the 'leaked' Matasano Chargen description of the attack on the net somewhere.

But other than just muck things up where is the motivation for a poisoning?

Man-in-the-middle attacks directed at ISPs serving end users who want to (say) get to their banks?

Regards,
-drc

What's new is the method of how it is being exploited.

Before, if you wanted to poison a cache for www.gmail.com, you get the victim name server to try to look up www.gmail.com and spoof flood the server trying to beat the real reply by guessing the correct ID. if you fail, you may need to wait for the victim name server to expire the cache before trying again.

The new way is slightly more sneaky. You get the victim to try to resolve an otherwise invalid and uncached hostname like 00001.gmail.com, and try to beat the real response with spoofed replies. Except this time your reply comes with an additional record containing the IP for www.gmail.com to the one you want to redirect it to. If you win the race and the victim accepts your spoof for 00001.gmail.com, it will also accept (and overwrite any cached value) for your additional record for www.gmail.com as well. If you don't win the race, you try again with 00002.gmail.com, and keep going until you finally win one. By making up uncached hostnames, you get as many tries as you want in winning the race. By tacking on an additional reply record to your response packet you can poison the cache for anything the victim believes your name server should be authoritative for.

This means DNS cache poisoning is possible even on very busy servers that normally you wouldn't be able to predict when it was going expire its cache, and if you fail the first time you can keep trying again and again until you succeed with no wait.

-- Kevin

Perhaps what you're missing can be found in the punchline to the transient post on the Matasano Security blog ("Mallory can conduct this attack in less than 10 seconds on fast Internet link").

Being able to divert users of a particular resolver (who thought they were going to paypal, or their bank, or a government web page to file their taxes, or, or, etc) to the place of your choosing with less than a minute's effort seems like cause for concern to me.

Luckily we have the SSL/CA architecture in place to protect any web page served over SSL. It's a good job users are not conditioned to click "OK" when told "the certificate for this site is invalid".

Joe

'course, as well as relying on users not ignoring certificate warnings,
SSL as protection against this attack relies on the user explicitly
choosing SSL (by manually prefixing the URL with https://), or noticing
that the site didn't redirect to SSL.

Your average Joe who types www.paypal.com into their browser may very
well not notice that they didn't get redirected to
https://www.paypal.com/

-Jasper

That did not even occur to me.

Anyone have a foolproof way to get grandma to always put "https://" in front of "www"?

Seriously, I was explaining the problem to someone saying "never click 'OK'" when this e-mail came in and I realized how silly I was being.

Help?

The problem is there is no perfect solution to these challenges
that the industry faces.

  The enhanced SSL certs and browser magic, eg:
www.paypal.com w/ Firefox3 gives a nice green "happy" bar.

  If you don't invest in these, or if there is a lack of user
education around these issues it's just one big Pharming pool.

  I talked to some govvies today and made what I believe is
the clear case when it comes to "Doing the right thing(tm)". My
case was that the industry would do the right thing as a whole.
There would be stragglers, but the risk of doing nothing is too
high.

  If your nameservers have not been upgraded or you did
not enable the proper flags, eg: dnssec-enable and/or dnssec-validation
as applicable, I hope you will take another look.

  - Jared

Patrick W. Gilmore wrote:

Anyone have a foolproof way to get grandma to always put "https://" in front of "www"?

Some tests from my home Comcast connection tonight showed less than desirable results from their resolvers.

The first thing I did was to double check that the bookmarks I use when visiting my banking sites all begin https. I was happy to see I had the sense to create them some time ago, by hand, with the https.

Even when I receive a notice of a new statement or pending payment on something in the email, and I KNOW it's valid, I'm still visiting it from the bookmark.

Bookmarks or favorites or whatever your browser of choice wishes to call them, for the https URLs. That, or remember to type in the https:// prefix.

- S

Skywing wrote:

Bookmarks or favorites or whatever your browser of choice wishes to call them, for the https URLs. That, or remember to type in the https:// prefix.

- S

Which works great until you run into something like Washington Mutual (of which you have no doubt heard)...

http://www.wamu.com redirects to
Chase Checking Accounts: Compare & Apply Today | Chase

and

https://www.wamu.com *also* redirects to
Credit Card, Mortgage, Banking, Auto | Chase Online | Chase.com (!)

And yes, then you're supposed to trust that the page you've been served up will send the form submit with your username and password to the right place over https.

They do now have a link to Credit Card, Mortgage, Banking, Auto | Chase Online | Chase.com on that main page, but you have to look for it. But really, https://www.wamu.com should redirect to *that* in order for it to be safe for the slightly-knowledgeable-about-http-security.

Matthew Kaufman
matthew@eeph.com

Patrick W. Gilmore wrote:

Anyone have a foolproof way to get grandma to always put "https://" in front of "www"?

I understand this is a huge can of worms, but maybe it's time to change the default behavior of browsers from http to https...?

I'm sure it's doable in FF with a simple plugin, one doesn't have to wait for FF4. (That would work for bookmarks too.)

Robert

Servers won't go along with it -- it's too expensive, both in CPU and
round trips.

The round trip issue affects latency, which in turn affects perceived
responsiveness. This is quite definitely the reason why gmail doesn't
always use https (though it, unlike some other web sites, doesn't
refuse to use it).

As for CPU time -- remember that most web site visits are very short;
this in turn means that you have to amortize the SSL setup expense over
very few pages. I talked once with a competent system designer who
really wanted to use https but couldn't -- his total system cost would
have gone up by a factor of 10.

    --Steve Bellovin, http://www.cs.columbia.edu/~smb

It probably wouldn't help. In this case, if I was the attacker, I'd just
find a company selling "Domain Validated" certs whose upstream
nameserver was vulnerable (there's enough "Domain Validated" certificate
pushers now that this shouldn't be hard)

Then you spoof the domain from their point of view, obtain a cert, and
now HTTPS will work with no error message, almost certainly fooling
anyone's grandma.

-Jasper

I don't think anything involving HTTPS is necessairly an answer to this
problem. Specifically:

* not all sites do HTTPS
* many organizations use transparent proxies like Microsoft ICA
* certification authorities can in theory be bought off (or otherwise
manipulated) to issue bogus certs, making switching to HTTPS worthless

William

Steven M. Bellovin wrote:

As for CPU time -- remember that most web site visits are very short;
this in turn means that you have to amortize the SSL setup expense over
very few pages. I talked once with a competent system designer who
really wanted to use https but couldn't -- his total system cost would
have gone up by a factor of 10.
  

We handle the SSL decryption on the front-end load-balancers (hardware assisted). For financial transactions the load-balancers also maintain long-lived SSL connections to the webservers, that the decrypted data is pipelined into. This avoids the expensive session setup and teardown on the servers.

Sam

RFC 2181 says the resolver should not overwrite authoritative data with
additional data in this manner.

I believe the Matasano description is wrong.

Tony.

Once upon a time, Robert Kisteleki <robert@ripe.net> said:

I understand this is a huge can of worms, but maybe it's time to change the
default behavior of browsers from http to https...?

This is a _DNS_ vulnerability. The Internet is more than HTTP(S).

Think about email (how many MTAs do TLS and validate the certs?). Even
things like BitTorrent require valid DNS (how about MPAA/RIAA poisoning
the cache for thepiratebay?).

Robert Kisteleki wrote:

Patrick W. Gilmore wrote:

Anyone have a foolproof way to get grandma to always put "https://" in front of "www"?

I understand this is a huge can of worms, but maybe it's time to change the default behavior of browsers from http to https...?

I'm sure it's doable in FF with a simple plugin, one doesn't have to wait for FF4. (That would work for bookmarks too.)

Robert

80 != 443
There's nobody listening on 443 for most of the Internet.
Ken