Re: Exploit for DNS Cache Poisoning - RELEASED

[Joe Greco]

> 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
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

RE: Exploit for DNS Cache Poisoning - RELEASED

[Robert D. Scott]

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 [EMAIL PROTECTED]
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



-Original Message-
From: Joe Greco [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 23, 2008 6:31 PM
To: Robert D. Scott
Cc: [EMAIL PROTECTED]
Subject: Re: 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
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then
I
won't contact you again." - Direct Marketing Ass'n position on e-mail
spam(CNN)
With 24 million small businesses in the US alone, that's way too many
apples.

Re: Exploit for DNS Cache Poisoning - RELEASED

[Mike Lewinski]

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

Re: Exploit for DNS Cache Poisoning - RELEASED

[David Conrad]

Hi,

On Jul 23, 2008, at 3:51 PM, Robert D. Scott wrote:

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

Re: Exploit for DNS Cache Poisoning - RELEASED

[Tuc at T-B-O-H.NET]

> 
> Now, there is an exploit for it.
> 
> http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
> 
For anyone looking to use it, you MUST update the frameworks
libraries. Some of the code only came out ~5 hours ago that
it needs.

Tuc/TBOH

Re: Exploit for DNS Cache Poisoning - RELEASED

[Kevin Day]

On Jul 23, 2008, at 5:30 PM, Joe Greco wrote:


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?




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

Re: Exploit for DNS Cache Poisoning - RELEASED

[Joe Abley]

On 23 Jul 2008, at 18:30, 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?


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

Re: Exploit for DNS Cache Poisoning - RELEASED

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -- Joe Abley <[EMAIL PROTECTED]> wrote:

>It's a good job users are not conditioned to click "OK" when
>told "the certificate for this site is invalid".

I appreciate your sense of humor. ;-)

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.6.3 (Build 3017)

wj8DBQFIh9n2q1pz9mNUZTMRAq5cAKCEx/4G+FJb6XSQyZu1IOvd9UBixgCfbZUk
nDISb0J+YuIJlLYkVIKkLBo=
=1Swd
-END PGP SIGNATURE-

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: Exploit for DNS Cache Poisoning - RELEASED

[Jasper Bryant-Greene]

On Wed, 2008-07-23 at 21:17 -0400, Joe Abley wrote:
> 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".

'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

Re: Exploit for DNS Cache Poisoning - RELEASED

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -- "Robert D. Scott" <[EMAIL PROTECTED]> wrote:

>Now, there is an exploit for it.
>
>http://www.caughq.org/exploits/CAU-EX-2008-0002.txt

Now also (mirrored) here:

 http://www.milw0rm.com/exploits/6122

...and probably a slew of other places, too. ;-)

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.6.3 (Build 3017)

wj8DBQFIh9qmq1pz9mNUZTMRAuXEAJ0cmn10Rz4Z0RG5LfseroFFvLbUmgCgipoV
rLDjjPCo+7w7+aV8udRK7fc=
=n1cC
-END PGP SIGNATURE-



--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: Exploit for DNS Cache Poisoning - RELEASED

[Joe Greco]

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

That's why that crummy technique isn't used.

> The new way is slightly more sneaky. You get the victim to try to  
> resolve an otherwise invalid and uncached hostname like  
> 1.gmail.com, and try to beat the real response with spoofed  
> replies.

That's the normal technique, as far as I was aware.

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

Thought that was the normal technique for cache poisoning.  I'm pretty 
sure that at some point, code was added to BIND to actually implement
this whole bailiwick system, rather than just accepting arbitrary out-
of-scope data, which it ... used to do (sigh, hi BIND4).

> If you win the race and the victim accepts your spoof for  
> 1.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 2.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.

Right.  To the best of my knowledge, that's neither a new nor a clever 
technique for generating additional DNS request transactions.

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

And that's one standard form of poisoning.

Cache poisoning and sending extra data is an interesting topic.  I have
to admit that my experience with it is somewhat dated, and a lot of it is
as much as a decade out of date, when I was writing miniature authoritative
name servers for application load balancing purposes.  I did in fact do
a number of experiments against various implementations to see what sins I
could get away with, and I have to say, the protocol is remarkable in that
so many broken-seeming things that I deliberately inflicted while playing
around can be worked out by server implementations.  But, then again, the
beauty of DNS is that it hasn't really changed much over time ...

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

This is disappointing, because Vixie specifically stated that this was a 
new attack, and I'm pretty sure he said it was one where the exploit could
not be determined merely by knowing the sort of change that was being made
to BIND.

Well, the change that was made to BIND was to randomize source ports,
which indicated it was a forged-response attack of some kind.

Knowing that there were further statements about the weakness of the PRNG
for the QID suggested that it was susceptible to a brute-force attack.

I guess there's a vague hint of novelty in it all if you want to be a tad
more clever about what you're corrupting.  I can think of a few examples,
which I will respectfully not discuss, just in case someone hasn't thought
of them, but basically it seems to me that this is neither a new nor a 
novel attack.

So I'm not super impressed.  Do I see the need for the patch?  Yes.  Do I
see the need to lie about the nature of the problem?  I guess, but this is
not any more of a problem today than it was a year (or ten!) ago, except 
maybe now someone is threatening to finally do something that might cause 
DNSSEC to get deployed, which seems like it would have been a better way
to scare people, IMHO.

I think a bunch of us saw the problem with spoofed DNS years ago, and I'm 
pretty sure a bunch of DNSSEC people have been predicting exactly this 
state of affairs for quite some time, and knowledge of the general problem 
predates even that.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Exploit for DNS Cache Poisoning - RELEASED

[Tuc at T-B-O-H.NET]

> - -- "Robert D. Scott" <[EMAIL PROTECTED]> wrote:
> 
> >Now, there is an exploit for it.
> >
> >http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
> 
> Now also (mirrored) here:
> 
>  http://www.milw0rm.com/exploits/6122
> 
> ...and probably a slew of other places, too. ;-)
> 
The changes the put into metasploit for this don't seem
to work if running from FreeBSD 5.5, possibly other BSD's and 
versions from talking to the author. 

Tuc/TBOH

Re: Exploit for DNS Cache Poisoning - RELEASED

[William Herrin]

On Wed, Jul 23, 2008 at 9:44 PM, Joe Greco <[EMAIL PROTECTED]> wrote:
>> 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.
>
> Thought that was the normal technique for cache poisoning.  I'm pretty
> sure that at some point, code was added to BIND to actually implement
> this whole bailiwick system, rather than just accepting arbitrary out-
> of-scope data, which it ... used to do (sigh, hi BIND4).

Joe,

I think that's the beauty of this attack: the data ISN'T out of scope.
The resolver is expecting to receive one or more answers to
1.gmail.com, one or more authority records (gmail.com NS
www.gmail.com) and additional records providing addresses for the
authority records (www.gmail.com A 127.0.0.1).

Regards,
Bill Herrin


-- 
William D. Herrin  [EMAIL PROTECTED] [EMAIL PROTECTED]
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Exploit for DNS Cache Poisoning - RELEASED

[Patrick W. Gilmore]

On Jul 23, 2008, at 9:27 PM, Jasper Bryant-Greene wrote:

On Wed, 2008-07-23 at 21:17 -0400, Joe Abley wrote:

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


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


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?

--
TTFN,
patrick

Re: Exploit for DNS Cache Poisoning - RELEASED

[Jared Mauch]

On Wed, Jul 23, 2008 at 11:01:11PM -0400, Patrick W. Gilmore wrote:
>> https://www.paypal.com/
>
> 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.

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

-- 
Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: Exploit for DNS Cache Poisoning - RELEASED

[Mike Lewinski]

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.

RE: Exploit for DNS Cache Poisoning - RELEASED

[Skywing]

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

-Original Message-
From: Patrick W. Gilmore [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 23, 2008 11:01 PM
To: [EMAIL PROTECTED]
Subject: Re: Exploit for DNS Cache Poisoning - RELEASED

On Jul 23, 2008, at 9:27 PM, Jasper Bryant-Greene wrote:
> On Wed, 2008-07-23 at 21:17 -0400, Joe Abley wrote:
>> 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".
>
> '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/

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?

--
TTFN,
patrick

Re: Exploit for DNS Cache Poisoning - RELEASED

[Matthew Kaufman]

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
http://www.wamu.com/personal/default.asp

and

https://www.wamu.com *also* redirects to
http://www.wamu.com/personal.default.asp (!)

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 
https://online.wamu.com/IdentityManagement/Logon.aspx 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
[EMAIL PROTECTED]
http://www.matthew.at

Re: Exploit for DNS Cache Poisoning - RELEASED

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -- Jared Mauch <[EMAIL PROTECTED]> wrote:

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

Let's hope some very large service providers get their act together
real soon now.

http://www.hackerfactor.com/blog/index.php?/archives/204-Poor-DNS.html

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.6.3 (Build 3017)

wj8DBQFIiAJiq1pz9mNUZTMRAiSqAJwL9t4ldzKMjHyA4KITrLz2dHvTFQCgkfuR
G4SnZhKReOYYBjdSSJamVQw=
=ac5p
-END PGP SIGNATURE-



--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: Exploit for DNS Cache Poisoning - RELEASED

[Sean Donelan]

On Thu, 24 Jul 2008, Paul Ferguson wrote:

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.


Let's hope some very large service providers get their act together
real soon now.


There is always a tension between discovery, changing, testing and 
finally deployment.


DNS vendors learned about the vulnerability on March 31 (or possibly 
earlier).  DNS vendors waited over 3 months to publically release their

patches, even though they knew their customers and users were vulnerable.

It probably took the vendors some time to change their code, test their 
changes, work on beta releases in various deployments because programmers 
are human and sometimes patches have bugs too. Then they announced their 
patches to the world, and the world (and ISPs, etc) has much less time

to regression test and verify the systems still work.  Vendors have
released bugging patches in the past. Patching a large ISP infrastructure 
under ordinary circumstances can be challanging.  If it takes software
vendors 90+ days to fix something, is it a surpise it may take a large ISP 
more than 14 days?


If they move to quickly and crash the resolvers because of a bug the 
human programmers may have not forseen in the ISPs DNS architecture, the 
Internet is effectively "down" for a large number of users.  Result: Bad 
press, angry customers, lawsuits, etc.


If they don't move quickly enough and the vulnerability is exploited by
a human bad guy, the Internet is effectively "corrupted" for a large
number of users.  Result: Bad press, angry customers, lawsuits, etc.

Damned if they do, damned if they don't.  Or in this case: Damned if
they are too fast, damned if they are too slow.

I don't think there really is a correct answer.  People are going
to say they suck no matter what.  Anyone who has ever been in the position
of scheduling security patches across a large ISP knows they aren't going
to get much thanks.

Although I didn't know the right answer, I did try to always patch 
production network first and the corporate network last; so if we didn't 
get everything finished before the exploit hit I could tell customers
we did try to put the customer first.  Although internal MIS folks 
would sometimes get mad at me for waiting to tell them.  Some people

think you should patch the corporate network first, and the production
network later.


So it brings up the ancient question about the schedule of vulnerability
announcements and whether some providers of some core infrastructure
should have an early start to patch their systems; because everyone
else will be depending on them functioning to obtain the patches when
the vulnerability is widely disclosed.  How do you decide how early,
who, what, how, ...

Or do not play favorites, and announce everything to everyone at
the exact same time; and its off to the races.

Or something in between.

Re: Exploit for DNS Cache Poisoning - RELEASED

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -- Sean Donelan <[EMAIL PROTECTED]> wrote:

>>
>> Let's hope some very large service providers get their act together
>> real soon now.
>
>There is always a tension between discovery, changing, testing and 
finally deployment.
>

Sure, I can empathize, to a certain extent. But this issue has
been known for 2+ weeks now.

Not sure I can be very empathic now, given the seriousness, and the
proper warning ISPs have been given.

$.02,

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.6.3 (Build 3017)

wj8DBQFIiBldq1pz9mNUZTMRAiLjAJ91jnOPW+nhuk0PA5qGjrwz0bH25ACgjOXS
IEJTnVU4BIZ8bMfU7dB4ZKY=
=sBS2
-END PGP SIGNATURE-


--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: Exploit for DNS Cache Poisoning - RELEASED

[Joe Greco]

> On Wed, Jul 23, 2008 at 9:44 PM, Joe Greco <[EMAIL PROTECTED]> wrote:
> >> 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.
> >
> > Thought that was the normal technique for cache poisoning.  I'm pretty
> > sure that at some point, code was added to BIND to actually implement
> > this whole bailiwick system, rather than just accepting arbitrary out-
> > of-scope data, which it ... used to do (sigh, hi BIND4).
> 
> Joe,
> 
> I think that's the beauty of this attack: the data ISN'T out of scope.
> The resolver is expecting to receive one or more answers to
> 1.gmail.com, one or more authority records (gmail.com NS
> www.gmail.com) and additional records providing addresses for the
> authority records (www.gmail.com A 127.0.0.1).

I think the response to that is best summarized as **YAWN**.

One of the basic tenets of attacking security is that it works best to
attack the things that you know a remote system will allow.  The 
bailiwick system is *OLD* tech at this point, but is pretty much
universally deployed (in whatever forms across various products), so 
it stands to reason that a successful attack is likely to involve 
either in-scope data, or a bug in the system.

The fact that this was known to be a cross-platform vulnerability
would have suggested an in-scope data attack.  I thought that part was
obvious, sorry for any confusion.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Exploit for DNS Cache Poisoning - RELEASED

[Tony Finch]

On Wed, 23 Jul 2008, Kevin Day wrote:
>
> The new way is slightly more sneaky. You get the victim to try to
> resolve an otherwise invalid and uncached hostname like 1.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 1.gmail.com, it will also
> accept (and overwrite any cached value) for your additional record for
> www.gmail.com as well.

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

I believe the Matasano description is wrong.

Tony.
-- 
f.anthony.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
FORTIES CROMARTY FORTH TYNE DOGGER: EAST OR SOUTHEAST 3 OR 4, INCREASING 5 OR
6 LATER. SLIGHT OR MODERATE. FOG PATCHES. GOOD, OCCASIONALLY VERY POOR.

Re: Exploit for DNS Cache Poisoning - RELEASED

[Jorge Amodio]

>
> Sure, I can empathize, to a certain extent. But this issue has
> been known for 2+ weeks now.
>

Well we knew about the DNS issues since long time ago (20+yrs perhaps?),
so the issue is not new, just the exploit is more easy to put together and
chances for it to succeed are much higher.

As I mentioned in another message, perhaps its time to get serious about
DNSSEC, where are we on this front ?

Cheers
Jorge

Re: Exploit for DNS Cache Poisoning - RELEASED

[Sean Donelan]

On Thu, 24 Jul 2008, Paul Ferguson wrote:

Let's hope some very large service providers get their act together
real soon now.


There is always a tension between discovery, changing, testing and

finally deployment.




Sure, I can empathize, to a certain extent. But this issue has
been known for 2+ weeks now.

Not sure I can be very empathic now, given the seriousness, and the
proper warning ISPs have been given.


Also recognize some of the simple testing tools get a bit confused
by some of the more complex DNS configurations used by the mega-ISP
DNS clusters; and generate false positives (and maybe even false
negative) results. You can see it happens when the testing tool
reports widely different number of queries checked.

Several of the ISPs with complex DNS clusters are patching and upgrading
them; however the current state of some of the patches wouldn't support
the query load those providers normally experience.  So they've been
working on alternative mitigation strategies.  However, its difficult
to now if the alternative strategies actually mitigate the actual threat
without knowing the actual threat.

And finally, there probably are some providers who haven't made plans to
change their DNS.  Unfortunately, the testing tools can't read minds 
(yet), so its difficult to know which ISPs are in this category.

Re: Exploit for DNS Cache Poisoning - RELEASED

[Steven M. Bellovin]

On Thu, 24 Jul 2008 09:10:13 -0500
"Jorge Amodio" <[EMAIL PROTECTED]> wrote:

> >
> > Sure, I can empathize, to a certain extent. But this issue has
> > been known for 2+ weeks now.
> >
> 
> Well we knew about the DNS issues since long time ago (20+yrs
> perhaps?), so the issue is not new, just the exploit is more easy to
> put together and chances for it to succeed are much higher.
> 
This is important.  Kaminsky took a known concept and did the hard
engineering work to make it feasible.  To slightly misuse a quote
that's more often applied to crypto, "amateurs worry about algorithms;
pros worry about economics".  The economics of the attack have now
changed.  (And we need to get DNSSEC deployed before they change even
further.)


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

Re: Exploit for DNS Cache Poisoning - RELEASED

[Jorge Amodio]

>
> ... economics of the attack have now
> changed.  (And we need to get DNSSEC deployed before they change even
> further.)
>
Amen.

Re: Exploit for DNS Cache Poisoning - RELEASED

[Paul Vixie]

[EMAIL PROTECTED] ("Jorge Amodio") writes:

> As I mentioned in another message, perhaps its time to get serious about
> DNSSEC, where are we on this front ?

still waiting for US-DoC to give ICANN permission to sign the root zone.
-- 
Paul Vixie

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Exploit for DNS Cache Poisoning - RELEASED

[Paul Vixie]

[EMAIL PROTECTED] ("Jorge Amodio") writes:

> As I mentioned in another message, perhaps its time to get serious about
> DNSSEC, where are we on this front ?

Still waiting for US-DoC to give ICANN/IANA permission to sign the root zone.
-- 
Paul Vixie

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Exploit for DNS Cache Poisoning - RELEASED

[Eric Brunner-Williams]

Neil Suryakant Patel is the nominee for AS for Communications and 
Information at DoC. If he's in the loop, even "advisory pending ...", 
and as a Cheney staffer (intially staff secretary, now as a domestic and 
economic policy adviser), that's possible, then adjust expectations 
accordingly.


Paul Vixie wrote:

[EMAIL PROTECTED] ("Jorge Amodio") writes:

  

As I mentioned in another message, perhaps its time to get serious about
DNSSEC, where are we on this front ?



Still waiting for US-DoC to give ICANN/IANA permission to sign the root zone.
  

RE: Exploit for DNS Cache Poisoning - RELEASED

[Tomas L. Byrnes]

The problem is, once the ICANNt root is self-signed, the hope of ever
revoking that dysfunctional mess as authority is gone.

Perhaps the IETF or DoC should sign the root, that way we have a prayer
of wresting control from ICANN, as opposed to paying a tax, in
perpetuity, for registration services to an unaccountable, unelected,
and imperious body?

Some of us don't think the UN/EU/ITU are good models for governance.

IE: Separation of powers. ICANN/IANA is granted (interim) authority to
operate, but some other governing body signs.



> -Original Message-
> From: Paul Vixie [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, July 24, 2008 9:13 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Exploit for DNS Cache Poisoning - RELEASED
> 
> [EMAIL PROTECTED] ("Jorge Amodio") writes:
> 
> > As I mentioned in another message, perhaps its time to get serious 
> > about DNSSEC, where are we on this front ?
> 
> Still waiting for US-DoC to give ICANN/IANA permission to 
> sign the root zone.
> --
> Paul Vixie
> 
> --
> This message has been scanned for viruses and dangerous 
> content by MailScanner, and is believed to be clean.
> 
> 
> 

Re: Exploit for DNS Cache Poisoning - RELEASED

[David Conrad]

On Jul 24, 2008, at 4:24 PM, Tomas L. Byrnes wrote:

The problem is, once the ICANNt root is self-signed, the hope of ever
revoking that dysfunctional mess as authority is gone.


Sorry, I don't follow -- sounds like FUD to me.  Care to explain this?

As far as I'm aware, as long as the KSK isn't compromised, changing  
the organization who holds the KSK simply means waiting until the next  
KSK rollover and have somebody else do the signing.



Perhaps the IETF


You mean oh say IANA?


or DoC


That'll be popular in the international community.


should sign the root, that way we have a prayer
of wresting control from ICANN, as opposed to paying a tax, in



perpetuity, for registration services to an unaccountable, unelected,
and imperious body?


Registration fees are unrelated to signing the root, but thanks for  
the gratuitous ICANN bashing.  It was missing in this thread -- I was  
wondering when it would show up.



Some of us don't think the UN/EU/ITU are good models for governance.


Indeed.


IE: Separation of powers. ICANN/IANA is granted (interim) authority to
operate, but some other governing body signs.



So you want to increase the role ICANN/IANA has in root zone  
management.  Interesting.


Regards,
-drc

Re: Exploit for DNS Cache Poisoning - RELEASED

[Valdis . Kletnieks]

On Thu, 24 Jul 2008 17:43:10 PDT, David Conrad said:
> On Jul 24, 2008, at 4:24 PM, Tomas L. Byrnes wrote:
>> The problem is, once the ICANNt root is self-signed, the hope of ever
>> revoking that dysfunctional mess as authority is gone.

> As far as I'm aware, as long as the KSK isn't compromised, changing  
> the organization who holds the KSK simply means waiting until the next  
> KSK rollover and have somebody else do the signing.

That's true if the ICANN KSK is signed *by some other entity* - that entity
can then force a change by signing some *other* KSK for the next rollover.

If the ICANN key is self-signed as Tomas hypothesizes, then that leverage
evaporates.
If  


pgpWohl3t8DWO.pgp
Description: PGP signature

Re: Exploit for DNS Cache Poisoning - RELEASED

[Paul Vixie]

"Tomas L. Byrnes" <[EMAIL PROTECTED]> wrote:
> The problem is, once the ICANNt root is self-signed, the hope of ever
> revoking that dysfunctional mess as authority is gone.

that sounds like the kind of foot-dragging that could be holding this up.

> Perhaps the IETF or DoC should sign the root, that way we have a prayer
> of wresting control from ICANN, as opposed to paying a tax, in
> perpetuity, for registration services to an unaccountable, unelected,
> and imperious body?

apparently when the internet was invented nobody gave any thought to all
kinds of stuff including classful addressing (how were we going to route
16 million class C's anyway?), settlements (aren't AS701 and LVLT also
somewhat imperious?), unwanted traffic (spam, DoS), address space longevity
and/or conservation, routing table bloat and churn, traffic source
authenticity (UDP, SMTP, syslog, ICMP, you name it)... and now you're
trying to say that we don't know how to govern it long-term either?

> Some of us don't think the UN/EU/ITU are good models for governance.

probably most of us.  however, there are certain things that can only get
done that way (country code assignments in postal and telephony space for
example) and i try to keep this in mind and continually forgive those who
mistakenly believe that IP addresses or domain names are like that at all.

> IE: Separation of powers. ICANN/IANA is granted (interim) authority to
> operate, but some other governing body signs.

the other party would have to sign every change.  probably that's what will
happen, IANA will edit, USG will hire some beltway bandit to hold the keys
and do the signing, and then the rootops will publish.  and i'm ok with
that except that it's taking too long to get it going, and i can't seem to
find the person whose desk it's sitting on so that i can offer them my help.
(noting that they may not need or want my help, but i'd rather offer my
help than just sit back and complain.)

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Exploit for DNS Cache Poisoning - RELEASED

[Ganbold Tsagaankhuu]

On Thu, Jul 24, 2008 at 10:32 AM, Tuc at T-B-O-H.NET <[EMAIL PROTECTED]> wrote:

> > - -- "Robert D. Scott" <[EMAIL PROTECTED]> wrote:
> >
> > >Now, there is an exploit for it.
> > >
> > >http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
> >
> > Now also (mirrored) here:
> >
> >  http://www.milw0rm.com/exploits/6122
> >
> > ...and probably a slew of other places, too. ;-)
> >
> The changes the put into metasploit for this don't seem
> to work if running from FreeBSD 5.5, possibly other BSD's and
> versions from talking to the author.
>
>Tuc/TBOH
>
>
True. On FreeBSD 7.0-STABLE (updated on Fri May 23) it fails to create raw
socket:
...
[-] This module is configured to use a raw IP socket. On Unix systems, only
the root user is allowed to create raw sockets.Please run the framework as
root to use this module.

[*] Attempting to inject poison records for example.com.'s nameservers into
202.72.241.4:55088...
[-] Auxiliary failed: undefined method `sendto' for nil:NilClass

Re: Exploit for DNS Cache Poisoning - RELEASED

[Tuc at T-B-O-H.NET]

> 
> On Thu, Jul 24, 2008 at 10:32 AM, Tuc at T-B-O-H.NET <[EMAIL PROTECTED]> 
> wrote:
> 
> > > - -- "Robert D. Scott" <[EMAIL PROTECTED]> wrote:
> > >
> > > >Now, there is an exploit for it.
> > > >
> > > >http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
> > >
> > > Now also (mirrored) here:
> > >
> > >  http://www.milw0rm.com/exploits/6122
> > >
> > > ...and probably a slew of other places, too. ;-)
> > >
> > The changes the put into metasploit for this don't seem
> > to work if running from FreeBSD 5.5, possibly other BSD's and
> > versions from talking to the author.
> >
> >Tuc/TBOH
> >
> >
> True. On FreeBSD 7.0-STABLE (updated on Fri May 23) it fails to create raw
> socket:
> ...
> [-] This module is configured to use a raw IP socket. On Unix systems, only
> the root user is allowed to create raw sockets.Please run the framework as
> root to use this module.
> 
> [*] Attempting to inject poison records for example.com.'s nameservers into
> 202.72.241.4:55088...
> [-] Auxiliary failed: undefined method `sendto' for nil:NilClass
> 
Sorry, I just checked it on 7.0 earlier today.

If you happen to know any FreeBSD Ruby programmers with heavy socket
experience, it would really be helpful. :-D 

I haven't tried the Python one yet. Probably later today.

Tuc/TBOH

Re: Exploit for DNS Cache Poisoning - RELEASED

[David Conrad]

Valdis,

On Jul 24, 2008, at 6:05 PM, [EMAIL PROTECTED] wrote:

On Thu, 24 Jul 2008 17:43:10 PDT, David Conrad said:

On Jul 24, 2008, at 4:24 PM, Tomas L. Byrnes wrote:
The problem is, once the ICANNt root is self-signed, the hope of  
ever

revoking that dysfunctional mess as authority is gone.



As far as I'm aware, as long as the KSK isn't compromised, changing
the organization who holds the KSK simply means waiting until the  
next

KSK rollover and have somebody else do the signing.


That's true if the ICANN KSK is signed *by some other entity* - that  
entity
can then force a change by signing some *other* KSK for the next  
rollover.


If the ICANN key is self-signed as Tomas hypothesizes, then that  
leverage

evaporates.


Except it doesn't work like that.  As has been presented in numerous  
places (RIPE, ICANN, etc.), Richard Lamb has been working with the  
usual suspects (the Swedish DNSSEC mafia, NLNetLabs folks, Nominet  
folks, etc.) to come up with a secure, trustable, and accountable  
architecture for doing the signing.  If a miracle happens and IANA  
were to be allowed to sign the root and then was told to give it to  
someone else, all that would need to be done would be for IANA staff  
to hand over the HSM, PIN codes and cards to someone else.  Of course,  
part of the architecture is that there is more than one card and that  
someone other than IANA would hold the second card (i.e., the same  
sort of thing you see in US missle silos), but that's somewhat  
irrelevant to a discussion about how the "dysfunctional mess" would  
have its "authority" revoked.


I suppose one could argue that ICANN could refuse to hand over the  
HSM, the PIN codes and cards, but given ICANN is a California- 
incorporated company providing the IANA functions under a contract  
with the US government, I somehow doubt ICANN would be in any position  
to refuse.  Federal Marshals can be quite persuasive I'm told.


Of course, all of this is academic since since I figure it is highly  
unlikely IANA will be permitted to sign the root.  If anyone, my money  
is on VeriSign (you remember them...) but it may be some other Beltway  
Bandit as Paul suggests.


Regards,
-drc
 

Re: Exploit for DNS Cache Poisoning - RELEASED

[Alexander Harrowell]

In what way is the EU's governance model the same as, or anything similar,
to the UN's or ITU's? This argument gets increasingly silly. Hell, when did
ITU last let someone randomly take over a chunk of the e164 name space?

On Fri, Jul 25, 2008 at 4:06 PM, David Conrad <[EMAIL PROTECTED]> wrote:

> Valdis,
>
>
> On Jul 24, 2008, at 6:05 PM, [EMAIL PROTECTED] wrote:
>
>> On Thu, 24 Jul 2008 17:43:10 PDT, David Conrad said:
>>
>>> On Jul 24, 2008, at 4:24 PM, Tomas L. Byrnes wrote:
>>>
 The problem is, once the ICANNt root is self-signed, the hope of ever
 revoking that dysfunctional mess as authority is gone.

>>>

Re: Exploit for DNS Cache Poisoning - RELEASED

[Paul Vixie]

in 
we see this text:

The DNS attacks are starting!!!

Below is a snippet of a logwatch from last night.  Be sure all DNS
servers are updated if at all possible.  The spooks are out in full
on this security vulnerability in force.

THIS IS YOUR LAST WARNING...!!!
Patch or Upgrade NOW!

...

this ought to be an interesting weekend.
-- 
Paul Vixie

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Exploit for DNS Cache Poisoning - RELEASED

[Pete Carah]

Paul Vixie wrote:

in 
we see this text:

The DNS attacks are starting!!!

Below is a snippet of a logwatch from last night.  Be sure all DNS
servers are updated if at all possible.  The spooks are out in full
on this security vulnerability in force.

THIS IS YOUR LAST WARNING...!!!
Patch or Upgrade NOW!

...

this ought to be an interesting weekend.


I saw much more than this *from the same address* starting two days ago, 
and from several other blocks belonging to the same university starting 
last week, to my home router and another server.  So far my better 
connected servers haven't been hit hard. (and no non-auto answer from 
"security" at that university...)


-- Pete

Re: Exploit for DNS Cache Poisoning - RELEASED

[Graeme Fowler]

On Fri, 2008-07-25 at 18:14 -0400, Pete Carah wrote:
> I saw much more than this *from the same address* starting two days ago, 
> and from several other blocks belonging to the same university starting 
> last week, to my home router and another server.  So far my better 
> connected servers haven't been hit hard. (and no non-auto answer from 
> "security" at that university...)

I saw this earlier in the week, along with queries for a domain name
which happens to have been registered by Dan Kaminsky, so I emailed him
about it. The addresses in question at Georgia Tech appear to be in use
as part of Doxpara's scan for unpatched systems, which he confirmed.

For those who are bothered, look out for queries from the same netblock
of the form:

rB6CIo_XgRlScY5K0iGISAAvygwAACujBAA=.ports.dns-integrity-scan.com/A/IN

It's probably obvious to one and all what they should be for. And the
fact that the queries are denied by correctly configured (ie. non-open)
resolvers makes it even less of a panic.

The sky isn't falling... yet.

Graeme

Re: Exploit for DNS Cache Poisoning - RELEASED

[Graeme Fowler]

On Fri, 2008-07-25 at 23:25 +0100, Graeme Fowler wrote:
> I saw this earlier in the week, along with queries for a domain name
> which happens to have been registered by Dan Kaminsky, so I emailed him
> about it. The addresses in question at Georgia Tech appear to be in use
> as part of Doxpara's scan for unpatched systems, which he confirmed.

And for extra points, can anyone with access to the raw un-logwatched
log entries tell us what's rather odd about the queries, given the
current furore over... well, that'd give the answer ;-)

Graeme

RE: Exploit for DNS Cache Poisoning - RELEASED

[Tomas L. Byrnes]

Lack of accountability, heavily bureacratic, and dirigiste.
 
Oh, and generally irrelevant/impotent in the real world of the
streets/net and crime/insurgency/dictatorship.


> -Original Message-
> From: Alexander Harrowell [mailto:[EMAIL PROTECTED] 
> Sent: Friday, July 25, 2008 10:54 AM
> To: David Conrad
> Cc: [EMAIL PROTECTED]
> Subject: Re: Exploit for DNS Cache Poisoning - RELEASED
> 
> In what way is the EU's governance model the same as, or 
> anything similar, to the UN's or ITU's? This argument gets 
> increasingly silly. Hell, when did ITU last let someone 
> randomly take over a chunk of the e164 name space?
> 
> On Fri, Jul 25, 2008 at 4:06 PM, David Conrad 
> <[EMAIL PROTECTED]> wrote:
> 
> > Valdis,
> >
> >
> > On Jul 24, 2008, at 6:05 PM, [EMAIL PROTECTED] wrote:
> >
> >> On Thu, 24 Jul 2008 17:43:10 PDT, David Conrad said:
> >>
> >>> On Jul 24, 2008, at 4:24 PM, Tomas L. Byrnes wrote:
> >>>
> >>>> The problem is, once the ICANNt root is self-signed, the hope of 
> >>>> ever revoking that dysfunctional mess as authority is gone.
> >>>>
> >>>
> 

Re: Exploit for DNS Cache Poisoning - RELEASED

[Florian Weimer]

* Paul Vixie:

> in 
> we see this text:
>
>   The DNS attacks are starting!!!
>
>   Below is a snippet of a logwatch from last night.  Be sure all DNS
>   servers are updated if at all possible.  The spooks are out in full
>   on this security vulnerability in force.
>
>   THIS IS YOUR LAST WARNING...!!!
>   Patch or Upgrade NOW!
>
>   ...
>
> this ought to be an interesting weekend.

It's from a Georgia Tech address, so it's likely some sort of monitoring
effort by David Dagon.  I see it in my logs, too.

https (was: Re: Exploit for DNS Cache Poisoning - RELEASED)

[Robert Kisteleki]

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

Re: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED)

[Steven M. Bellovin]

On Thu, 24 Jul 2008 09:51:40 +0200
Robert Kisteleki <[EMAIL PROTECTED]> 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.)
> 
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

Re: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED)

[Jasper Bryant-Greene]

On Thu, 2008-07-24 at 09:51 +0200, 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.)

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

Re: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED)

[William Pitcock]

On Thu, 2008-07-24 at 09:51 +0200, 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.)
> 

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

Re: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED)

[Chris Adams]

Once upon a time, Robert Kisteleki <[EMAIL PROTECTED]> 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?).

-- 
Chris Adams <[EMAIL PROTECTED]>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED)

[Jeffrey Ollie]

On Thu, Jul 24, 2008 at 3:05 AM, Steven M. Bellovin <[EMAIL PROTECTED]> wrote:
>
> 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).

Interestingly enough, Google just added a feature to GMail to force
secure connections:

http://googlesystem.blogspot.com/2008/07/force-gmail-to-use-secure-connection.html

Jeff

Re: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED)

[Hank Nussbacher]

On Thu, 24 Jul 2008, Jeffrey Ollie wrote:


Interestingly enough, Google just added a feature to GMail to force
secure connections:

http://googlesystem.blogspot.com/2008/07/force-gmail-to-use-secure-connection.html

Jeff


I wish Yahoo and Hotmail even had the ability of *reading* email via 
https:

http://www.interall.co.il/hotmail-yahoo-https.html

And then MS doesn't quite understand why people prefer Gmail to Hotmail 
:-)


-Hank

Re: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED)

[Jim Popovitch]

On Thu, Jul 24, 2008 at 11:24 PM, Hank Nussbacher <[EMAIL PROTECTED]> wrote:
> I wish Yahoo and Hotmail even had the ability of *reading* email via https:
> http://www.interall.co.il/hotmail-yahoo-https.html

Hah!  It was only a year ago that Yahoo even added SSL capabilities
for login.  Six months ago they added POP3S.

-Jim P.

Re: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED)

[Matthew Petach]

On 7/24/08, Hank Nussbacher <[EMAIL PROTECTED]> wrote:
> On Thu, 24 Jul 2008, Jeffrey Ollie wrote:
>
> > Interestingly enough, Google just added a feature to GMail to force
> > secure connections:
> >
> http://googlesystem.blogspot.com/2008/07/force-gmail-to-use-secure-connection.html
> >
> > Jeff
> >
>
>  I wish Yahoo and Hotmail even had the ability of *reading* email via https:
>  http://www.interall.co.il/hotmail-yahoo-https.html

I'm sure when Gmail gets close to the same number of users
as Yahoo, they will discover how challenging and painful it is
to support that many simultaneous short-lived SSL connections.
It's much easier to support CPU intensive tasks like full-time
SSL when you have a small user base; as that user base
grows, the cost of providing that service continues to grow,
often outpacing the revenue benefit it brings.

I *definitely* agree that any paid-for mail service should
support full-time SSL connectivity for reading as well
as login.

For a free service, though, it's hard to afford the CPU
resources to handle it as the demand scales up.

>  And then MS doesn't quite understand why people prefer Gmail to Hotmail :-)
>
>  -Hank

The good news is that the more users switch to gmail from
hotmail, the less load there is on the server CPUs at hotmail,
and the sooner they'll be able to afford to enable full-time
SSL for the remaining users.  :D  So clearly, the goal is to
encourage everyone *else* to go use gmail, leaving you to
enjoy the very lightly-loaded and highly-responsive platform
left behind.  ;)

Matt

Re: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED)

[Jim Popovitch]

On Fri, Jul 25, 2008 at 5:52 PM, Matthew Petach <[EMAIL PROTECTED]> wrote:
> I'm sure when Gmail gets close to the same number of users
> as Yahoo, they will discover how challenging and painful it is
> to support that many simultaneous short-lived SSL connections.

True, however GMail has the advantage of seeing Yahoo!'s past problems
and working (in advance) around them.   SSL is a good thing, and
thankfully Yahoo! came into the 21st century.  ;-)   Before I switched
to GMail I use to VPN my laptop connections to Yahoo!  POP3 via a
server closer to Yahoo! to avoid sniffing opptys.

-Jim P.

TLD servers with recursion was Re: Exploit for DNS Cache Poisoning - RELEASED

[Simon Waters]

On Thursday 24 July 2008 05:17:59 Paul Ferguson wrote:
>
> Let's hope some very large service providers get their act together
> real soon now.
>
> http://www.hackerfactor.com/blog/index.php?/archives/204-Poor-DNS.html

It isn't going to happen without BIG political pressure, either from users, or 
governments, and other bodies.

I checked last night, and noticed TLD servers for .VA and .MUSEUM are still 
offering recursion amongst a load of less popular top level domains.

Indeed just under 10% of the authoritative name servers mentioned in the root 
zone file still offer recursion.

I didn't check IPv6 servers, but these IPv4 servers are potentially vulnerable 
to this (and other) poisoning attacks. Hard to pin down numbers as some have 
been patched, and some have unusual behaviour on recursion, but I fancy my 
chances of owning more than a handful of TLDs if I had the time to try (and 
immunity from prosecution).

The advice NOT to allow recursion on TLD servers is well over a decade old. So 
who thinks the current fashionable problem will be patched widely in a 
month - given it is much less critical in nature?

The .MUSEUM server that is offering recursion is hosted by the Getty 
Foundation, so I assume money isn't the issue. The Vatican ought to be able 
to find someone in its billion adherents prepared to help configure a couple 
of name servers.

I also noticed that one of the ".US" servers doesn't exist in the DNS proper, 
glue exists but not the record in the zone. I'm guessing absence of a name 
servers name record in its proper zone makes certain spoofing attacks easier 
(since you are only competing with glue records), although I can't 
specifically demonstrate that one for blackhat 2008 - it suggests a certain 
lack of attention on the part of the domain's administrators.

I was tempted to write a mock RFC, proposing dropping all top level domain 
names which still have recursion enabled in one or more of their name 
servers - due to "lack of maintanence". A little humour might help make the 
point, slashdot might go for it.

Re: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning - RELEASED

[John Kristoff]

On Thu, 24 Jul 2008 10:06:25 +0100
Simon Waters <[EMAIL PROTECTED]> wrote:

> I checked last night, and noticed TLD servers for .VA and .MUSEUM are
> still offering recursion amongst a load of less popular top level
> domains.
> 
> Indeed just under 10% of the authoritative name servers mentioned in
> the root zone file still offer recursion.

While not ideal, at least most resolvers will not go asking those
servers for anything other than what they are authoritative for unless
an attacker for some reason wanted to setup a long chain of poisons. The
large, shared caching servers and all those open CPE devices are a
much larger concern I think.

John

Re: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning - RELEASED

[Gadi Evron]

On Thu, 24 Jul 2008, John Kristoff wrote:

On Thu, 24 Jul 2008 10:06:25 +0100
Simon Waters <[EMAIL PROTECTED]> wrote:


I checked last night, and noticed TLD servers for .VA and .MUSEUM are
still offering recursion amongst a load of less popular top level
domains.

Indeed just under 10% of the authoritative name servers mentioned in
the root zone file still offer recursion.


While not ideal, at least most resolvers will not go asking those
servers for anything other than what they are authoritative for unless
an attacker for some reason wanted to setup a long chain of poisons. The
large, shared caching servers and all those open CPE devices are a
much larger concern I think.


Indeed--you won't hear arguments from me on other threats, especially not 
CPE devices which I fought to bring recognition to.


But sticking to the point, TLD servers should (under most circumstances) 
be recursive. Thing is, those that are, are likely to stay that way.


I personally know several folks from within and wayyy from outside the DNS 
world who discovered this very out there and obvious issue and worked hard 
to try and contact the operators. Those that haven't fixed it yet, likely 
won't if all thing remain even.


Others I am not aware of likely did the same, withs imilar results. I 
guess we could try again.


Gadi.

Re: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning - RELEASED

[Gadi Evron]

On Thu, 24 Jul 2008, Gadi Evron wrote:

But sticking to the point, TLD servers should (under most circumstances) be


Should NEVER, oops.

RE: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning- RELEASED

[Martin Hannigan]

> 
> I personally know several folks from within and wayyy from outside the
> DNS
> world who discovered this very out there and obvious issue and worked
> hard
> to try and contact the operators. Those that haven't fixed it yet,
> likely
> won't if all thing remain even.
> 


I don't know that a failure to act immediately is indicative of ignoring
the problem. Not to defend AT&T or any other provider, but it's not as
simple as rolling out a patch. 


-M<

RE: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning- RELEASED

[Gadi Evron]

On Thu, 24 Jul 2008, Martin Hannigan wrote:





I personally know several folks from within and wayyy from outside the
DNS
world who discovered this very out there and obvious issue and worked
hard
to try and contact the operators. Those that haven't fixed it yet,
likely
won't if all thing remain even.




I don't know that a failure to act immediately is indicative of ignoring
the problem. Not to defend AT&T or any other provider, but it's not as
simple as rolling out a patch.


Marty, are we talking of the same problem? I am talking about recursion 
enabled in bind?





-M<

Re: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning- RELEASED

[Steven M. Bellovin]

On Thu, 24 Jul 2008 15:50:15 -
"Martin Hannigan" <[EMAIL PROTECTED]> wrote:

> 
> I don't know that a failure to act immediately is indicative of
> ignoring the problem. Not to defend AT&T or any other provider, but
> it's not as simple as rolling out a patch. 
> 
Right.  What scares me is all of the semi-managed hotspots with
software that's rarely updated.

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

Re: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning- RELEASED

[Gadi Evron]

On Thu, 24 Jul 2008, Steve Bertrand wrote:

Gadi Evron wrote:

On Thu, 24 Jul 2008, Martin Hannigan wrote:



I personally know several folks from within and wayyy from outside the
DNS
world who discovered this very out there and obvious issue and worked
hard
to try and contact the operators. Those that haven't fixed it yet,
likely
won't if all thing remain even.



I don't know that a failure to act immediately is indicative of ignoring
the problem. Not to defend AT&T or any other provider, but it's not as
simple as rolling out a patch.


Marty, are we talking of the same problem? I am talking about recursion 
enabled in bind?


I'm confused by the last sentence. I don't understand if you are asking a 
question, or stating that recursion should be disabled.


If it is a statement, then you must mean that ops should disable recursion, 
and enable forwarding for name resolution, correct? In this case, its been 
proven that having an upstream forward that is 'broken' will have the exact 
same effect as having a broken recursive server.


My apologies if I've misunderstood your comment.


We are talking about ccTLD NS.

Gadi.

Re: TLD servers with recursion was Re: Exploit for DNS Cache Poisoning- RELEASED

[Steve Bertrand]

Gadi Evron wrote:

On Thu, 24 Jul 2008, Martin Hannigan wrote:



I personally know several folks from within and wayyy from outside the
DNS
world who discovered this very out there and obvious issue and worked
hard
to try and contact the operators. Those that haven't fixed it yet,
likely
won't if all thing remain even.



I don't know that a failure to act immediately is indicative of ignoring
the problem. Not to defend AT&T or any other provider, but it's not as
simple as rolling out a patch.


Marty, are we talking of the same problem? I am talking about recursion 
enabled in bind?


I'm confused by the last sentence. I don't understand if you are asking 
a question, or stating that recursion should be disabled.


If it is a statement, then you must mean that ops should disable 
recursion, and enable forwarding for name resolution, correct? In this 
case, its been proven that having an upstream forward that is 'broken' 
will have the exact same effect as having a broken recursive server.


My apologies if I've misunderstood your comment.

Steve