[Snort-devel] Problems with .ida rules in web-iis.rules

Russell Fulton r.fulton at ...1343...
Wed Sep 25 12:23:09 EDT 2002


Form current rules (web-iis.rules) whe have:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS ISAPI .ida attempt"; uricontent:".ida?"; nocase; dsize:>239; flow:to_\server,established; reference:arachnids,552; classtype:web-application-attack; reference:bugtraq,1065; reference:cve,CAN-2000-0071; sid:1243\;  rev:6;)
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS ISAPI .ida access"; uricontent:".ida"; nocase; flow:to_server,establi\shed; reference:arachnids,552; classtype:web-application-activity; reference:cve,CAN-2000-0071; reference:bugtraq,1065; sid:1242;  rev:6;)

over the last few months (since I switched to 1.9 ?) I have noticed that most
codered alert are triggering the second rule not the first:


[**] WEB-IIS ISAPI .ida access [**]
09/19-20:25:48.172968 200.248.63.13:3534 -> 130.216.16.10:80
TCP TTL:240 TOS:0x10 ID:0 IpLen:20 DgmLen:1504
***AP*** Seq: 0xC40FDEA8  Ack: 0x48B72C65  Win: 0xFAF0  TcpLen: 20
0x0000: 00 E0 1E 8E 31 71 00 00 0C 46 5C D1 08 00 45 10  ....1q...F\...E.
0x0010: 05 E0 00 00 00 00 F0 06 00 00 C8 F8 3F 0D 82 D8  ............?...
0x0020: 10 0A 0D CE 00 50 C4 0F DE A8 48 B7 2C 65 50 18  .....P....H.,eP.
0x0030: FA F0 00 00 00 00 47 45 54 20 2F 64 65 66 61 75  ......GET /defau
0x0040: 6C 74 2E 69 64 61 3F 4E 4E 4E 4E 4E 4E 4E 4E 4E  lt.ida?NNNNNNNNN
0x0050: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E  NNNNNNNNNNNNNNNN
0x0060: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E  NNNNNNNNNNNNNNNN
0x0070: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E  NNNNNNNNNNNNNNNN
0x0080: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E  NNNNNNNNNNNNNNNN
0x0090: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E  NNNNNNNNNNNNNNNN
0x00A0: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E  NNNNNNNNNNNNNNNN
0x00B0: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E  NNNNNNNNNNNNNNNN
0x00C0: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E  NNNNNNNNNNNNNNNN
0x00D0: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E  NNNNNNNNNNNNNNNN
0x00E0: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E  NNNNNNNNNNNNNNNN
0x00F0: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E  NNNNNNNNNNNNNNNN
0x0100: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E  NNNNNNNNNNNNNNNN
0x0110: 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E  NNNNNNNNNNNNNNNN
0x0120: 4E 4E 4E 4E 4E 4E 4E 25 75 39 30 39 30 25 75 36  NNNNNNN%u9090%u6
0x0130: 38 35 38 25 75 63 62 64 33 25 75 37 38 30 31 25  858%ucbd3%u7801%
0x0140: 75 39 30 39 30 25 75 36 38 35 38 25 75 63 62 64  u9090%u6858%ucbd
0x0150: 33 25 75 37 38 30 31 25 75 39 30 39 30 25 75 36  3%u7801%u9090%u6
0x0160: 38 35 38 25 75 63 62 64 33 25 75 37 38 30 31 25  858%ucbd3%u7801%
0x0170: 75 39 30 39 30 25 75 39 30 39 30 25 75 38 31 39  u9090%u9090%u819
0x0180: 30 25 75 30 30 63 33 25 75 30 30 30 33 25 75 38  0%u00c3%u0003%u8
0x0190: 62 30 30 25 75 35 33 31 62 25 75 35 33 66 66 25  b00%u531b%u53ff%
0x01A0: 75 30 30 37 38 25 75 30 30 30 30 25 75 30 30 3D  u0078%u0000%u00=
0x01B0: 61 20 20 48 54 54 50 2F 31 2E 30 0D 0A 43 6F 6E  a  HTTP/1.0..Con
0x01C0: 74 65 6E 74 2D 74 79 70 65 3A 20 74 65 78 74 2F  tent-type: text/
0x01D0: 78 6D 6C 0A 48 4F 53 54 3A 77 77 77 2E 77 6F 72  xml.HOST:www.wor
0x01E0: 6D 2E 63 6F 6D 0A 20 41 63 63 65 70 74 3A 20 2A  m.com. Accept: *
0x01F0: 2F 2A 0A 43 6F 6E 74 65 6E 74 2D 6C 65 6E 67 74  /*.Content-lengt
0x0200: 68 3A 20 33 35 36 39 20 0D 0A 0D 0A 55 8B EC 81  h: 3569 ....U...
[ snip ]

snort Version 1.9.0beta6 (Build 201)

This appears to be a bug.

About 1 in 10 probes triggers the first rule as expected.  I have examined the
two sets of packets but can not spot any signifcant differences that would 
account for the difference in treatment.  This behaviour has persisted over
several different builds on 1.9.

Has anyone else noticed this?

-- 
Russell Fulton, Computer and Network Security Officer
The University of Auckland,  New Zealand

"It aint necessarily so"  - Gershwin

-- 
Russell Fulton, Computer and Network Security Officer
The University of Auckland,  New Zealand

"It aint necessarily so"  - Gershwin
-- 
Russell Fulton, Computer and Network Security Officer
The University of Auckland,  New Zealand

"It aint necessarily so"  - Gershwin





More information about the Snort-devel mailing list