[Snort-sigs] DNS Cache Poisoning

Joe Stewart jstewart at ...5...
Thu Apr 7 12:48:57 EDT 2005

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).

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/

More information about the Snort-sigs mailing list