Tuesday, January 31, 2012

VRT Rule Release for 01/31/2012

Join us as we welcome the introduction of the newest rule release for today from the VRT. In this release we introduced 18 new rules and made modifications to 380 additional rules.

There were no changes made to the snort.conf in this release.In VRT's rule release:
Synopsis:This release adds and modifies rules in several categories.Details:The Sourcefire VRT has added and modified multiple rules in theexploit, file-identify, netbios, policy, scada, smtp, specific-threats,spyware-put, telnet, web-client and web-misc rule sets to providecoverage for emerging threats from these technologies.
In order to subscribe now to the VRT'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 http://www.snort.org/store. Make sure and stay up to date to catch the most emerging threats!

Thursday, January 26, 2012

VRT Rule Update for 1/26/2012

Join us as we welcome the introduction of the newest rule release for today from the VRT. In this release we introduced 47 new rules and made modifications to 29 additional rules.

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

In VRT's rule release:
Synopsis:
This release adds and modifies rules in several categories.

Details:
The Sourcefire VRT has added and modified multiple rules in the
backdoor, blacklist, botnet-cnc, exploit, file-identify, ftp, scada,
specific-threats, voip and web-misc rule sets to provide coverage for
emerging threats from these technologies.


In order to subscribe now to the VRT'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 http://www.snort.org/store. Make sure and stay up to date to catch the most emerging threats!

Tuesday, January 24, 2012

VRT Rule Update for 1/24/2012

Join us as we welcome the introduction of the newest rule release for today from the VRT. In this release we introduced 59 new rules and made modifications to 19 additional rules.

There were no changes made to the snort.conf in this release.  This rule pack also introduces coverage for Snort 2.9.1.2

In VRT's rule release:
Synopsis:
This release adds and modifies rules in several categories.

Details:
The Sourcefire VRT has added and modified multiple rules in the
backdoor, blacklist, botnet-cnc, ddos, dos, exploit, file-identify,
oracle, policy, scada, specific-threats, sql, voip, web-activex and
web-misc rule sets to provide coverage for emerging threats from these
technologies.


In order to subscribe now to the VRT'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 http://www.snort.org/store. Make sure and stay up to date to catch the most emerging threats!

Snort 2.9.2.0: Javascript Normalization

JavaScript obfuscation is an technique being increasingly used to modify the malicious Javascript code and make it difficult for analysis or detection. The latest version of Snort introduced JavaScript normalization capability to enhance Snort's client side detection by decoding obfuscated JavaScript and detecting any malicious code or attacks.

This blog post focuses on how to enable this functionality and write rules on the decoded data.

What are the dependencies/suggestions:
-----------------------------------------------
HTTP Config Options:

The HTTP config option "extended_response_inspection" needs to be turned on for the normalization to work as intended.

Along with this option it is suggested to configure the following options as well.

1. inspect_gzip, which turns on the gzip decompression of HTTP response body
2. normalize_utf, which utf normalizes the HTTP body.

Ex: preprocessor http_inspect_server:
extended_response_inspection \
inspect_gzip \
normalize_utf


Or be sure and use the snort.conf provided here: http://blog.snort.org/2011/12/vrt-snortconf-example-files.html

PAF:

PAF should also be enabled on the HTTP ports. For more information on PAF, see the blog post "What is PAF?" (http://blog.snort.org/2011/09/what-is-paf.html)

How to enable the JavaScript normalization in Snort:
--------------------------------------------------------------
The config option "normalize_javascript" should be added to the HTTP Inspect server configuration to enable normalization. When this option is enabled, Http Inspect searches the HTTP response body (decompressed/de-chunked) for JavaScript by looking at the <script> HTML tags. Snort normalizes the standard JavaScript functions such as unescape/decodeUri/decodeUriComponent/String.fromCharCode, in addition, the %uXXX, %XX, \XX, \uXXXX encoding format is also handled by Snort. Apart from these encodings, Http Inspect will also detect consecutive whitespace and normalize it to a single space. The config option "max_javascript_whitespaces" determines the maximum number of consecutive whitespaces allowed within the Javascript.

Syntax: normalize_javascript

Ex: preprocessor http_inspect_server:
extended_response_inspection \
inspect_gzip \
normalize_utf \
normalize_javascript


Here is an example of the Javascript normalization:

HTTP/1.1 200 OK\r\n
Date: Wed, 29 Jul 2009 13:35:26 GMT\r\n
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch10 mod_ssl/2.2.3 OpenSSL/0.9.8c\r\n
Last-Modified: Sun, 20 Jan 2008 12:01:21 GMT\r\n
Accept-Ranges: bytes\r\n
Content-Length: 204\r\n
Keep-Alive: timeout=15, max=99\r\n
Connection: Keep-Alive\r\n
Content-Type: application/octet-stream\r\n\r\n
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>FIXME</title>
</head>
<body>
<script>document.write(unescape("%48%65%6C%6C%6F%2C%20%73%6E%6F%72%74%20%74%65%61%6D%21"));
</script>
</body>
</html>

This encoded Javascript results in the following HTTP response body.
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>FIXME</title>
</head>
<body>
<script>document.write(Hello, snort team!);
</script>
</body>
</html>


There are three new obfuscation related preprocessor alerts added to Snort.
1. The preprocessor alert with SID 9 and GID 120 is generated when the obfuscation levels within the Http Inspect is equal to or greater than 2.
2. The preprocessor alert with GID 120 and SID 11 is generated when there are more than one type of encodings within the escaped/encoded data.
3. The preprocessor alert with GID 120 and SID 10 is generated When the whitespaces in the javascript obfuscated data is equal to or more than "max_javascript_whitespaces" value preprocessor alert with GID 120 and SID 10 is generated.

Please note, due to the performance constraints we currently decode two Javascript nested obfuscation levels. We are looking into making this a user configurable option in a future release.

How to write rules against the normalized data?
--------------------------------------------------------
You can access the normalized JavaScript buffer using the rule option "file_data" as follows:

Ex:
alert tcp any any -> any any ( msg:"Javascript Obfuscation"; file_data; content:"snort team!"; ..)

Monday, January 23, 2012

The importance of PulledPork

Bottom line up front:  If you aren't using PulledPork, you are going to have a gigantic depreciation in functionality.

You've heard it said on the Snort lists, you've heard it on this blog, you've heard it on Twitter,  you've heard it from CNN...  okay, well, not CNN..

The importance of PulledPork.

The reason that we are very heavily insist that you are using pulledpork is primarily for two very big reasons:
  1. Flowbit auto-resolution
  2. Default Policy usage
  • The first reason: Flowbit auto-resolution

I've written in great length about the need for flowbits, you can find a couple of my blog posts here
http://blog.snort.org/2011/05/resolving-flowbit-dependancies.html
and
http://blog.snort.org/2011/12/if-you-are-having-problems-with-your.html

The reason that I'm writing about it again, is that to refresh your memory back when we created the file-identify rule category:
http://blog.talosintel.com/2011/11/say-hello-to-file-identify-category.html

We outlined that part of this conversion was to move all flowbit names from their old names (such as http.gif) to a new format (now file.gif).  This project has now been completed and all flowbits across all files have been moved to the new format, and all the rules that "set" flowbits have been commented to be "off" by default and in no policies.

What we are relying on here is either if you are using PulledPork or the Sourcefire product, you either select your base policy (which I'll talk about in section two), or, even if you don't, PulledPork will auto-resolve the flowbit "set" names that you'll need and go through and turn those on for you.  That way you are only running rules that you need to have on based upon either the policy you are running, or the state of the rules.  We really insist that you use the disablesid and enablesid functionality in PulledPork to be able to turn the rules that you WANT for your environment on and let PulledPork auto-resolve all the dependancies you need for you.
  • The second reason: Policy usage
There are four states that we place rules in when we create them, three of the states are assigned to policies.
  1. Connectivity
  2. Balanced
  3. Security
The last state is "in no policies".

  1. The first, connectivity, means "Connectivity over Security".  Meaning this is a speedy policy for people that insist on blocking only the really known bad with no false positives.  
  2. The second, balanced, means "Balanced between Connectivity and Security".  Meaning that this is a good starter policy for everyone.  It's quick, has a good base coverage level, and covers the latest threats of the day.  The policy contains everything that is in Connectivity.
  3. The third, security, means "Security over Connectivity".  Meaning that this is a stringent policy that everyone should strive to get to through tuning.  It's coverage is much more exhaustive, and has some policy-type rules in it.  Rules that will alert on Flash contained within an Excel file and things like that.  This policy contains everything that is in the first two.

The last state is "in no policies".  This means that we insist that you look through these by product name or CVE in order to turn them on.  These may not have a fast content match, could be false positive prone, or the vulnerability it is covering is not in a very prevalent piece of software.  

The way we make the decision about what is "on" or "off" by default when you aren't using the policies, is, if it's in balanced, it's on by default, it's it not in balanced, it's off by default.  There are a ton of exceptions to this rule, but this is the general rule of thumb.

Unified2 Anonymizer v0.9.0b release!

Eric Lauzon is happy to announce the beta release of u2_anon.

u2_anon is a tool that allows you to "share" anonymized unified2 files to help debug issues or share results without compromising the information contained inside. u2_anon will not modify the unified2 file/files used as the source, but will create a copy of the source unified2 file with anonymized data that can be shared.

I strongly suggest that you run u2_anon on files that are not currently being written by snort, since it will not "spool" unified2 file like barnyard2 or other unified2 readers can do.
u2_anon has 4 different levels or anonymity levels:

[-eE:] [Anonymize Event] 
 - Will set source and destination IP's of EVENT to ipv4 - "127.0.0.1" , ipv6 "::ffff:127.0.0.1" 
 [-lL:] [Anonimize LinkLayer (ethernet)] 
 - Will set source mac to AA:AA:AA:AA:AA:AA and dst mac to BB:BB:BB:BB:BB:BB 
 [-pP:] [Anonymize Packet data] 
 - Will Zero out packet payload 
 [-xX:] [Anonymize Extra DATA event] 
 - Will set IP information to "loopback" and extra data "data" will be zeroed.

u2_anon will work on a single file or a directory containing multiple files.

Note that u2_anon is still beta and new features will be added along the way, if you have comments, suggestions, or bug/issues, please feel free to let me know.

You can download it directly from here https://github.com/binf/u2_anon/tags

Thursday, January 19, 2012

Snort 2.9.2.1 is now available!

Snort 2.9.2.1 includes the following updates and improvements:
* Added new alerts for HTTP (undefined methods & HTTP 0.9 simple requests).

* Updates to the Stream preprocessor in TCP session tracking to avoid re-queuing retransmitted data that was already flushed. Also various tweaks for PAF flushing.

* Updates to the reputation preprocessor to handle shared memory switching.

* Updates to the SCADA preprocessors in their handling of PAF flushing and Modbus request/response length checking. Also tweaks in alerts for reserved DNP3 functions.

* Updates to flowbit groups to always use the group when some rules refer to a flow group while others do not refer to a group for the same flowbit.

* Updates to GTP preprocessor to check invalid extension header length for GTPv1.

* Updates to sfrt library, used in reputation preprocessor and target based configuration, when calculating memory allocated and support for IPv6.

It is now available at https://www.snort.org/downloads in the Latest Release section.

VRT Rule Update for 01/19/2012

Join us as we welcome the introduction of the newest rule release for today from the VRT. In this release we introduced 58 new rules and made modifications to 850 additional rules.

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

This rulepack also as dropped support for Snort 2.9.1.0 and 2.9.1.1 per our EOL Policy.

In VRT's rule release:
Synopsis:
This release adds and modifies rules in several categories.

Details:
The Sourcefire VRT has added and modified multiple rules in the
backdoor, blacklist, botnet-cnc, exploit, file-identify, misc, policy,
scada, shellcode, specific-threats, web-activex and web-client rule
sets to provide coverage for emerging threats from these technologies.


In order to subscribe now to the VRT'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 http://www.snort.org/store. Make sure and stay up to date to catch the most emerging threats!

Monday, January 16, 2012

Basic Setup of Security-Onion: Snort, Snorby, Barnyard, PulledPork, Daemonlogger

Basic Setup of Security-Onion: Snort, Snorby, Barnyard, PulledPork, Daemonlogger (Hacking Illustrated Series InfoSec Tutorial Videos)

A great little basic setup on Security-Onion (a Linux Distribution that uses Snort, Daemonlogger, and PulledPork). Great job!

GTP Decoder and Preprocessor

GPRS Tunneling Protocol (GTP) is a group of IP-based communications protocols used to carry General Packet Radio Service (GPRS) within Global System for Mobile Communications (GSM), Universal Mobile Telecommunications Service, (UMTS) and Long Term Evolution (LTE) networks. To help thwart the increasing number of attacks to those networks, we provide two components: GTP decoder and GTP preprocessor.

GTP decoder extracts payload inside the GTP Protocol Data Unit (PDU); GTP preprocessor inspects all the signaling messages and provide keywords for further inspection. These components work separately; you can use either or both depending on your needs. All of three versions (GTPv0, GTPv1, and GTPv2) are supported.

This article focuses on how to use GTP decoder and GTP preprocessor effectively.

GTP Decoder

When the decoder is enabled and configured as below:

config enable_gtp

The decoder strips the GTP headers and parses the inner IP/TCP/UDP encapsulated packets. Therefore all rules and detection work as if there was no GTP header.

Example:

Most GTP packets look like this

IP -> UDP -> GTP -> IP -> TCP -> HTTP

If you had a standard HTTP rule:

alert tcp any any -> any $HTTP_PORTS (msg: "Test HTTP"; flow:to_server,established; content:"SOMETHINGEVIL"; http_uri; .... sid:X; rev:Y;)"

It would alert on the inner HTTP data that is encapsulated in GTP.

In addition to decode, it also provides alerts for GTP in GTP and invalid header length.

GTP Preprocessor

Different from GTP decoder, GTP preprocessor examines all signaling messages.
After it is enabled using:

preprocessor gtp

It will inspect all the control channel messages. It can provide alerts about invalid message length, information element length, and out of order information elements.

GTP preprocessor also provides several rule options to help customize inspection.

drop udp any any -> any any ( msg: "GTPv0 is not supported!"; gtp_version:0; sid:1000000)

This rule blocks all the GTP version 0 messages when the network does not support GTP version 0 any more.

By using gtp_type, you can write rules to alert/block some message types that your communication network does not support.

drop udp any any -> any any ( msg: "Location messages are not supported!"; gtp_type: send_routing_info_request, send_routing_info_response ; sid:2000000)

Since location management messages are optional, some networks do not support them. This rule prevents the attackers against those messages.

In addition, gtp_info provides more fine grain control, you can inspect the information elements inside the message. Using gtp_info with content keyword together, you can control what information element is allowed in your network.

alert udp any any -> any any ( msg: "MS is not validated!"; gtp_version:1; gtp_info:ms_validated; content: "|0d0e|"; sid:3000000)

This rule checks whether Serving GPRS Support Node (SGSN) has successfully authenticated the Mobile Station (MS). If not, an alert will be generated.

If you are using GTP decoder and preprocessor in your network, please share your experience with us.