[Snort-sigs] DNS Cache Poisoning
bytejump at ...2420...
Wed Apr 6 13:14:47 EDT 2005
I'm the author of that original sig.
I've now run the sig on my network for a couple of days and had very
few false positives. I have had pcaps sent to me of traffic that
generated a significant number of falses, though, and have been
working on fixes. Unfortunately, though, I'm not terribly optimistic
on that front.
The problem lies with the positioning of the root serveres within the
payload. Adjusting the "depth:50" to "depth:70" may clear up a bunch
of the falses you are getting, but you'll still likely get some. I've
even received pcaps where a non-TLD-SERVER was responding as
authoritative for .com, generating false positives on the rule
(assuming that server wasn't malicious itself).
Essentially what happens is that a non-root server answers as
authoritative for the .com top-level domain. The malicious server uses
DNS compression and a pointer to point to .com within the query
portion of the payload. For example, if you make a DNS query for
"www.sprint.com", the authoritative DNS server for "sprint.com" should
respond and, if using compression, will have 0xc0 (this indicates the
use of compression) followed by a pointer value, and then 0x0002 to
indicate that the response is authoritative. The pointer indicates how
many bytes from the beginning of the payload to check for the name
that is being referred to. In our example, it would be "sprint.com",
so the pointer would point, from the beginning of the payload, to the
"sprint.com" portion of the query "www.sprint.com".
The malicious servers we're seeing claim they are authoritative for
".com" and have a pointer going to the ".com" portion of
"www.sprint.com" in our example. The byte_jump portion of the rule is
what follows this DNS compression pointer.
Unfortunately for us, though, there are instances (quite often) where
the top-level root servers use this same pointing technique to claim
that they are authoritative for ".com". So, if we didn't have the
negated content looking for "TLD-SERVERS" we'd get boatloads of
Doubly-unfortunate though, is the fact that some servers push the
"TLD-SERVERS" further into the payload than 60 bytes, or themselves
respond as authoritative for ".com", which I would consider suspicious
due to the fact that they are not in the root.hints file distributed
with BIND. That's a tinfoil hat issue, though.
Hopefully you can see the difficulty in writing a consistent rule that
avoids false positives and evasion.
On Apr 6, 2005 10:27 AM, Jaramillo, Paul D [CC]
<Paul.D.Jaramillo at ...2992...> wrote:
> Anybody got a decent sig for this yet? I tried the one posted by ISC and it
> generates a continuous stream of false positives.
> alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"com DNS cache poison";
> content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|";
> content:"|00 02|"; distance:1; within:2;
> content:"|03|com|00|"; nocase; within:5; classtype:misc-attack; sid:1600;
> Paul D. Jaramillo
> Security Event Management
> Sprint Corporate Security
More information about the Snort-sigs