On Wednesday 06 April 2005 04:13 pm, Cody Hatch wrote:
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).
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
