Snort Signatures 101

The following is a set of tips to help you write good rules, avoid common mistakes, and understand the process of bringing a threat from discovery to signature. Please feel free to edit and add to this page!

General Things to Remember

Write to the Vuln, NOT the Exploit

It's not always possible, but always strive to understand the vulnerability and write the signature to detect that. Do NOT cut and paste from an exploit and expect that to be a good signature. Exploits change, are easily modifyable. Vulnerabilities, if understood properly, are static.

However in the event the vulnerability is not understood writing to the exploit for a TEMPORARY signature is often acceptable.

Write to Eliminate

When writing a signature you should try to use protocol options, payload size, ports and other modifiers to ELIMINATE traffic that you are certain is not of interest. This will make your rules more efficient and accurate.

For example, if you know your target packet isn't ever over 100 bytes, put a dsize:<100; in there. It'll let the engine eliminate a lot of packets before going to matching.

Test Test Test

When troubleshooting a signature change or add a single rule option at a time and test. For example; if you wanted to match upon BAD1 & BAD2 within FTP write to match a single item at a time. So start with something like:

alert tcp any any -> any any (msg:"bad content match"; content:"BAD1"; content:"BAD2; sid:10000001; rev:1;)

Once you have this test it on a pcap to make sure it fires then add in each option at a time (such as flow, depths, within, direction and port numbers and so on) and test each change to make sure it still works. In doing this you know that if the rule suddenly breaks or doesn't work the issue lies within the last change and this makes it considerably easier to troubleshoot by only adding in small parts a time and testing then testing the complete rule.

PCRE

PCRE is great, but dangerous. You MUST use some other less expensive match to prequalify packets before applying PCRE. A content match for example for a major part of what you intend to PCRE for is key.

What is the difference between offset, distance, depth and within?

All content matches and modifiers start from the first byte of the payload. None of them will look in the header, that's all parsed and can be matched using other directives.

Depth is how far to LOOK into the payload from the start of the payload.

Distance is how far to SKIP from the LAST byte of the previous match before looking for the current match

Offset is how far to SKIP into the packet from the beginning of the payload before looking for the current match

Within says only look in the NEXT x bytes AFTER the last byte of the last content match.

So offset and depth are from the start of payload and often used together, distance and within are similar but relevant to the last content match.

An example image made by Deapesh Misra:

  • Diagram example:
    Snort-Diagram.png

Activex Rules

When Writing Rule for Activex Rules we have to look for mainly CLSID or PROGID, Vulnerable method and other parameters of the method.

For example:

Exploit:

<object classid='clsid:18A76B9A-45C1-11D3-80DC-00C04F6B92D0' id='target' />
<script language='vbscript'>
argCount = 2
arg1=String(402, "A")
arg2=1
target.CreateStore arg1 ,arg2
</script>

In the above exploit clsid is "18A76B9A-45C1-11D3-80DC-00C04F6B92D0" and vulnerable method is "CreateStore", Now we have to look for these two strings in the rule...
Flow is from_server or to_client.

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"EasyMail Quicksoft ActiveX? CreateStore? method Remote code excution"; flow:established,to_client; content:"18A76B9A-45C1-11D3-80DC-00C04F6B92D0"; nocase; content:"CreateStore"; nocase; classtype:web-application-attack; reference:url,www.milw0rm.com/exploits/9685; sid:xxxx; rev:1;)

This is the first rule.. BUT it will be fired when we accessing a vulnerability Description also.. so we will modify it more better.

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"EasyMail Quicksoft ActiveX? CreateStore? method Remote code excution"; flow:established,to_client; content:"clsid"; nocase; content:"18A76B9A-45C1-11D3-80DC-00C04F6B92D0"; nocase; distance:0; content:"CreateStore"; nocase; distance:0; classtype:web-application-attack; reference:url,www.milw0rm.com/exploits/9685; sid:xxxx; rev:2;)

The above rule is second version of the exploit (not for the Vulnerability) we have added clsid and distance modifier for the id and createstore.. This rule also fires sometimes for the vulnerability description but lesser than first one.

To avoid FP for this rule we will add PCRE...

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"EasyMail Quicksoft ActiveX? CreateStore? method Remote code excution"; flow:established,to_client; content:"clsid"; nocase; content:"18A76B9A-45C1-11D3-80DC-00C04F6B92D0"; nocase; distance:0; content:"CreateStore"; nocase; distance:0; pcre:"/<object\s*[^>]*\s*classid\s*=\s*(?P\x22|\x27|)\s*clsid\s*\x3a\s*{?\s*18A76B9A-45C1-11D3-80DC-00C04F6B92D0\s*}?\s*(?P=q1)(\s|>)/si"; classtype:web-application-attack; reference:url,www.milw0rm.com/exploits/9685; sid:xxxx; rev:3;)

Now this rule will not trigger on vulnerability descriptions... cause we have added PCRE to look for OBJECT, classid and clsid in a sequence. Now this rules is perfectly works for the above exploit..

Exploit:(with modification)

<script language='vbscript'>
argCount = 2
arg1=String(402, "A")
arg2=1
target.CreateStore arg1 ,arg2
</script>
<object classid='clsid:18A76B9A-45C1-11D3-80DC-00C04F6B92D0' id='target' />

The above exploit also works same as old one.. but our rule will not fire this new exploit.. for this reason I am removing distance modifier for Createstore method.

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"EasyMail Quicksoft ActiveX? CreateStore? method Remote code excution"; flow:established,to_client; content:"clsid"; nocase; content:"18A76B9A-45C1-11D3-80DC-00C04F6B92D0"; nocase; distance:0; content:"CreateStore"; nocase; pcre:"/<object\s*[^>]*\s*classid\s*=\s*(?P\x22|\x27|)\s*clsid\s*\x3a\s*{?\s*18A76B9A-45C1-11D3-80DC-00C04F6B92D0\s*}?\s*(?P=q1)(\s|>)/si"; classtype:web-application-attack; reference:url,www.milw0rm.com/exploits/9685; sid:xxxx; rev:4;)

Now This rule work for both Exploits...
We have to read the Vulnerability description thoroughly to develop a rule which work for Vulnerability not for exploit.. here we have added only one method there may be other methods which are vulnerable.
If we have another Vulnerable method call 'Retrivestore' what could be the next version of the rule??

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"EasyMail Quicksoft ActiveX? CreateStore? method Remote code excution"; flow:established,to_client; content:"clsid"; nocase; content:"18A76B9A-45C1-11D3-80DC-00C04F6B92D0"; nocase; distance:0; pcre:"/<object\s*[^>]*\s*classid\s*=\s*(?P\x22|\x27|)\s*clsid\s*\x3a\s*{?\s*18A76B9A-45C1-11D3-80DC-00C04F6B92D0\s*}?\s*(?P=q1)(\s|>)/si"; pcre:"/(createstore|retrivestore)/i"; classtype:web-application-attack; reference:url,www.milw0rm.com/exploits/9685; sid:xxxx; rev:6;)

This is unfortunately a very computationally expensive rule. We have included two PCREs. This signature will be best split into two. Content matches are far less expensive than PCRE.

Common Mistakes

Distance

Distance applies to the previous content match, and is relative to the end of the match before that. So a distance modifier can come only after at least the second content match and modifies the two prior.

Normally every content match is evaluated from the beginning of the packet. NOT from the end of the last match. if you want to specify that a string should occur only after the last match you should use:

content:"match1"; content:"match2"; distance:0;

This means the second match cannot start until after the first.

Flow

Always use flow when possible. It'll help the engine eliminate a lot of traffic.

References

Do NOT put http:// into a reference string. It is assumed when you use url.

User-agent references

Before writing a signature for a reference please consult the following ilnk to make sure it's unique:

https://developer.mozilla.org/En/User_Agent_Strings_Reference

http://msdn.microsoft.com/en-us/library/ms537503(VS.85).aspx

http://www.botsvsbrowsers.com/

http://www.useragentstring.com

Contributors

wolvee jonkman
Topic attachments
I Attachment Action Size Date Who Comment
PNGpng Snort-Diagram.png manage 18.5 K 2009-09-25 - 19:02 UnknownUser  
Edit | Attach | Print version | History: r11 | r9 < r8 < r7 < r6 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r7 - 2009-10-22 - MattJonkman
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © Emerging Threats