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@lurhq.com> 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
-------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
