OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: [Snort-users] Improving the rule "IDS212 - MISC - DNS Zone Transfer"
From: James Hoagland (hoaglandsilicondefense.com)
Date: Mon Aug 28 2000 - 21:40:40 CDT

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    *|
|*               hoaglandSiliconDefense.com                *|
|*  Voice: (707) 445-4355 x13          Fax: (707) 826-7571  *|
_______________________________________________
Snort-users mailing list
Snort-userslists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/snort-users