[Snort-sigs] DNS Cache Poisoning

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

Cody

On Apr 7, 2005 12:46 PM, Joe Stewart <jstewart at ...5...> wrote:
> 
> Cody,
> 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
> 
> --
> 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.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
>




More information about the Snort-sigs mailing list