ModSecurity Blog

We are starting a new blog post series here on the ModSecurity site called "Advanced Feature of the Week" where we will be highlighting many of ModSecurity's really cool capabilities. These are the features that seldom used or fully understood by the average ModSecurity user however can provide detection of sophisticated attacks if used properly. It is our goal with these blog posts to help shed light on these unique features and to provide some real-world, in-the-trenches gotchas for successful usage of these features.

This blog post series will have the following major topic sections -

1) ModSecurity Reference Manual Information

Provide reference manual data.

2) Use Within the OWASP Core Rule Set (CRS)

Outline if/when/how the CRS is utilizing this feature.

3) So What?

Will provide some context as to why you as a user should even care about this capability. What advanced attack/vulnerability is this attempting to catch.

Reference Manual

validateByteRange

Description: Validates the byte range used in the variable falls into the specified range.

Example:

SecRule ARGS:text "@validateByteRange 10, 13, 32-126"

Note

You can force requests to consist only of bytes from a certain byte range. This can be useful to avoid stack overflow attacks (since they usually contain "random" binary content). Default range values are 0 and 255, i.e. all byte values are allowed. This directive does not check byte range in a POST payload when multipart/form-data encoding (file upload) is used. Doing so would prevent binary files from being uploaded. However, after the parameters are extracted from such request they are checked for a valid range.

validateByteRange is similar to the ModSecurity 1.X SecFilterForceByteRange Directive however since it works in a rule context, it has the following differences:

You can specify a different range for different variables.

It has an "event" context (id, msg....)

It is executed in the flow of rules rather than being a built in pre-check.

OWASP ModSecurity CRS

Use of @validateByteRange in the OWASP ModSecurity CRS (from the end of the modsecurity_crs_20_protocol_violations.conf file) -

#
# Restrict type of characters sent
# NOTE In order to be broad and support localized applications this rule
# only validates that NULL Is not used.
#
# The strict policy version also validates that protocol and application
# generated fields are limited to printable ASCII.
#
# -=[ Rule Logic ]=-
# This rule uses the @validateByteRange operator to look for Nul Bytes.
# If you set Paranoid Mode - it will check if your application use the range 32-126 for parameters.
#
# -=[ References ]=-
# http://i-technica.com/whitestuff/asciichart.html
#
SecRule ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "@validateByteRange 1-255" \
"phase:2,rev:'2.0.8',pass,nolog,auditlog,msg:'Invalid character in request',id:'960901',tag:'PROTOCOL_VIOLATION/EVASION',tag:'WASCTC/WASC-28',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE3',tag:'PCI/6.5.2',severity:'4',t:none,t:urlDecodeUni,setvar:'tx.msg=%{rule.msg}',tag:'http://i-technica.com/whitestuff/asciichart.html',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.protocol_violation_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-PROTOCOL_VIOLATION/EVASION-%{matched_var_name}=%{matched_var}"
SecRule TX:PARANOID_MODE "@eq 1" "chain,phase:2,rev:'2.0.8',pass,nolog,auditlog,msg:'Invalid character in request',id:'960018',tag:'PROTOCOL_VIOLATION/EVASION',tag:'WASCTC/WASC-28',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE3',tag:'PCI/6.5.2',severity:'4',t:none,t:urlDecodeUni,tag:'http://i-technica.com/whitestuff/asciichart.html'"
SecRule REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer|TX:HPP_DATA \
"@validateByteRange 32-126" \
"t:none,t:urlDecodeUni,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.protocol_violation_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-PROTOCOL_VIOLATION/EVASION-%{matched_var_name}=%{matched_var}"

As you can see, the CRS is, by default, only restricting the existence of Nul Bytes. If the user initiates the PARANOID_MODE variable, however, the CRS will restrict down the allowed byte range to only allow 32-126 which are the normal printable characters for US ASCII (space character through the tilde character).

So What?

Why would you need to use @validateByteRange to restrict anything more than Nul Bytes? The short answer is because of the potential of Impedance Mismatches between a security inspection system (IDS, IPS or WAF) and the target web application. The process of data normalization or canonicalization and how the destination web application handles best-fit mappings can cause issues with bypasses. Here is a great recent references for this issue.

Lost In Translation - Giorgia Maone (of the NoScript FF extension fame) outlines how ASP classic web apps attempt to do best-fit mappings of non-ASCII Unicode characters. One example issue is the following XSS payload

ASP classic, however, will try and do best-fit mapping and actually will normalize the data into working JS code -

<script>eval('alert("XSS")')</script>

The issue that this raises, for security inspection, is that the inbound payload will most likely not match most XSS regular expression payloads however the application itself will modify it into executable code!

So, this brings us to today's advanced ModSecurity feature - @validateByteRange. By restricting the allowed character byte ranges, you can help to identify when unexpected character code points are used. If the payload above is sent, you should receive an alert message similar to the following -

I was searching on Google in utf8 for something with a Pound sign and clicked on my own website, this triggered then ModSec, as the referrer contained a utf8 encoded Pound sign. I couldnt figure a way out of this and switched this rule to warning only.

I still feel that this rule is a sensible thing to have enabled, but how do I make it utf8 aware?

@Jinxy - The @validateByteRange operator tells ModSecurity *how* to process the payload data. In this case, it is restricting which byte characters are allowed within your site. As you have stated however, if your site requires support other languages (using UTF8 encoding) then you will need to keep this setting pretty wide.

@Thomas - In general checking the Referer request header is prone to false positives as you really have no control over what other people are doing on their sites and this ends up being a "guilt by association" problem when you click on links to a site. What I would recommend is that you update the CRS with a new rule in the modsecurity_crs_48_local_exceptions.conf file where you can evaluate the matched rule and if it was found in the Referer variable then just cancel the TX match. Take a look at the 48 file for some examples.