[Snort-sigs] DNS Cache Poisoning
bytejump at ...2420...
Thu Apr 7 13:41:38 EDT 2005
Excellent improvement on the rule, Joe. I hadn't thought of making
that change, though it'll only work on the .com and .net top-level
domains, I believe.
I tested that rule on several pcaps I've got. Some of the pcaps
contain packets that have been a pain due to the false positives
generated by the previous incarnations of the rule. Your modified rule
did not trigger on them.
I also ran the rule against pcaps of the real-world attacks, and the
rule did trigger on those, so it appears that we may have a pretty
consistent rule. The other top-level domains, such as .biz, .info,
.us, .uk, etc. are even more tricky. I'm going to continue trying to
write rules for those as well.
On Apr 7, 2005 12:46 PM, Joe Stewart <jstewart at ...5...> wrote:
> Here's what I've seen - adjusting the depth for the !TLD-SERVER check
> will clear up some false positives, but that's not the only issue with
> the way the signature is written.
> The false positive also occurs when a server uses compression to store
> names from two different domains in the same packet. So, if you have
> example1.com and example2.com in the same packet, the server may store
> example2.com as "example2|c0 xx|" where xx is the pointer to .com in
> example1.com. So it ends up resembling the way an authority record
> for .com might be constructed, and triggers the signature.
> One way to cut down on the number of false positives is to try and avoid
> triggering on packets where the searched-for "c0 xx" follows a name
> instead of an IP address. One way to do this is to search for IP
> addresses by length, so if you have a 4-byte hostname section preceding
> the .com label you could still get false positives, but they should be
> scaled way back. Another way might be PCRE, but it could get ugly. I'm
> seeing no false positives yet with the 4-byte length check so I'm
> sticking with it for now.
> Also, instead of looking for !"TLD-SERVERS", which you point out could
> be evaded by adding that text to a malicious packet, requiring us to
> play with the depth setting, perhaps searching for a number of
> authority records under a certain threshold might help. Of course, the
> attacker could add that number of authority records, but the more
> variations on the signature we have, the less chance the attack will go
> unnoticed globally.
> With that in mind, I've created a variation of your signature with the
> changes I have suggested above:
> alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"com DNS cache poison";
> byte_test:2,<,7,8; content:"|00 04|"; content:"|c0|"; distance:4;
> within:1; content:"|00 02|"; distance:1; within:2;
> byte_jump:1,-3,relative,from_beginning; content:"|03|com|00|"; nocase;
> within:5; classtype:misc-attack; sid:1600; rev:4;)
> Basically the changes are: it looks a for packet with fewer than 7
> authority records (there should usually be 12 or 13, but who knows if
> you find a server with an old root hints file) and where the .com label
> follows an IP address (meaning it's probably the start of a new record
> and not part of a larger text label).
> Joe Stewart, GCIH
> Senior Security Researcher
> LURHQ http://www.lurhq.com/
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net
More information about the Snort-sigs