Subject: DNS Blackhole attack

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 5 Mar 2005 06:13:04 -0800

[ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. Please fix your 
   subscription addresses. ]

This just appeared on the SANS list. Time to stop arguing and get DNSSEC
deployed.

Global DNS cache poisoning attack?; Update...

We are currently investigating a report from several sites that indicate
users being re-directed to malware sites. At this time it appears to be a
DNS cache poisoning attack (not a spyware, adware, or browser hijack) and we
are seeking more information.

Popular domain names such as google.com, ebay.com, and weather.com are being
directed to the following servers. Of course when connecting to these
servers, "bad things" (tm) will happen, so don't go to them.

www.7sir7.com (217.160.169.87) 
123xxl.com (217.160.169.87, 207.44.240.79, 216.127.88.131) 
abx4.com (217.160.169.87, 207.44.240.79, 216.127.88.131) 

If your site has been affected, please submit the following information:
1. When the attack was first noticed and whether it is still occurring.
2. What DNS server software you having facing the Internet. This information
will be kept in strictest confidence.
3. If you identified any other sites that users were being re-directed to
(besides the ones listed above).

Updates will be made to this diary as we find out more information.

Update at 23:40 UTC

There appear to be two issues at hand. The first is the DNS cache poisoning.
At this time, it appears to be affecting Symantec firewalls with DNS
caching. If you recall, there was a vulnerability back in July that made
these products very succeptable to DNS cache poisoning. Some victims have
responded that they applied the patch, but were still affected. So this
could be a different vulnerability or the patch didn't work properly. Maybe
someone at Symantec could enlighten us?

http://securityresponse.symantec.com/avcenter/security/Content/2004.06.21.ht
ml 

The second issue is the ABX toolbar spyware that gets loaded onto the
machine when visiting the target servers. This appears to happen using an
ActiveX control. Users running Windows XP SP2 or a web browser that does not
support ActiveX will probably not get hit with the spyware if they visit the
server.

Unfortunately, information on the ABX toolbar spyware is very limited at
this time and it doesn't seem to be detected yet by the normal toolset of
spyware/antivirus tools.

In the meantime, we have been working to get the IP addresses and DNS
servers supporting this attack shutdown. Some of the IP addresses are
already blackholed.

[eof]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Dean Anderson <[email-masked]>
Date: Sun, 6 Mar 2005 00:03:20 -0500 (EST)

> This just appeared on the SANS list. Time to stop arguing and get DNSSEC

I've not been testing DNSSEC, but I understand it requires TCP. So, DNSSEC
cannot be deployed on root servers, due to large number of root servers
using anycast, and anycast conflict with the DNSSEC's TCP requirements.
(Anycast only works on UDP single packet per transaction protocols. ISC
mistakenly told root operators that anycast can be deployed with TCP.) So,
DNSSEC probably won't be very effective at preventing cache poisoning
attacks.

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Frederico A C Neves <[email-masked]>
Date: Sun, 6 Mar 2005 02:21:55 -0300

On Sun, Mar 06, 2005 at 12:03:20AM -0500, Dean Anderson wrote:
> I've not been testing DNSSEC, but I understand it requires TCP.

No it doesn't. 

Please read 2671 and the 3 drafts
draft-ietf-dnsext-dnssec-[intro|protocol|records] on RFC Ed Queue.

... (removed conclusions based on wrong assumption).

---

From: David Conrad <[email-masked]>
Date: Sat, 5 Mar 2005 21:28:31 -0800

Hi,

You don't need TCP for DNSSEC (see EDNS0).

There is already discussion about deploying DNSSEC on the roots (in 
fact, there has been for quite a while -- the root ops are very 
conservative in deploying new stuff (as they should be)).

TCP can be used for anycast, but that's not relevant for this WG.  I'll 
let folks from ISC speak for themselves about what they may or may not 
have told the root operators.

Rgds,
-drc

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 06 Mar 2005 14:22:41 +0900

> using anycast, and anycast conflict with the DNSSEC's TCP requirements.

That is not a valid reason to avoid DNSSEC. Anycast does work with
short-lived TCP.

However, the security problem, here, is not inherent to DNS but
is caused by poor implementation of it, which is why we MUST
avoid DNSSEC which is a lot more complex than DNS and is
assured to make its implementations poor and insecure.

						Masataka Ohta

---

From: Florian Weimer <[email-masked]>
Date: Sun, 06 Mar 2005 12:01:59 +0100

> This just appeared on the SANS list. Time to stop arguing and get DNSSEC

There are at least four types of cache poisoning attacks:

  (1) Attacks which blindly spoof name server replies.  Because of the
      16 bit message ID, these attacks are always practical
      (especially if a constant query source port is used), even if
      implementations use hard-to-guess IDs.

  (2) Attacks which exploit weaknesses in resolver implementations
      which fail to discard bogus data received from authoritative
      name servers they have queried.

  (3) Attacks which exploit DNS configuration management systems which
      do not correctly filter some records.

  (4) Some ISPs have broken DNS management procedures which set up
      delegations for customers even though they do not receive a
      delegation from a parent zone for it.

From what I've heard, the current round of attacks is indeed in
category (2).  DNSSEC does not prevent this (and it doesn't help
against (3) and (4), either).  One could even argue that DNSSEC's
complexity will result in further vulnerabilities in the
interpretation of the meaning of DNS responses.

---

From: [email-masked]
Date: Sun, 6 Mar 2005 14:32:20 +0000

> I've not been testing DNSSEC, but I understand it requires TCP. So, DNSSEC

	you might want to try it out to be sure of your understandings.

> mistakenly told root operators that anycast can be deployed with TCP.) So,

	they did?  guess not everyone received the msg.

> DNSSEC probably won't be very effective at preventing cache poisoning

	prevent... perhaps not.  but it could, if used properly.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 07 Mar 2005 01:05:15 +0900

>       name servers they have queried.

Actually, attacks can exploit weaknesses in resolver implementations
which fail to distinguish and to separately cache unauthoritative
(delegation) data received from authoritative name servers they
have queried.

DNSSEC can't be helpful, unless parent zones sign glues, which
causes serious management troubles.

						Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Sun, 06 Mar 2005 16:28:37 +0000

> >   which fail to discard bogus data received from authoritative name
> >   servers they have queried.
> 
> (delegation) data received from authoritative name servers they have
> queried.

both of those statements are true.

> causes serious management troubles.

this statement, however, is not.

---

From: Ralph Droms <[email-masked]>
Date: Sun, 06 Mar 2005 13:42:44 -0500

Paul - which part (or all) of "DNSSEC can't be helpful, unless parent zones
sign glues, which causes serious management troubles." isn't true?

- Ralph

---

From: Pekka Savola <[email-masked]>
Date: Sun, 6 Mar 2005 20:58:42 +0200 (EET)

> both of those statements are true.

maybe this calls for working on specifying more clearly what resolvers 
(and other DNS components) must and must not do?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Paul Vixie <[email-masked]>
Date: Sun, 06 Mar 2005 19:26:06 +0000

> Paul - which part (or all) of "DNSSEC can't be helpful, unless parent
> zones sign glues, which causes serious management troubles." isn't
> true?
> 
> - Ralph

all of it.  in security, all you have to show for each attack is either
that you handle it, or you don't handle it, or it reduces to some other
attack which you either do or don't handle.

the case where the glue is MIM'd reduces to the case where your packets
are destroyed by loss or congestion, which is something dnssec already
doesn't handle (and that i can't think of a way to handle).

there's huge FUD about dnssec.  i'm disappointed in ohta-san and in djb
for their parts in producing and/or amplifying this FUD.  dnssec is very
subtle and powerfully complex (or complexly powerful?) but both of these
men are very much intelligent enough to know better than they've spoken.

dnssec doesn't guaranty success, it just provides new paths toward failure.

---

From: Alex Bligh <[email-masked]>
Date: Sun, 06 Mar 2005 22:49:58 +0000

--On 06 March 2005 19:26 +0000 Paul Vixie <[email-masked]> wrote:

> are destroyed by loss or congestion,

For my education: Why does an attack which involves *introducing* a
spurious glue record (in vanilla DNS) reduce (in DNSSEC) to an attack where
packets are destroyed by loss or congestion (which I agree in DNSSEC is
insoluble)?

IE if it reduces to a common denominator, what is the (unpreventable)
attack on DNSSEC which produces the same result as MIM glue insertion in
vanilla DNS?

My (as yet uneducated) read had been that both were susceptible to DoS (in
the truest sense) attacks due to packet loss, but that while vanilla DNS
could suffer from injection of false information, the worst that could
happen in a DNSSEC world is that participants could be prevented from
receiving updated information or notification that old information was out
of date. Should I be removing my ever-decreasingly-rose-tinted specs?

Alex

---

From: Johan Ihrén <[email-masked]>
Date: Mon, 7 Mar 2005 03:01:18 +0100

> attack on DNSSEC which produces the same result as MIM glue insertion 

I think you misunderstood Paul.

His point is that with DNSSEC MIM'd glue eventually results in a 
response that doesn't validate and hence is discarded, which is 
basically the same outcome as the response packet being lost in 
transit. What DNSSEC cannot prevent is the spoofing as such, it can 
only help detect when it is happening.

There is no unpreventable attack on DNSSEC that will produce the same 
result as MIM glue insertion in vanilla DNS (i.e. forged data being 
accepted as valid).

> of date.

Signed glue is a red hering. DNSSEC isn't about securing server 
identities, it is about securing data.

As most of you know for a signed delegation the referral will contain 
NS RRset for the child + DS for the child + RRSIG(DS) + possibly some 
glue. The RRSIG(DS) enables the validator to verify whether the data 
from the child is authentic or not regardlesss of whether it arrived 
from the right servers or not. I.e. it will work just fine even if the 
glue is spoofed as long as the bad guy serves data that validate.

For an unsigned delegation there will be no DS nor RRSIG(DS) and hence 
no such protection for the child. In this case the semantics and risk 
of spoofing fall back to be the same as for standard DNS. This is not 
surprising, as an unsigned delegation is a statement of the child not 
having requested the data protection that would come from the 
delegation being signed. I.e. either the child isn't DNSSEC capable or 
it is DNSSEC capable, but, for whatever reason, does its own trust 
anchor distribution.

> Should I be removing my ever-decreasingly-rose-tinted specs?

No.

Regards,

Johan

---

From: Paul Vixie <[email-masked]>
Date: Sun, 06 Mar 2005 23:15:56 +0000

> > the case where the glue is MIM'd reduces to the case where your
> > packets are destroyed by loss or congestion,
> 
> spurious glue record (in vanilla DNS) reduce (in DNSSEC) to an attack
> where packets are destroyed by loss or congestion (which I agree in
> DNSSEC is insoluble)?

it you contact an address which was introduced to you as an authority for
some zone, and it can't answer with a key corresponding to that zone's DS
in the parent zone, then you'll be throwing their answers away, which is
exactly the same in dnssec terms as never having received those answers,
which is exactly what would happen if they never hear your questions.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 07 Mar 2005 09:25:26 +0000

> which is exactly what would happen if they never hear your questions.

Yes I see what you are saying.

Alex

---

From: Dean Anderson <[email-masked]>
Date: Fri, 11 Mar 2005 18:32:35 -0500 (EST)

> > I've not been testing DNSSEC, but I understand it requires TCP.

That's good to hear.

> draft-ietf-dnsext-dnssec-[intro|protocol|records] on RFC Ed Queue.

Will do. Probably should get busy in the lab...

Thanks,

---

From: Dean Anderson <[email-masked]>
Date: Fri, 11 Mar 2005 18:30:02 -0500 (EST)

> That is not a valid reason to avoid DNSSEC. Anycast does work with

Uhh, no, it doesn't. Not when Per-packet-load-balancing (PPLB) is used 
anywhere.

Cisco has been shipping PPLB for a while now. Its been tested: PPLB works
on BGP links, and it works on OSPF links. Its not just external paths you
need to worry about.  If you have OSPF internal network using PPLB, and
the internal paths lead to different external peer interfaces, then
packets could hit different anycast root servers on a per-packet basis. So 
TCP won't work to them.

This was discussed at length some little while back.  The notion that
short-lived tcp can work over anycast is wrong.

> assured to make its implementations poor and insecure.

I don't agree the security problem DNS is a due to implementation bugs.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 11 Mar 2005 18:50:42 -0500 (EST)

> 	you might want to try it out to be sure of your understandings.

Yep.  When I'm not sure of something, I usually say so. 

> 	they did?  guess not everyone received the msg.

I suppose some people ignored the discussion of anycast on DNSOP. And
someone complained that anycast DNS root server operations weren't
relevant to Nanog.  (bmanning)

And I haven't quite forgotten the rather vicious personal attack on me
made by John Brown on DNSOP, where he claimed to have no association with
ISC, even though he started chagres.net with Suzzanne Woolf who was the
ISC project manager in charge of promoting root anycast.

But I suppose that ISC hasn't made any efforts to get the message out. So 
I have little doubt that not everyone has gotten the message.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 14 Mar 2005 09:52:56 +0900

> Uhh, no, it doesn't. Not when Per-packet-load-balancing (PPLB) is used 

That was a point of you instantly denied in last Decemner.

If you use PPLB in a way you think appropriate, unicast TCP
suffers badly.

> This was discussed at length some little while back.

I think there was two follow-ups, one of which was mine.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 14 Mar 2005 18:30:49 +0900

> this statement, however, is not.

My apologies.

DNSSEC can't be helpful, even if  parent zones sign glues.

Sloppy DNSSEC implementations do not distinguish glue As signed by
their parent zones and As signed by authorities, just as sloppy DNS
implementations do not distinguish glue As supplied by their parent
zones and As signed by authorities.

							Masataka Ohta