DNS Exploit Attempts??

[Terpasaur]

Good morning.

I upgraded our last resolver this morning to the new P1 code and
turned on "rndc querylog". I am seeing a steady stream of these
messages with the same IP at a rate of about 100/min.

Jul 30 11:50:39 ns2 named[2780]: [ID 873579 daemon.info] security:
info: client 194.85.88.199#22941: query (cache) './ANY/IN' denied

Is this an example of the cache exploit attempt?

I've already spoken with our INET team about blocking the IP at the
firewall a couple of days to see if the automated mechanism stops
because of denied access, or if it continues regardless.

Thanks,

Emery Rudolph
Sr. Systems Analyst
Office of Information Technology
University of Maryland University College
Email: Erud...@umuc.edu

[Dawn Connelly]

Hehehe, that address is coming from Russia so you can pretty much assume
it's badness.
If you don't want to wait for your firewall team for future events like
this, you can always blacklist them too.

blackhole { address_match_list };

[Emery Rudolph]

Thanks Dawn,
I must have misunderstood the blackhole directive. I thought it was strictly
for blocking nameserver - nameserver queries as opposed to a client that
points directly at you by making you their primary nameservice.

If this problem flares up again, I will definitely try the option. :-)

[Jeff Lightner]

I was on vacation last week but saw the thread then about these failed
queries.

Someone had apparently posted on a Fedora forum that seeing the high
level of query cache denied was a sign of people trying the exploit but
someone else here said it wasn't a symptom of the exploit.

However, on returning to my office I too saw a dramatic increase in the
number of these. If they aren't for the exploit does someone know why
they increased?

P.S. I'm already patched for the exploit.

----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

[Graeme Fowler]

On Wed, 2008-07-30 at 13:08 -0400, Jeff Lightner wrote:
> Someone had apparently posted on a Fedora forum that seeing the high
> level of query cache denied was a sign of people trying the exploit but
> someone else here said it wasn't a symptom of the exploit.

That's not *quite* correct (well, not even correct actually, but that
sounds churlish).

I said that the addresses listed in the post on the fedora-users list
were actually directly related to research work being done by Dan
Kaminsky and/or some people at a .edu connected to him.

The OP of the message fired off in a panic, IMO, without doing any
homework whatsoever.

> However, on returning to my office I too saw a dramatic increase in the
> number of these. If they aren't for the exploit does someone know why
> they increased?

If you've seen a dramatic increase in log entries, have you done any
work at all to see where they're coming from? Pound to a penny, if you
find they're from an educational institution you'll be able to fire off
an email to someone there (look in WHOIS for the contact details for
starters) and they'll tell you. If they're from Nigeria, Chinese ISPs,
Russia, or a bunch of colo/hosting places in the US or Europe (or other
common malware sources, yours will differ from mine) then they're
probably scans from less friendly types.

There's an interesting message on the OARCI dnsops list here:

http://lists.oarci.net/pipermail/dns-operations/2008-July/003110.html

[note: the sender of that message is the originator of query-cache scans
from Georgia Tech IP IPv4 space]

I guess the important message here is: do some homework first. They may
or may not be malicious, but having an indication either way is good
before you run into the woods with your shotgun.

Graeme

[Dawn Connelly]

True that...but this is most likely the script that was causing the badness
he was seeing: http://www.opennet.ru/dev/fsbackup/src/1.2pl1_to_1.2pl2.diff
It was written by the same guy that owns the IP address space that he was
seeing the . requests coming from. It should still be blacklisted.

[Jeff Lightner]

The point in my post was asking if there was a known thing that occurred
that would have suddenly have spawned more of these kinds of queries
than in the past given that various people are seeing them.

Obviously I could research individual addresses - but my question wasn't
how to research them but rather if there was a known badness that had
suddenly started spawning more of them given that I was seeing them as
others also apparently were.

To that end Dawn's post more closely attempted to answer that than
Graeme's.

I have by the way already created a blacklist. Again I was just
wondering if there was something new and exciting happening.

-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Dawn Connelly
Sent: Wednesday, July 30, 2008 4:01 PM
To: Graeme Fowler
Cc: bind-...@isc.org
Subject: Re: DNS Exploit Attempts??

[Dawn Connelly]

No worries. This particular "attack" isn't new...it's probably just being
used a lot more. It's testing for low hanging fruit to target. If your
recursion is open to the world, it will be wicked easy to poison your
cache... moral of the story- patching is great, but make sure your recursion
ACLs are in place too.

[Jeff Lightner]

Yep.

Recursion and cache query are both prohibited from outside - that was
actually done before the exploit patch because they'd been flagged in a
PCI compliance scan.

________________________________

[Sten Carlsen]

BTW: if you suspect your cache has been poisoned, would more than just
flushing the cache be needed to remove the badness? Other than the
obvious: upgrade to a safe version and disable recursing for that audience.

--
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!"

[Jeff Lightner]

I'd think that wouldn't help much.

If your cache had been poisoned using the new exploit it meant someone
had already found your server was susceptible to the exploit and would
likely be responding to all your queries from that point on. Even
turning off cache wouldn't likely help because all your fresh lookups
would be answered by the bad guy.

[Bruce Esquibel]

Terpasaur <emery....@gmail.com> wrote:

> Jul 30 11:50:39 ns2 named[2780]: [ID 873579 daemon.info] security:
> info: client 194.85.88.199#22941: query (cache) './ANY/IN' denied

> Is this an example of the cache exploit attempt?

Heh, after I read this I enabled the querylog and sure enough, I had an ip
address near that one doing the same thing, on both of our servers.

I did spot another entry in the logs that isn't a concern but odd to me...

client 149.20.56.10#10053: query:
not-an-attack.dan-kaminsky.browse-deluvian.doxpara.com IN ANY +

The ip address goes back to isc.org so just wondering if there is a spider
of sorts running to determine whose name server is running what version or
something.

-bruce
b...@ripco.com

[Paul Vixie]

Bruce Esquibel <b...@e4500.ripco.com> writes:

> client 149.20.56.10#10053: query:
> not-an-attack.dan-kaminsky.browse-deluvian.doxpara.com IN ANY +
>
> The ip address goes back to isc.org so just wondering if there is a spider
> of sorts running to determine whose name server is running what version or
> something.

yes, isc is supporting several dns spiders who are measuring the population
of patched vs. unpatched, and measuring for poison injections.
--
Paul Vixie