Tuesday, December 23, 2014

Snort Subscriber Rule Set Update for 12/23/2014, NTP

Just released:
Snort Subscriber Rule Set Update for 12/23/2014

We welcome the introduction of the newest rule release from Talos. In this release we introduced 11 new rules and made modifications to 1 additional rules.

There were no changes made to the snort.conf in this release.

Talos's rule release:
Synopsis: Talos is aware of a vulnerability affecting Network Time Protocol (NTP). 
Details: CVE-2014-9295: A coding deficiency exists in NTP that may lead to remote code execution. A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 1, SID 32890. 
Talos has also added and modified multiple rules in the browser-plugins, file-flash, file-multimedia, file-other and server-other rule sets to provide coverage for emerging threats from these technologies.

In order to subscribe now to Talos's newest rule detection functionality, you can subscribe for as low as $29 US dollars a year for personal users, be sure and see our business pricing as well at https://www.snort.org/products. Make sure and stay up to date to catch the most emerging threats!

Snort Subscriber Rule Set Update for 12/23/2014, libpng vulnerability

Just released:
Snort Subscriber Rule Set Update for 12/23/2014

We welcome the introduction of the newest rule release from Talos. In this release we introduced 15 new rules and made modifications to 6 additional rules.

There were no changes made to the snort.conf in this release.

Talos would like to thank the following individuals for their contributions, their rules are included in the Community Ruleset:

Avery Tarasov
32888


Talos's rule release:
Synopsis: Talos is aware of a vulnerability affecting libpng. 
Details: Vulnerability in libpng: A coding deficiency exists in the libpng image library that may lead to remote code execution. A previously released rule will detect attacks targeting this vulnerability and has been updated with the appropriate reference information. It is included in this release and is identified with GID 1, SID 3132. A new rule to detect this vulnerability is also included in this release and is identified by GID 1, SID 32889.
Talos has also added and modified multiple rules in the blacklist, exploit-kit, file-flash, file-image, file-other, file-pdf, indicator-compromise, malware-cnc and server-webapp rule sets to provide coverage for emerging threats from these technologies.

In order to subscribe now to Talos's newest rule detection functionality, you can subscribe for as low as $29 US dollars a year for personal users, be sure and see our business pricing as well at https://www.snort.org/products. Make sure and stay up to date to catch the most emerging threats!

Monday, December 22, 2014

Using the protected_content Keyword

I’ve been fiddling with some new options in Snort 2.9.7 rules. Specifically the new protected_content rule option. I discovered some things that are not clear in the Snort Manual so I thought I would share.

The protected_content option is designed to allow searching for content in a packet without having to spell out the content in the rule. That way if your rule is looking for something sensitive, you can hide this from anyone with access to the rule. It’s helpful if you’re looking for things like passwords you have used. In my case I have some content rules looking for my wife’s common passwords leaving the network. (I, of course would never re-use a password) ;-)

My old rules had the password clearly shown in the content match. So I thought this would be a perfect use case for the new keyword. However, there are some considerations. The content keyword looks through the entire packet (or whatever is entered in offset,depth,distance and within) for the string. Protected_content is different, it only looks in a specific spot. When using protected_content you search for a hash of the string instead of the string itself. So Snort has to hash whatever bytes you want to check. Because of this, we can’t really check an entire packet because it would mean calculating hundreds of hashes - way too slow.

The protected_content keyword comes with several parameters:
The hash itself
The hash type (md5, sha256, sha512)
The length of the original string
Optional - offset or distance

Consider:
protected_content:"131848a7d09b05b96ea105fe238619e3"; hash:md5; length:8;
This would look in the packet at byte offset zero for an 8 byte string matching the md5 shown. It would ONLY look in the first 8 bytes. In this case the required length parameter works much like distance or within in a normal content match.

So, you need to look in a specific location. But how then do I find my wife’s password? I have no idea how far into the packet it might be.

There’s another consideration, the protected_content keyword is “computationally expensive” according to the Snort Manual. So we should precede it with a content match to take advantage of the fast pattern matcher. Turns out I can kill two birds here, I can search the entire packet and make the rule more efficient by using a content keyword prior. The answer is to search for a small subset of my protected content to determine what part of the packet to hash. Yes this does somewhat compromise my secret string but it’s a tradeoff to get detection.

Here is the rule:

alert tcp $HOME_NET any -> any any (sid:1000000; content:"over"; protected_content:"ef87dbd48fed4bcaf02cfc9e8c534344"; hash:md5; length:11; distance:-6; metadata:service http, service smtp, service imap, service pop3, impact_flag red; msg:"Sensitive data 1 ...over..."; classtype:sdf; rev:6; )

I start out looking for a portion of the secret word. Hopefully this is as specific as possible without giving away too much. This is followed by the protected content option which backs up far enough to get to the start of my secret word and hash the required bytes.

Some disadvantages of this technique are:

- It’s not as fast as pure “content” but we knew that going in
- It requires that I put part of my secret word into a regular content match

Using a combination of content and protected_content I can now search for sensitive data without worrying (as much) about who has access to my rules. Of course, cracking the hash of a short string is still fairly easy but it does provide at least a bit of protection.

Happy Snorting!

Thursday, December 18, 2014

Snort Subscriber Rule Set Update for 12/18/2014

Just released:
Snort Subscriber Rule Set Update for 12/18/2014

We welcome the introduction of the newest rule release from Talos. In this release we introduced 35 new rules and made modifications to 16 additional rules.

There were no changes made to the snort.conf in this release.

Talos would like to thank the following individuals for their contributions, their rules are included in the Community Ruleset:

Avery Tarasov
32852
32853


Talos's rule release:
Talos has added and modified multiple rules in the app-detect, browser-ie, browser-plugins, file-flash, file-office, file-pdf and os-windows rule sets to provide coverage for emerging threats from these technologies.


In order to subscribe now to Talos's newest rule detection functionality, you can subscribe for as low as $29 US dollars a year for personal users, be sure and see our business pricing as well at https://www.snort.org/products. Make sure and stay up to date to catch the most emerging threats!

Translating a Snort 2.9.X configuration file into a Snort 3.0 configuration file

Enter Snort2Lua

One of the major differences between Snort 2.9.X and Snort 3.0 is the configuration. Snort 2.9.X configuration files are written in Snort-specific syntax while Snort 3.0 configuration files are written in Lua. Snort2Lua is a program specifically designed to convert Snort 2.9.X configuration files into Lua files that Snort 3.0 can understand.


Basic Usage
Snort2Lua is included in the Snort 3.0 distribution. The Snort2Lua source code is located in the tools/snort2lua directory. The program is automatically built and installed.


Translating your configuration
To run Snort2Lua, the only requirement is a file containing Snort 2.9.X syntax. Assuming your configuration file is named snort.conf, run the command
    • snort2lua –c snort.conf
Snort2Lua will output a file named snort.lua. Assuming your snort.conf file is a valid Snort 2.9.X configuration file, than the resulting snort.lua file will always be a valid Snort 3.0 configuration file; any errors that occur are because Snort 3.0 currently does not support all of the Snort 2.9.X options.

Every keyword from the Snort configuration can be found in the output file. If the option or keyword has changed, then a comment containing both the option or keyword’s old name and new name will be present in the output file.


Translating a rule file
Snort2Lua can also accommodate translating individual rule files. Assuming the Snort 2.9.X rule file is named snort.rules and you want the new rule file to be name updated.rules, run the command
    • snort2lua –c snort.rules -r updated.rules
Snort2Lua will output a file named updated.rules. That file, updated.rules, will always be a valid Snort 3.0 rule file. Any rule that contains unsupported options will be a comment in the output file.


Understanding the Output
Although Snort2Lua outputs very little to the console, there are several things that occur when Snort2Lua runs.  This is a list of Snort2Lua outputs.

The console.   Every line that Snort2Lua is unable to translate from the Snort 2.9.X format to the Snort 3.0 format is considered an error. Upon exiting, Snort2Lua will print the number of errors that occurred. Snort2Lua will also print the name of the error file. 

The output file.  As previously mentioned, Snort2Lua will create a Lua file with valid Snort 3.0 syntax.  The default Lua file is named snort.lua.  This file is the equivalent of your main Snort 2.9.X configuration file.

The rule file.   By default, all rules will be printed to the Lua file.  However, if a rule file is specified on the command line, any rules found in the Snort 2.9.X configuration will be written to the rule file instead

The error file.  By default, the error file is snort.rej. It will only be created if errors exist.  Every error referenced on the command line can be found in this file.  There are two reasons an error can occur.
1)   The Snort 2.9.X configuration file has invalid syntax. If Snort 2.9.X cannot parse the configuration file, neither can Snort2Lua.  In the example below, Snort2Lua could not convert the line 'config bad_option'.  Since that is not valid Snort 2.9.X syntax, this is a syntax error.

2)    The Snort 2.9.X configuration file contains preprocessors and rule options that are not supported in Snort 3.0.  If Snort 2.9.X can parse a line that Snort2Lua cannot parse, than Snort 3.0 does not support something in the line.  As Snort 3.0 begins supporting these preprocessors and rule options, Snort2Lua will also begin translating these lines. One example of such an error is dcerpc2.

Additional .lua and .rules files. Every time Snort2Lua parses the include or binding keyword, the program will attempt to parse the file referenced by the keyword.  Snort2Lua will then create one or two new files.  The new files will have a .lua or .rules extension appended to the original filename.


Snort2Lua Documentation
Additional information is available in the Snort2Lua section of the Snort 3.0 manual.