[Snort-users] Improving the rule "IDS212 - MISC - DNS Zone Transfer"

James Hoagland hoagland at ...47...
Mon Aug 28 22:40:40 EDT 2000


Greetings,

I just spent some amount of time with RFC 1035 in an attempt to 
figure out false positives we regularly get from the Whitehats Zone 
transfer signature.  What I have found that it is hard without a 
module to do protocol analysis.  This is probably why it has not been 
improved.  However I think there is a way to do it without many false 
positives.  I haven't tried it though and I am hardly a DNS expert so 
I thought I'd send it out to the list for people's thoughts.

First, let me thank MAX for his efforts in his thorough database.  It 
is a great service to the community.

Okay, here we go.  This is the current signature, which Max based on 
session analysis:

alert TCP $EXTERNAL any -> $INTERNAL 53 (msg: 
"IDS212/dns-zone-transfer"; content: "|01 00 00 01 00 00 00 00 00 
00|"; flags: AP; offset: 2; depth: 16;)

This is what the RFC shows for the DNS header.

                                     1  1  1  1  1  1
       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     |                      ID                       |
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     |                    QDCOUNT                    |
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     |                    ANCOUNT                    |
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     |                    NSCOUNT                    |
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     |                    ARCOUNT                    |
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

So, the current signature is matching QR=0 and Opcode=0 (a standard 
query), aa=0  (N/A for queries), tc=0 (not truncated), rd=1 
(recursive query), z=0 (as it always is supposed to be), rcode=0 (N/A 
for queries), qdcount=1 (exactly one query present), 
ancount=nscount=arcount=0 (N/A for queries).  So, it is basically 
looking for a packet with 1 query contained.  Nothing here is 
specific to zone transfers as queries.  I'm guessing there aren't 
more false positives since it is looking for TCP.  And actually an 
attacker attempting to bypass the signature might be able to change 
the AA, TC, RD, Z, and RCODE fields to non-standard values without 
effect.

After the above header, there is supposed to be QDCOUNT number of 
question sections of this form:

                                     1  1  1  1  1  1
       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     |                                               |
     /                     QNAME                     /
     /                                               /
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     |                     QTYPE                     |
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     |                     QCLASS                    |
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

QNAME is the ASCII name of the name being asked about (the zone name 
for zone transfers), prefixed with 1 byte indicating the length of 
this name.

QTYPE is the query type (e.g., a zone transfer is 252 (hex FC))

QCLASS is the queried name space (e.g., the Internet).  I think this 
should be either be a small number or 255.

As you can see, it is difficult to look for FC in just the right 
places since there may be multiple query sections and the qname 
section's length varies.  However I think it should be effective to 
look for a byte with FC anywhere after the first byte of the first 
question section.  This assumes that QNAME name doesn't contain FC 
(it shouldn't since FC is not ASCII or commonly found in hostnames) 
and QCLASS is not FC (it shouldn't be, I think).  Also for any 
question sections beyond the first, it assumes the length isn't 252 
(that is an awful long hostname).

So, I propose changing to rule to have content "|FC|", offset 13, and 
eliminate the depth subfield.  I think keeping it be TCP only is okay 
since that is what the attacker would need to get much of the 
response back.

So, what do people think?

Sorry for the long message.

-- Jim
-- 
|*   Jim Hoagland, Associate Researcher, Silicon Defense    *|
|*               hoagland at ...47...                *|
|*  Voice: (707) 445-4355 x13          Fax: (707) 826-7571  *|



More information about the Snort-users mailing list