Defining custom data leak & attack signatures

Custom signatures can be attack signatures and/or data leak signatures.

If the predefined regular expressions cause false positives or do not match what you need, you can configure your own. This gives you the flexibility to define your own special types of personally identifiable information, as well as zero-day attacks.

Signatures should be crafted carefully to avoid performance issues inherent in regular expressions that use recursion. For details, see Regular expression performance tips.

To configure a custom signature

Go to Web Protection > Known Attacks > Custom Signature.
To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Web Protection Configuration category. For details, see Permissions.

From the Custom Signature tab, click Create New, then configure these settings:

Name	Type a unique name that can be referenced in other parts of the configuration. The maximum length is 63 characters.
Direction	Select which direction FortiWeb applies the expression to: Request—The custom signature is designed to detect attacks. Response—The custom signature is designed to detect information disclosure.
Action	Select the action FortiWeb takes when it detects a violation of the rule: Alert—Accept the request and generate an alert email and/or log message. Note: If Direction is Data Leakage, does not cloak, except for removing sensitive headers. Sensitive information in the body remains unaltered. Alert & Deny—Block the request (reset the connection) and generate an alert and/or log message. This option is applicable only if Direction is Signature Creation. You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages). Erase & Alert—Hide replies with sensitive information (sometimes called “cloaking”). Block the reply (or reset the connection) or remove the sensitive information, and generate an alert email and/or log message. This option is applicable only if Direction is Data Leakage. If the sensitive information is a status code, you can customize the web page that will be returned to the client with the HTTP status code. Note: This option is not fully supported in Offline Protection mode. Effects will be identical to Alert; sensitive information will not be blocked or erased. Period Block—Block subsequent requests from the client for a number of seconds. Also configure Block Period. You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages). Note: If FortiWeb is deployed behind a NAT load balancer, when using this option, you must also define an X-header that indicates the original client’s IP. Failure to do so may cause FortiWeb to block all connections when it detects a violation of this type. For details, see Defining your proxies, clients, & X-headers. Erase, no Alert—Hide replies with sensitive information (sometimes called “cloaking”). Block the reply (or reset the connection) or remove the sensitive information without generating an alert email and/or log message. This option is applicable only if Direction is Data Leakage. Note: This option is not fully supported in Offline Protection mode. Send HTTP Response—Block and reply to the client with an HTTP error message and generate an alert email and/or log message. You can customize the attack block page and HTTP error code that FortiWeb returns to the client. For details, see Customizing error and authentication pages (replacement messages).
Block Period	Type the number of seconds that you want to block subsequent requests from the client after the FortiWeb appliance detects that the client has violated the rule. This setting is available only if Action is set to Period Block. The valid range is from 1 to 3,600 seconds (1 hour). For details, see Monitoring currently blocked IPs.
Severity	When rule violations are recorded in the attack log, each log message contains a Severity Level (`severity_level`) field. Select which severity level the FortiWeb appliance will use when it logs a violation of the rule: Low Medium High The default value is High.
Trigger Action	Select which trigger, if any, that the FortiWeb appliance will use when it logs and/or sends an alert email about a violation of the rule. For details, see Monitoring currently blocked IPs.

Click OK.
Click Create New to create a custom signature condition rule. The condition rules in the same custom signature are in "AND" relationship.

Complete the following settings:

Match Operator	Regular expression match—The signature matches when the value of a selected target in the request or response matches the Regular Expression value. Greater than/Less than/Not equal/Equal—FortiWeb determines whether the signature matches by comparing the value of a selected target in the request or response to the Threshold value.
Case Sensitive	Select to differentiate between upper case and lower case letters in the Regular Expression value. For example, when this option is enabled, an HTTP request involving `tomcat` would not match a sensitive information signature that specifies T`omcat` (difference is lower case “t”).
Regular Expression	Specifies the value to match in a selected target. If the Action is Alert & Erase, enclose the portion of the regular expression to erase in brackets. For example, the regular expression value `(webattack)` detects and erases the string `webattack` from responses. To create and test a regular expression, click the >> (test) icon. For details, see Regular expression syntax.
Threshold	If Greater Than, Less Than, Equal, or Not Equal is selected as the Match Operator, this is the value that FortiWeb uses to evaluate a selected target.
Available Target/Selected Target	Use the arrows to add or remove locations in the HTTP request that FortiWeb scans for a signature match, then click the right arrow to move them into the Search In area. The argument's name and value are often included in the request body. In this case, you can't create a rule for the REQUEST_BODY target to detect the argument's name and value. Instead, you need to create rules for ARGS_NAME or/and ARGS_VALUE targets. For example, if you want to block the parameter `count` if its value is `true` (`"count":true`), you can create the following two rules: Rule #1: Regular expression:`count` Selected Target: `ARGS_NAMES` Rule #2: Regular expression:`true` Selected Target: `ARGS_VALUE` Whether a string should be treated as an argument or request body depending on the syntax of the content. For example, the above mentioned `"count":true` is only considered as argument in JSON and XML content types. For other content types, it is just a text string in the request body. See the following examples for more details: Example: ASP .Net version & other multiple server detail leaks Example: Zero-day XSS Example: Local file inclusion fingerprinting via Joomla

Click OK.
Repeat this procedure for each rule that you want to add.
Click OK to save your custom signature.
Go to Web Protection > Known Attacks > Custom Signature.
To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Web Protection Configuration category. For details, see Permissions.
From the Custom Signature Group tab, click Create New to create a new group of custom signatures. Alternatively, to add your custom signature to an existing set, click Edit to add it to that set.
The custom signatures in the same group are in "OR" relationship.
In Name, type a name that can be referenced by other parts of the configuration. The maximum length is 63 characters.
Click OK.
Click Create New to include individual rules in the set.
From the Custom Signature drop-down list, select a custom signature to add to the group.
To view or change information associated with the custom signature, select the Detail link. The Edit Custom Signature dialog appears. You can view and edit the rules. Use the browser Back button to return.
Click OK.
Repeat the previous steps for each individual rule that you want to add to the custom signature set.
Group the custom signature set in a signature rule. For details, see Blocking known attacks .

When the custom signature set is enabled in a signature rule policy, you can add either the group or an individual custom signature rule in the group to an advanced protection custom rule. For details, see Custom Policy.

Example: ASP .Net version & other multiple server detail leaks

Example.com is a cloud hosting provider. Because it must offer whatever services its customers’ web applications require, its servers run a variety of platforms—even old, unpatched versions with known vulnerabilities that have not been configured securely. Unfortunately, these platforms advertise their presence in a variety of ways, identifying weaknesses to potential attackers.

HTTP headers are one way that web server platforms are easily fingerprinted. Example.com wants to remove unnecessary headers that provide server details to clients in order to make it harder for attackers to fingerprint their platforms and craft successful attacks. Specifically, it wants to erase these HTTP response headers:

X-AspNet-Version: 2.0.50727

X-AspNetMvc-Version: 3.0

Server: Microsoft-IIS/7.0

X-Powered-By: ASP.NET

To do this, Example.com writes a custom signature that erases content with 4 meet condition rules, one to match the contents of each header (but not the header’s key), and includes the custom signature in the signature set used by the protection profile:

Direction	Response
Action	Alert & Erase
Severity	Low
Trigger Action	notification-servers1
Meet condition rule 1
Match Operator	Regular expression match
Regular Expression	\bServer:(.*)\b
Selected Target	ARGS_NAMES
Meet condition rule 2
Match Operator	Regular expression match
Regular Expression	\bX-AspNetMvc-Version:(.*)\b
Selected Target	ARGS_NAMES
Meet condition rule 3
Match Operator	Regular expression match
Regular Expression	\bX-AspNet-Version:(.*)\b
Selected Target	ARGS_NAMES
Meet condition rule 4
Match Operator	Regular expression match
Regular Expression	\bX-Powered-By:(.*)\b
Selected Target	ARGS_NAMES

The result is that the client receives HTTP responses with headers such as:

Server: XXXXXXXX

X-Powered-By: XXXXXXXX

X-AspNet-Version: XXXXXXXX

To improve performance, Example.com could use the attack logs generated by these signature matches to notify system administrators to disable version headers on their web servers. As each customer’s web server is reconfigured properly, this would reduce memory and processor power required to rewrite its headers.

Example: Zero-day XSS

Example.com is a cloud hosting provider. Large and with a huge surface area for attacks, it makes a tempting target and continuously sees attackers trying new forms of exploits.

Today, its incident response team discovered a previously unknown XSS attack. The attacker had breached the web applications’ own input sanitization defenses and succeeded in embedding 3 new methods of browser attacks in many forum web pages. Example.com wants to write a signature that matches the new browser attacks, regardless of what method is used to inject them.

All of the example text colored magenta contributes to the success of the attacks, and should be matched when creating a signature.

The first new XSS attack found was:

The above attack works by leveraging a client web browser’s error handling against itself. Without actually naming JavaScript, the attack uses the JavaScript error handling event onError() to execute arbitrary code with the HTML <img> tag. The <img> tag’s source is a non-existent image. This triggers the web browser to load an arbitrary script from the attacker’s command-and-control server. To avoid detection, he attacker has even bought a DNS name that looks like one of example.com’s legitimate servers: www.example.co.

The incident response team has also found two other classes of XSS that evades the forum’s own XSS sanitizers (which only look for injection of <script> and <object> tags). The first one exploits a web browser’s parser by tricking it with additional quotes in an unexpected place:

<img """><script>alert("XSS")</script>">

The second one exploits the nature of all web pages with images and other external files. Other than the web page itself, all images, scripts, styles, media, and objects cause the web browser to make secondary HTTP requests: one for each component of the web page. Here, the <img> tag causes the client’s web browser to make a request that is actually an injection attempt on another website.

The incident response team has written 3 regular expressions to detect each of the above XSS attack classes, as well as similar permutations that use HTML tags other than <img>:

<(.*)src(\s)*=(\s)*[‘’‘”](\s)*(.*)(\s)*[‘’‘”](\s)*onError
<(.*)[‘’‘”][‘’‘”]*(.*)>(\s)*<script>
<(\s)*[^(<script)](\s)*src(\s)*=(\s)*(HTTP|HTTPS|ftp|\\\\|\/\/)(.*)\?

To check for any of the 3 new attacks, the team creates a custom signature with 3 meet condition rules. (Alternatively, the team can create a single meet condition rule that joins the 3 regular expressions by using pipe ( | ) characters between them.)

Direction	Request
Action	Alert & Deny
Severity	High
Trigger Action	notification-servers1
Meet condition rule 1
Match Operator	Regular expression match
Regular Expression	<(.)src(\s)=(\s)[‘’‘”](\s)(.)(\s)[‘’‘”](\s)*onError
Selected Target	REQUEST_BODY
Meet condition rule 2
Match Operator	Regular expression match
Regular Expression	<(.)[‘’‘”][‘’‘”](.)>(\s)<script>
Selected Target	REQUEST_BODY
Meet condition rule 3
Match Operator	Regular expression match
Regular Expression	<(\s)[^(<script)](\s)src(\s)=(\s)(HTTP\|HTTPS\|ftp\|\\\\\|\/\/)(.*)\?
Selected Target	REQUEST_BODY

Attackers can try many techniques to evade detection by signatures. When writing custom attack signatures for FortiWeb, or when sanitizing corrupted content via rewriting, consider that smart attackers:

instead of explicitly injecting JavaScript statements such as document.write();, inject CSS or object HTML that either implicitly uses JavaScript or achieves the same purpose (and therefore will not be caught by sanitizers rejecting JavaScript only syntax)
use alternate encodings such as hexadecimal, Base64 or HTML entities instead of character in the encoding specified in the web page’s charset
follow or break up valid tags with ignored special characters, such as slashes, spaces, tabs, bells, or carriage returns
use characters that are functionally equivalent, such as single quotes ( ’ ) or back ticks ( ‘ ) instead of double quotes ( “” )

These may be functionally ignored or gracefully handled by a web browser or server’s parser, but will allow the attack to slip by your signature if it is not carefully crafted

In the above example, the attacker uses the back tick ( ‘ ) used instead of quotes, avoids the literal mention of javascript:, and does not match a regular expression that requires the exact, unvaried HTML tag <script>. Your regular expression should be flexible enough to account for these cases.

If content has already been corrupted by a successful attack, you can simultaneously sanitize all server responses and notify the response team of specific corrupted URLs. This can help your incident response team to quickly clean the impacted applications and databases. See Example: Sanitizing poisoned HTML.

Example: Local file inclusion fingerprinting via Joomla

Attackers sometimes scout for vulnerabilities in a target before actually executing an attack on it or other, more challenging targets. To look for advance notice of specific attacks that your web servers may soon experience, you might create a honeypot: this server would run the same platform as your production web servers, but contain no valuable data, normally receive no legitimate traffic, and be open to attacks in order to gather data on automated attacks for your forensic analysis.

Let’s say your honeypot, like your production web servers, runs Joomla. In either your web server’s logs, you see requests for URLs such as:

10.0.0.10
-
-
[16/Dec/2011:09:30:49 +0500]
"GET /index.php?option=com_ckforms&controller=../../../../../../../../winnt/system32/cmd.exe?/c+ver HTTP/1.1"
200
"-"
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0a2) Gecko/20111101 Firefox/9.0a2)"

where the long string of repeated ../ characters indicates an attempt at directory traversal: to go above the web server’s usual content directories.

If Joomla does not properly sanitize the input for the controller parameter (highlighted in bold above), it would be able to use LFI. The attacker’s goal is to reach the cmd.exe file, the Microsoft Windows command line, and enter the command ver, which displays the web server’s specific OS version, such as:

Microsoft Windows [Version 6.1.7601]

Since the attacker successfully fingerprinted the specific version of Windows and Joomla, all virtual hosts on that computer would be vulnerable also to any other attacks known to be successful on that platform.

Luckily, this is happening on your honeypot, and not your company’s web servers.

To detect similar attacks, you could write your own attack signature to match and block that and similar directory-traversing requests via controller, as well as to notify you when your production web servers are being targeted by this type of attack:

Direction	Request
Action	Alert & Deny
Severity	High
Trigger Action	notification-servers1
Meet condition rule
Match Operator	Regular expression match
Regular Expression	^/index\.php\?option=com_ckforms\&controller=(\.\.\/)+?
Selected Target	REQUEST_URI

If packet payload retention and logging were enabled, once this custom signature was applied, you could analyze requests to locate targeted files. Armed with this knowledge, you could then apply defenses such as tripwires, strict file permissions, uninstalling unnecessary programs, and sandboxing in order to minimize the likelihood that this attacker would be able to succeed and achieve her objectives.