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!

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!

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!

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.

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.

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:

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.

Connectivity

Balanced

Security

The last state is "in no policies".

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.

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.

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.

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:

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!

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.

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.

Friday, January 13, 2012

If you receive this error, this basically means that you've not added the FILE_DATA_PORTS variable into your snort.conf file.

We are increasingly using this variable across multiple categories to be able to more thoroughly cover file based attack vectors, and will continue to use it, so make sure you are using the snort.conf provided by the VRT here:https://www.snort.org/configurations

Snort 2.9.1.0 has reached it's end of life and Snort 2.9.1.1 will reach it's end of life next week. We'll be removing 2.9.1.0 on Tuesday's release (January 17th) and 2.9.1.1's support will be removed on Thursday (January 19th).

If you are using either one of these versions, we highly recommend that you upgrade to Snort version 2.9.2 which includes some new groundbreaking technology:

Thursday, January 12, 2012

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

It is imperative that you use PulledPork to update your rules as all rules that set flowbits in the file-identify and set to "noalert" are now off by default. We will be discussing this in an upcoming blog post.

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!

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!

Friday, January 6, 2012

Snort 2.9.2 marks Snort’s first foray into the world of "Supervisory Control And Data Acquisition", or SCADA. In this release, we have added preprocessors to support the DNP3 and Modbus protocols.
SCADA covers a broad range of networks, from industrial control processes to utility distribution. There are a slew of protocols and devices out there. These networks have some similar characteristics; they involve a central "Master" device that sends commands and reads data from several "Outstation" devices. These outstations are typically small embedded systems, and they may even communicate over serial link to a gateway which passes the messages over TCP/IP.
The following documents can help get you up to speed:

The complete Modbus specifications are free to download, but the DNP3 specs will require a paid membership at www.dnp.org. The DNP3 Primer will be enough for this blog post.
The DNP3 and Modbus preprocessors will decode their respective protocols, check for certain anomalies, and provide rule options for some of the protocol fields. The Snort Manual (XXX: LINK MANUAL, manual.snort.org/nodeXXXXX.html) will act as a reference for preprocessor and rule syntax, while this blog post will highlight some of the tasks you can perform:

Easier Rule Writing:

VRT releases a set of Modbus and DNP3 rules in their "scada.rules" file. Prior to Snort 2.9.2, these rules had to decode the protocol with "content" and "byte_test" rules. This makes for some cumbersome rules.
Here is rule 1:17782, as it was written before the Modbus preprocessor:

This rule is checking for DNP3’s "start" bytes (0x0564), checking the direction set in the Link-Layer header, checking for the "response" function code, then finally decoding the "Internal Indicators" field to read the "device trouble" flag. Now, we can let the preprocessor handle the boilerplate!

The introduction of new rule options will make it easier to tailor Snort to your particular SCADA deployment.

Anomaly Detection:

The Modbus and DNP3 preprocessors will perform some sanity checking on the packets that they inspect. DNP3 packets are interspersed with checksums, and Snort can be configured to alert when they are incorrect. A large number of alerts could indicate a faulty device or network connection.
Both protocols contain multiple length fields, and Snort’s preprocessors need to check them meticuously to make sure that the traffic is valid. For instance, Modbus packets contain an overall length for the PDU, but each Modbus function has a defined format. Let’s take Modbus function #1, "Read Coils", as an example:

(Source: MODBUS Application Protocol, version 1.1b, page 12)
Modbus "Read Coils" requests should always be 5 bytes long. If Snort encounters a "Read Coils" request that is not 5 bytes long, an alert on rule 144:1 (MODBUS_BAD_LENGTH) will be generated.
Now, take a look at the response format:

(Source: MODBUS Application Protocol, version 1.1b, page 12)
Here, the response is at least 3 bytes, but could contain up to 258 bytes. However, the Modbus header earlier in the packet contains its own length field. If the byte count in the response does not line up with the original length, then the packet is invalid and Snort will generate an alert.
This type of checking is done in several areas of the Modbus and DNP3 preprocessors. In general, we are looking for situations where invalid traffic could cause implementations to crash if they were not programmed defensively. Alerts may indicate faulty devices, or an attacker’s attempt to find vulnerabilities.

Access Control / Auditing

The new Modbus and DNP3 rule options allow you to keep a log of interesting, yet legitimate, traffic. Suppose your network contains a DNP3 outstation device, and in a typical usage scenario your master station polls this device to read data. Under normal operation, you would not send write requests to this device, so you would like to know if a write request is attempted. This can be accomplished with a simple Snort rule:

This rule would drop any packets containing a DNP3 "Cold Restart" command, unless the source IP on the packet matched the IP of your Master station.

Logging Error Conditions

These protocols already provide tools for devices to communicate that they are having trouble. Modbus devices can return Exception codes in place of Function codes, and DNP3 devices can use the "Internal Indications" field. Snort rules can be written to generate alerts when these errors happen.
The following rule will alert if a DNP3 Outstation reports that it has a corrupt configuration:

Protocol-Aware Flushing

The Modbus and DNP3 preprocessors take advantage of Protocol-Aware Flushing (PAF), a Stream5 feature that we introduced back in Snort 2.9.1. For information on PAF itself, see the blog post "What Is PAF?" (http://blog.snort.org/2011/09/what-is-paf.html)
Modbus and DNP3 were both designed for use with serial-link networks, even though they can be carried over TCP/IP. The typical PDU size can be measured in dozens or hundreds of bytes. In addition, these protocols use a binary format that made it cumbersome to write Snort rules. A rule needs to reliably read data at specific offsets within a PDU.

For Stream reassembly to be useful, the reassembled packets had to resemble complete PDUs. Stream5’s original one-size-fits-all reassembly strategy would not be suitable. Consider the following scenarios:
Scenario #1: Multiple PDUs contained in a single TCP segment

The small PDU size of SCADA protocols allows multiple PDUs to get combined into a single TCP segment. Before PAF, a Snort rule would have treated this as a single PDU. PDUs #2 and #3 would have successfully evaded the IDS.
Scenario #2: PDUs not aligned on TCP segment boundaries

This is the type of attack that previous generations of the Stream preprocessor were designed to defeat. In this scenario, no packet contains a full PDU, and packets need to be reassembled before there is any meaningful detection. However, traditional Stream5 flush points would have taken us back to Scenario #1. The PDUs are so small that it doesn’t make sense to reassemble 400 bytes into a single packet.

PAF solves this problem by letting us statefully inspect Modbus or DNP3 traffic, read the header’s length field, and set Stream5’s flush point accordingly. These new preprocessors require PAF to be enabled (this is on by default in Snort 2.9.2). With PAF, reassembled packets look like this:
Scenario #4: Packets reassembled with PAF

So, if a Snort rule is attempting a content match somewhere in the user data, there is a likely chance that the data will be interrupted by CRCs.
On top of that, DNP3 is a three-layer protocol that provides its own segmentation. While each individual Link-Layer frame has a maximum size of 260 bytes, they can be reassembled into Application-Layer fragments with sizes closer to 2 kB. The DNP3 Transport Layer is the layer in between that provides this segmentation.
Snort’s DNP3 preprocessor will queue up segments and reassemble them, stripping out the CRCs. This provides an Application-Layer message for the "dnp3_data" rule option. When DNP3’s reassembly rules call for segments to be dropped, the Snort preprocessor will generate an alert on rule 145:3 (Bad Sequence Number) or rule 145:4 (Reassembly Reset).

Plans for Future SCADA Support

The Snort team is interested in bringing support for more SCADA protocols. If there are other SCADA protocols that are of interest on your particular network, we’d like to know so we can look into them for possible inclusion in future releases. You can reach us at snort-team@sourcefire.com. We can always use…

Protocol Specs

Traffic captures (sanitized)

Sample implementations

Beta Testers

If you run Snort on a network with Modbus or DNP3 traffic, please try the new preprocessors and tell us what you think! We are interested in all constructive feedback. Should you encounter a bug, please use these instructions (https://www.snort.org/community#bugs) to submit a bug report.This blog post written by Ryan Jordan, we'd like to thank Ryan for his significant contributions to Snort and Sourcefire and we wish him luck in his future endeavors.

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!