Bug #301
Updated by Peter Manev almost 13 years ago
Hi, I have noticed something interesting, while testing a pcap with a specific rule. I apologise for the long post, but I would rather give as much info as possible. So here is some general info about the problem The rule is : alert udp any 6881 -> any 1024: (msg:"ET TROJAN Srizbi registering with controller"; dsize:20; content:"|2d|"; offset:6; content:"|2d|"; distance:6; within:1; content:!"|00|server."; offset:44; classtype:trojan-activity; reference:url,www.secureworks.com/research/threats/ronpaul/; reference:url,doc.emergingthreats.net/2007711; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/VIRUS/TROJAN_Srizbi; sid:2007711; rev:9;) Please find a 1 packet pcap that was used for testing the rule. Below is a breakdown of the payload of the packet(UDP , 20 bytes of payload): 0 1 2 3 4 5 6-------------------------------------------“offset:6” (bytes count) 0 1 2 3 4 5 6--------- “distance:6” after 1st match (“|2d|”) (bytes count) 1----- “within:1” (bytes count) 21 00 d1 52 32 b3 f3 0a 79 c0 2d 8c 00 04 00 00 c0 56 36 2d - payload (content:"|2d|" at byte #11 and #20) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20--- byte number (for visualisation purposes) I. Tested with Suricata version 1.1beta2 (rev c8701cf) 1.First of all that rule should not log an alert (shouldn't probably load at all), because "offset:44" looks for a content after the 44th byte of payload. However "dsize:20" limits the rule to packets that have exactly 20 bytes of payload. The rule however DOES fire an alert, because I think(I might be mistaken here in my logic) of the following - "" ...content:!"|00|server."; offset:44;... "" - so it actually looks for anything that does not match "|00|server." after the 44th byte of the payload, but the packet has only 20 bytes of payload , so it matches nothing to nothing that does not match "|00|server." so it does fire an alert. 2. The rule generates an alert with or without "content:!"|00|server."; offset:44;" in it. 3. The rule should not generate an alert once again because of “within:1” - I know that "within" (in this case)means to match the 2nd content string(|2d|) within one byte after the first content match, but we also have "distance:6"(start searching for a match 6 bytes after the previous match) , so that would be the 7th byte (0,1,2,3..7) after the first match which is - |36| (byte #19)- which is not the case judging by the payload, nevertheless the rule still fires. It should generate an alert if within is set to 2 - "within:2" 4. If I try the rule with “within:2” - it does not generate an alert - which might lead to the conclusion that the "within" modifier starts counting at "0" (0,1,2...)- which should not be the case, "within" must start counting at 1. II Tested with Suricata version 1.0.4 1. The rule does NOT generate an alert with or without "content:!"|00|server."; offset:44;" - which is good I think , it is not supposed to. 2. There is another problem though – If I take out "content:!"|00|server."; offset:44;" of the rule, no matter what I set the “within” modifier to be it seems to have no effect on the rule at all – the rule does not generate an alert. 3. If I take out “within:1” and "content:!"|00|server."; offset:44;" out of the rule, then it does generate an alert. Example: alert udp any 6881 -> any 1024: (msg:"ET TROJAN Srizbi registering with controller"; dsize:20; content:"|2d|"; offset:6; content:"|2d|"; distance:6; classtype:trojan-activity; reference:url,www.secureworks.com/research/threats/ronpaul/; reference:url,doc.emergingthreats.net/2007711; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/VIRUS/TROJAN_Srizbi; sid:2007711; rev:9;) Additional info: distance,offset – start counting at 0 within,depth – start counting at 1 http://blog.joelesler.net/2010/03/offset-depth-distance-and-within.html - distance and within modifiers explained by Joel Esler. http://www.snort.org/assets/166/snort_manual.pdf – snort manual (offset,distance and within - 3.5.5, 3.5.6, 3.5.7)