Imperva Secure Sphere Custom Signatures

Let's take a look into different types and how to create custom Web Application Firewall Signatures

Single Part Signatures
The basic signature unit is part, which contains the actual signature text.
Example: The following signature searches for the text “hello world”.
part=”hello world”
Use \x<hex value> to add binary characters to the signature.
Example: In the following signature the white space is replaced with \x20.
part=”hello\x20world”
To look for the backslash character, enter a double backslash.
Example:The following signature looks for the text “hello\world”.
part=”hello\\world”
Note: The length of the text searched for by part must be at least three characters. Secure Sphere does not save signatures containing part lengths less than three characters.

Multi Part Signatures
You can include as many parts as required in a signature to search for a sequence of text strings.
Example: The following signature:
part=”Imperva”, part=”Secure”, part=”Sphere”
can match either of the following strings:
• abcdImpervaSecureSphere
• abcdImpervaabcdSecureSphere
• abcdImpervaabcdSecure---Sphere
Different parts should be separated by a comma. White spaces are allowed before and after the comma.

Absolute Modifiers
Absolute modifiers limit the part to be matched to a specific area of a stream.
The absolute modifiers that are supported are:
• amin: The absolute position in the stream to start matching this part.
• amax: The absolute position in the stream to stop matching this part.
Example: The following signature searches for the string cmd.exe only from position 10 to position 20 in the stream.
part=”cmd.exe”, amin=”10”, amax=”20”
You can include absolute modifiers after any part by using commas. You can either add a single modifier or both modifiers for each part.

Relative Modifiers
Relative modifiers limit the part to a specific area after the previous part.
The supported relative modifiers are:
• rmin: The position, relative to the previous part to start searching for this part.
• rmax: The position, relative to the previous part to stop searching for this part.
Example: The following signature includestwo parts. The second part is searched for in a range of 10
characters from the first part.
part=”cmd”, part=”.exe”, rmax=”10”
The string cmd12345.exe matches this signature. However the string cmd12345678.exe does not match the signature because the “.exe” part ends 12 characters after the “cmd” part. You can include relative modifiers after any part by using commas. You can either add a single modifier or both modifiers for each part. You can also include both relative and absolute modifiers for the same part.
Relative modifiers are ignored for the first part, as the part must be relative to the previous part, which in this case does not exist.

IBM Rational Appscan 8,7 Scan Configuration

What to Scan Settings
1. To launch the wizard do one of the following:

• Click Create New Scan.
• If AppScan is already open, click the New Scan icon on the toolbar.

2. In the New Scan dialog box, verify that the Launch Scan Configuration Wizard check box is selected.
3. In the Predefined Templates list, select a scan template by clicking on it. If you do not need a specific template, select the Default template.
4. In the Scan Configuration Wizard Welcome screen, select the required scanning option:

• web Application Scan:
• web Service Scan:

Note:The web Service Scan option is only available if GSC (Generic Service Client) is installed on your machine. You can click the blue link to download GSC to your computer, and then double-click on the .EXE file to install it.

Web Application Scan Configuration Wizard
1. Starting URL:Type the URL of your application. The scan will start at this URL.
2. Case Sensitive Path:When this check box is selected (default), links that differ from each other by case only are treated as different pages.
3. Additional Servers and Domains:If your application includes servers or domains other than those of the Starting URL, and your AppScan license includes them, you must add them here so that they will be included in the scan:
a. Click the plus icon to open the Add Servers and Domains dialog box
b. Type in the hostname or IP address of the server, or the domain name (e.g. sitetoscan.com), then click OK. The new item is added to the list.
4. I need to configure additional connectivity settings:By default AppScan uses Internet Explorer proxy settings. Select this check box only if you want AppScan to use a different proxy. This will open an additional step, “URL and Servers: Additional settings,” when you click the Next button.
5. Click Next to continue to the next step of the wizard.

Login Management Settings
1. Select the radio button for the required Login method.
2. Do one of the following:

• For Recorded Login or Prompt, click Record or Import set the a login sequence
• For Automatic Login, simply type inUsername and Password.

If the key icon turns red , AppScan attempted to but was unable to identify any pattern in the in-session page that it can use during scanning to verify that it has not been logged out. To remedy this you should open the extra step of the wizard and either provide AppScan with an identifier manually, or deactivate In-Session Detection

Test Policy Settings
1. To load a different Test Policy, click on one of the Pre-Defined Policies or Recent Policies in the Policy Filespane.
2. Send tests on login and logout pages:
3. Clear session identifiers before testing login pages

Complete the Scan configuration Wizard
Select one of the options:

• Start a full automatic scan:Start a full scan of the application (Explore followed immediately by Test).
• Start with automatic Explore only:Explore the application, but do not proceed to the Test stage. (You can run the Test stage later.)
• Start with Manual Explore:The browser will open and you can manually explore your site by clicking on links and completing fields. AppScan will record the results to use in the Test stage.
• I will start the scan later: Close the wizard without starting a scan. The next time you start a scan, this template will be used. (Schedule the scan option available)

We shall take on the test policies in a different post

Netwitness Investigator Parsers

Ever wondered how Netwitness Investigator differentiate the traffic and produce alerts? Let's take a look into those parsers. Key point to remember: it is session based and not packet based. Priority to packet collection and reassembly before anything else.

1. FlexParse
 » FlexParse exposes the network session parsing and metadata model
    - Configure how to identify applications and extract data

• XML parser definitions
• Register search tokens
• Perform logic operations 
• Register metadata for the NetWitness system

» Why?
   - Instantly customize and expand processing and modeling behavior
   - Processing flexibility for networks with:

• Heavy application profiles
• Proprietary protocols 
• And threats that don’t fall into common intrusion detection methods 

» What's possible…
   - Expand baseline parsers, fast flux identification, social networking profiling, mainframe exploitation, SCADA, file object identification, complex threat identification, …Etc.

2. SCADA MODBUS Parser
» Why?
   - Need insight into SCADA over IP to correlate with other network activity –critical infrastructure                   monitoring
» Demonstrate
   - Create new Service type for MODBUS
   - Simple text based protocol has numeric tokens that map to actions:

• “Read Coil Status”
• “Read Input Status”
• “Read Hold Registers” 
• “Read Input Registers” 
• “Force Single Coil”
• “Force Multiple Coils”
• Etc……

3. Malicious PDF Parser

» Why?

    - One of the most pervasive exploitation techniques used currently

    - Very effective exploitation technique that can be difficult to detect

» Demonstrate

   - Combined existence of PDF tokens, including javascript that classifies potentially malicious objects

   - Use “flags” to keep “state” between several different <match> statements

» A deeper insight to Parser Logic

» Find the following token:

   - HTTP/1.1 200 OK

» If above is found, then find token:

   - Content-Type: application/pdf

» If above is found, then find token:

   - %PDF-1.

» If above is found, then alert if the following is found:

   - /S/JavaScript

4. JRE 0day Analysis

Hunting for Anomalous Traffic

» Profile HTTP for java-archives (potential deployment toolkit)

» Rule: service = HTTP(80) && content = ‘application/java-archive’

Internal host being referred to what?

» Use IP from anomalous traffic analysis

- Rule: ip.src = 156.145.x.x && referrer contains ‘nytimes.com’,’foxnews.com’,etc..’

» Redirection to 95.211.14.21

- Netherlands Hosting Provider

- 95.211.14.21/measure/ad.php

- Inspect php

» Rule to profile & find ad.php querystring:

- service = HTTP(80) && (query contains 'pl=' && query contains 'ce=' && query contains 'hb=' && query contains 'av=' && query contains 'jv=’)

Ad.php behavior

» How many times have I seen this “.gif”?

Compromised Hosts

» Rule: service = HTTP(80) && filename=‘p.gif’ && content = ‘application/octet-stream’

» 3 Sessions

» 3 Unique hosts

Deeper Analysis

» p.gif (exe) appears corrupt

- Does that mean no one was infected?

» Let’s have a look at the .jar

» .jar modifies the first two bytes of the binary to subvert “MZ” token signatures

» FlexParse profile the malware

And there you go: you have parsers ready for show.

How to create UDS for IPS/IDS?

User Defined Signatures for IPS/IDS may relate to three basic scenarios of requirement.
# Emergency Situation:  There may be situations where an attack covering particular vulnerabilities may be a very high priority for your network but might not be provided as swiftly as your security policy might require. In this case, you might need to write and deploy strategic signatures based on your knowledge of your network’s vulnerabilities until an update from McAfee is available.
# Forensic Analysis: It may be useful to deploy specialized signatures to investigate suspicious activity on your network and possibly to track intrusions.
# Custom Signatures for Your Particular Environment: Writing custom signatures for your network environment may be necessary for a variety of reasons. The most common is policy enforcement. For example, your security policy may dictate that certain traffic or usage patterns are disallowed. In such cases, it may be useful to write and deploy signatures that can alert your IT or security staff

Steps to create User Defined Signatures
Step 1: Identify the reason for creating this UDS to make appropriate choices

•  Before creating a signature, you should carefully consider the requirement that you are trying to address. This means that you should have a clear understanding of the signature’s purpose, such as a specific business or policy requirement. 
• You should also have a clear rationale for using a signature,instead of another mechanism. In some cases, a User-Defined Signature may not be the appropriate solution. 
• For this reason, you should consider whether you can address your need with other technical means, such as router ACLs, firewall rules, or a network sniffer. 
• Finally, you should verify that the signature you intend to create does not duplicate functionality already provided in the vendors Intrusion Detection/Prevention System

Step 2: Technical information

• A signature is generally based on an advisory or some other description of a known vulnerability. You should have in hand whatever information you can find regarding what the signature will be used to detect. This can include traffic dumps of an attack in progress or the exploit code itself. You can use this information to determine the characteristics of the vulnerability. 
• This information should include specific criteria that comprise the signature, such as field values and patterns to match. Your research may lead to a long list of characteristics specific to the exploit traffic. Bear in mind, however that a signature based on all suspicious characteristics may be too specific. Although it would be precise, it may be inefficient or lead to detection problems. On the other hand, a signature based on only one of the characteristics may be too broad and generate false positives.

Step 3: Protocol in which this UDS will search the traffic (also known as the impact protocol).

• Identify the traffic first (For eg: TCP or UDP) and then look for the specific protocols which you need to monitor/block (For eg: HTTP). It might be possible that the vendor does not support that specific protocol. In that case a more generic platform oriented approach is advised.

Step 4: Specific hardware or software platforms affected by this traffic (also known as impact packages).

• Identify the OS first (For eg: Windows or Linux) and then enable the package which you need to be protected. But remember in case the vendor does not support the specific platform or package it is wise to select some close to your target.

Step 5: Identify the Severity of this event.

• Specifying a severity comes quite handy in the process workflow specifically with importance to the support staff's reactive measures.

Step 6: The direction in which the 'traffic to be watched for' occurs.

• Specify whether the alert needs to be generated for inbound or outbound or both traffic methodologies.

Step 7: Specific criteria that comprise the signature, such as field values and patterns to match.

• Introduce the signature on strings, hex, regular expressions, etc to action on matching with the traffic.

Step 8: A method, data, or tool to be used for testing the signature. Implementing a signature testing plan

• Use traffic generation tools or packet dumps to verify that your signature(s) match the traffic you intend it to detect.
• Verify that your signature is not duplicating functionality already provided by the Sensor by examining whether your test traffic raises additional alerts other than UDS.
• Deploy the signature to a non-production Sensor connected to either a test network that duplicates your production network traffic or a non-production Sensor connected to your production network in Span or Tap mode.

Signature Components:
# Select:
- Sensors
- Inbound/Outbound
- Range of IP/Host (optional)
- Protocol
- Ports
- Pattern/String/Numeric Comparison
- Mode (Alert/Block/Drop)
- Severity
# Logical Constructs:
The logical constructs provide methods for grouping and ordering the more granular pieces of the signature - numeric tests and pattern matches - in any order you require. The core constructs are:
•  AND- Tests are grouped within AND blocks. The tests must all succeed, but may occur in any order inside the context of a given flow. AND blocks cannot be contained within an OR condition.
•  OR- The first test to succeed fulfills the condition, and the next AND or OR block is engaged. OR constructs are contained withinAND blocks, though at times they may be the only contents.
•  ANDTHEN- ANDTHEN is the ordering construct. By placing ANDTHEN statements between AND blocks, you can create a structured order for your tests, if required.
# Detecting Windows:
The detection window is the portion of the traffic flow that a signature should examine for signature matches. The detection window may be one of:
- Packet- All of the signature tests (and thus all protocol fields) must occur in a single packet on the network.
- Request- All of the signature tests must occur in the request direction of the flow. (Useful if the protocol is bidirectional and might include the same data or commands in either direction.)
- Response- Identical to request, but used to examine only response-direction traffic.
- Flow- When the detection window is set to flow, all conditions can be fulfilled by traffic flowing in either direction. Tests are still subject to any ordering imposed by the structure of the signature or flow direction implied by the field being tested.
- Benign Trigger Probability- This is a measure of the confidence with which the signature writer believes the signature can identify a network event. A high benign trigger probability (BTP) implies that a signature may be prone to false positives. When creating a UDS, you should set the BTP to “Low” to ensure that your signatures are selected by the Default Policy.
- Severity- Severity is simply an indication of how severe the signature writer believes the network event detected by the signature to be. You should set the Severity to at least “Medium” to ensure that the signatures will be selected by the Default Policy.

Please note that this article can be very helpful for those who uses McAfee Network Security Platform *formerly Intrushield*. But it can act as a generic one as well as most of the steps are common in all IDPS with the components might vary in some.