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!

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.

Friday, January 13, 2012

PortVar Lookup failed on '$FILE_DATA_PORTS'

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

Which includes the FILE_DATA_PORTS variable:

# List of file data ports for file inspection
portvar FILE_DATA_PORTS [$HTTP_PORTS,110,143]

Snort 2.9.1.0, 2.9.1.1 End-of-Life

As you may notice per our EOL Policy located on the Snort.org website:

https://www.snort.org/eol

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:

http://blog.snort.org/2011/12/snort-292-has-been-released.html

Thank you

Thursday, January 12, 2012

VRT Rule Update for 01/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.

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
attack-responses, backdoor, botnet-cnc, chat, exploit, file-identify,
misc, multimedia, policy, specific-threats, spyware-put, sql,
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!

Marty has new chair in his office

Marty decided that he needed a chair for his new office here at Sourcefire.  Thanks to Twitter, this gem was made known to him:


Tuesday, January 10, 2012

Snort 2.9.2 Manuals are updated

The PDF documentation available at http://www.snort.org/docs as well as the HTTP manual at http://manual.snort.org have been updated to Snort 2.9.2.

VRT Rule Update for 01/10/2012, MS Tuesday

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

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

In VRT's rule release:
Synopsis:
The Sourcefire VRT is aware of vulnerabilities affecting products from
Microsoft Corporation and Adobe Inc.

Details:
Microsoft Security Advisory MS12-002:
Microsoft Windows contains a programming error that may allow a remote
attacker to execute code on an affected system.

Rules to detect attacks targeting this vulnerability are included in
this release and are identified with GID 1, SIDs 20878 and 20879.

Microsoft Security Advisory MS12-004:
The Microsoft Windows Media Player contains vulnerabilities that may
allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting these vulnerabilities are included in
this release and are identified with GID 1, SIDs 20880 and 20900.

Microsoft Security Advisory MS12-005:
The Microsoft Object Linking and Embedding engine contains a
vulnerability that may allow a remote attacker to execute code on an
affected system.

Rules to detect attacks targeting this vulnerability are included in
this release and are identified with GID 1, SIDs 20881 through 20883.

Microsoft Security Advisory MS12-006:
The SSL CBC encryption algorithm contains a programming error that may
lead to information disclosure.

A rule to detect attacks targeting this vulnerability is included in
this release and is identified with GID 1, SID 20212.

Microsoft Security Advisory MS12-007:
The Microsoft Anti-Cross Site Scripting Library contains a programming
error that may allow a remote attacker to execute code on an affected
system.

A rule to detect attacks targeting this vulnerability is included in
this release and is identified with GID 1, SID 20884.

Adobe Security Bulletin APSB12-01:
Adobe Acrobat and Reader contain programming errors that may allow a
remote attacker to execute code on an affected system.

Rules to detect attacks targeting these vulnerabilities are included in
this release and are identified with GID 1, SIDs 20919 through 20923.

Additionally this release contains new and modified rules in the
backdoor, blacklist, botnet-cnc, dos, exploit, file-identify, misc,
multimedia, netbios, policy, snmp, specific-threats, sql, web-activex,
web-client 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!

Friday, January 6, 2012

Snort 2.9.2: SCADA Preprocessors

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:

alert tcp $EXTERNAL_NET any -> $HOME_NET 502 ( \
msg:"SCADA Modbus write single register from external source"; \
flow:established,to_server; content:"|06|"; depth:1; offset:7; \
reference:url,www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf; \
classtype:protocol-command-decode; sid:17783; rev:1;)

This rule does a content match on the byte containing the function code. The Modbus protocol is easy enough to decode, but new rule options can make the rule much easier to read:

alert tcp $EXTERNAL_NET any -> $HOME_NET 502 ( \
msg:"SCADA Modbus write single register from external source"; \
flow:established,to_server; modbus_func:write_single_register; \
reference:url,www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf; \
classtype:protocol-command-decode; sid:17783; rev:2;)

Similar rules exist for DNP3. Take rule 1:15713 as an example:

alert tcp $EXTERNAL_NET 20000 -> $HOME_NET any ( \
msg:"SCADA DNP3 device trouble"; \
flow:established,to_client; content:"|05|d"; depth:2; \
byte_test:1,&,64,1,relative; content:"|81|"; depth:1; offset:12; \
byte_test:1,&,64,13; reference:url,www.dnp.org/About/Default.aspx; \
classtype:protocol-command-decode; sid:15713; rev:3;)

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!

alert tcp $EXTERNAL_NET 20000 -> $HOME_NET any ( \
msg:"SCADA DNP3 device trouble"; \
flow:established,to_client; dnp3_ind:device_trouble; \
reference:url,www.dnp.org/About/Default.aspx; \
classtype:protocol-command-decode; sid:15713; rev:4;)

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:

Request:
Function code:      1 Byte      0x01
Starting address:   2 Bytes     0x0000 to 0xFFFF
Quantity of coils:  2 Bytes     1 to 2000

(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:

Response:
Function code:      1 Byte      0x01
Byte count:         1 Byte      N
Coil status:        N Bytes     <Data>

(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:

alert tcp $EXTERNAL_NET any -> $MY_OUTSTATION_IP 20000 ( \
msg:"Somebody writing to my DNP3 outstation!"; \
flow:established,to_server; dnp3_func:write; \
sid:1000000; )

This rule will alert any time a DNP3 Write request is seen going towards $MY_OUTSTATION_IP. If Snort is running inline, you could even block such requests:

drop tcp !$MY_MASTER_IP any -> $MY_OUTSTATION_IP 20000 ( \
msg:"Dropped DNP3 Restart command not originating from my Master"; \
flow:established,to_server; dnp3_func:cold_restart; \
sid:1000001; )

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:

alert tcp $MY_OUTSTATION_IP 20000 -> $EXTERNAL_NET any ( \
msg:"DNP3 Outstation with corrupt configuration"; \
flow:established,to_client; dnp3_ind:config_corrupt; \
sid:1000002; )

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

|---------------------- Packet #1 ---------------------|
[PDU #1: 50 bytes][PDU #2: 200 bytes][PDU #3: 150 bytes]

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

|--------- Packet #1 ---------|-------- Packet #2 --------...|
[PDU #1: 50 bytes][PDU #2: 200 bytes][PDU #3: 150 bytes]....

Just like Scenario #1, PDUs #2 and #3 would evade the IDS. This situation could continue as long as PDUs don’t start on packet boundaries.
Scenario #3: TCP small-segment attack

| Pkt #1 |  Pkt #2  | Pkt #3 | Pkt #4 | Pkt #5 | Pkt #6|
[PDU #1: 50 bytes][PDU #2: 200 bytes][PDU #3: 150 bytes]

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

[--- Packet #1 --][--- Packet #2 ---][--- Packet #3 ---]
[PDU #1: 50 bytes][PDU #2: 200 bytes][PDU #3: 150 bytes]

PAF allows us to write our detection code in terms of PDUs, not packets.

DNP3 Transport-Layer Reassembly

The DNP3 protocol presents some new challenges for large content matches. For starters, CRCs are interspersed in between every 16 bytes of data:

[DNP3 Link-Layer Header][CRC][16 bytes data][CRC][ ... data+CRC pairs ... ]

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.

Tuesday, January 3, 2012

VRT Rule Update for 01/03/2012

Join us as we welcome the introduction of the newest rule release for today from the VRT. In this release we introduced 5 new rules and made modifications to 586 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, dos, exploit, file-identify, misc, policy, rpc,
specific-threats, web-activex, web-client, web-iis and web-php 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!