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: 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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 6 Mar 2005 07:49:50 -0800

First we have to understand that we are dealling with a very different
security problem to the one that was considered when DNSSEC was first
proposed. At that time the governing paradigm was 'security perfectionism'.
We are facing a rather different problem, criminal gangs with significant
but finite resources.

We do not need to preclude an attack absolutely, but we do need to reduce
the incentive to try. In particular we want to make it such that an attacker
is unlikely to believe that they will be able to recover the cost of
developing an attack before it is closed.

DNSSEC might be overdesigned for the current set of attacks but as a
pragmatic matter it is very unlikely that it would be possible to get
agreement on a simpler scheme in less time than it would take to deploy the
current DNSSEC. Also the combination of four years further action of Moore's
law, the use of DNS to distribute security policy information and an
imminent pain point mean that deployment possibilities are now open that did
not exist in 2000.

To answer Florian's point, yes it looks like this particular attack is a bug
exploit, not a protocol exploit, but the attack is illustrative of the type
of measure being used to perform phishing type attacks. It takes us much
longer to respond than it takes the attacker to switch tactics.

---

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

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

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

Yes I see what you are saying.

Alex

---

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

On Sun, 6 Mar 2005, Frederico A C Neves wrote:

> On Sun, Mar 06, 2005 at 12:03:20AM -0500, Dean Anderson wrote:
> > On Sat, 5 Mar 2005, Hallam-Baker, Phillip wrote:
> > I've not been testing DNSSEC, but I understand it requires TCP.
> 
> No it doesn't. 

That's good to hear.

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

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

Thanks,

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

---

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

On Sun, 6 Mar 2005, Masataka Ohta wrote:

> Dean Anderson wrote:
> > 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.
> 
> That is not a valid reason to avoid DNSSEC. Anycast does work with
> short-lived TCP.

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.

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

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)

On Sun, 6 Mar 2005 [email-masked] wrote:

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

> > (Anycast only works on UDP single packet per transaction protocols. ISC
> > mistakenly told root operators that anycast can be deployed with TCP.) 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