An analysis of the Web hacking incidents from the first half of 2010 performed by Trustwave’s SpiderLabs Security Research team shows the following trends and findings:

• A steep rise in attacks against the financial vertical market is occurring in 2010, and is currently the no. 3 targeted vertical at 12 percent. This is mainly a result of cybercriminals targeting small to medium businesses’ (SMBs) online banking accounts.
• Corresponding to cybercriminals targeting online bank accounts, the use of Banking Trojans (which results in stolen authentication credentials) made the largest jump for attack methods (Banking Trojans + Stolen Credentials).
• Application downtime, often due to denial of service attacks, is a rising outcome.
• Organizations have not implemented proper Web application logging mechanisms and thus are unable to conduct proper incident response to identify and correct vulnerabilities. This resulted in the no. 1 “unknown” attack category.

WHID Top 10 Risks for 2010

As part of the WHID analysis, here is a current Top 10 listing of the application weaknesses that are actively being exploited (with example attack method mapping in parentheses). Hopefully this data can be used by organizations to re-prioritize their remediation efforts.

Download the full report and Join the live Trustwave Webinar Sept. 16th: Web Hacking Incidents Revealed: Trends, Stats and How to Defend (registration required).

Description: Look up the parameter in the RBL given as parameter. Parameter can be an IPv4 address, or a hostname.

Example:

SecRule REMOTE_ADDR "@rbl sc.surbl.org"

The OWASP ModSecurity CRS includes limited use of the @rbl operator within the optional_rules/modsecurity_crs_42_comments_spam.conf file:

#
# Comment spam is an attack against blogs, guestbooks, wikis and other types of
# interactive web sites that accept and display hyperlinks submitted by
# visitors. The spammers automatically post specially crafted random comments
# which include links that point to the spammer's web site. The links
# artificially increas the site's search engine ranking and may make the site
# more noticable in search results.
#

SecRule IP:PREVIOUS_RBL_CHECK "@eq 1" "phase:1,t:none,pass,nolog,skipAfter:END_RBL_LOOKUP"
 SecRule REMOTE_ADDR "@rbl sbl-xbl.spamhaus.org" "phase:1,t:none,pass,nolog,auditlog,msg:'RBL Match for SPAM Source',tag:'AUTOMATION/MALICIOUS',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.automation_score=+%{tx.warning_anomaly_score},setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.%{rule.id}-AUTOMATION/MALICIOUS-%{matched_var_name}=%{matched_var},setvar:ip.spammer=1,expirevar:ip.spammer=86400,setvar:ip.previous_rbl_check=1,expirevar:ip.previous_rbl_check=86400,skipAfter:END_RBL_CHECK"

 SecAction "phase:1.t:none,nolog,pass,setvar:ip.previous_rbl_check=1,expirevar:ip.previous_rbl_check=86400"
SecMarker END_RBL_LOOKUP

SecRule IP:SPAMMER "@eq 1" "phase:1,t:none,pass,nolog,auditlog,msg:'Request from Known SPAM Source (Previous RBL Match)',tag:'AUTOMATION/MALICIOUS',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.automation_score=+%{tx.warning_anomaly_score},setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.%{rule.id}-AUTOMATION/MALICIOUS-%{matched_var_name}=%{matched_var}"

SecMarker END_RBL_CHECK

The goal of this ruleset is to run an @rbl check once for each IP address and then save the response in a TX variable for 1 day.  This is used to limit the number of @rbl lookups that the web server needs to do as there is a latency hit for executing the DNS queries.

Why use Real-time Blacklist Lookups anyways?   What we are talking about here is IP Reputation.  Has this client been identified as bad by other web sites?  It is sort of like the "No Fly" lists that the Department of Homeland Security makes available to airlines.  It is a method of sharing information about clients so that you can decided if you want to allow this client access to your site at all or perhaps treat them differently (such as with increased logging).  Real-time block lists (RBL) are community-based, central repositories for IP Reputation. RBLs are most commonly used to identify web-based comment spam. If you run a blog or user-forum site, wouldn't you like to know if the current client has already been identified as a spammer?

While @rbl is a useful feature, there is a caution with its usage - it is a severe performance hit and can cause increased latency for clients.  Whereas the @geoLookup operator accessed a local DB, @rbl checks occur in real-time over the network and utilize the DNS infrastructure.  For the same reason that most web admins disable real-time client resolution in logging, running a DNS lookup on each client request can cause severe delays.  

Here are a few recommended tips for using @rbl.

Implement a local caching DNS server like rbldnsd so that your @rbl checks issue DNS queries to the local system first.

Alternatively, you can use ModSecurity to save rbl responses in the IP persistent storage collection.  This is what the CRS modsecurity_crs_42_comment_spam.conf file does.  The persistent data is cached for 1 day.

Make sure that you choose your RBL carefully.  You not only want to ensure that the RBL category is appropriate for your site but also that the accuracy of the list is good.

This excerpt is taken from the updated Reference Manual section of Ivan Ristic's book ModSecurity Handbook.

Transformation functions are used to alter input data before it is used in matching (i.e., operator execution). The input data is never modified, actually—whenever you request a trans- formation function to be used, ModSecurity will create a copy of the data, transform it, and then run the operator against the result.

Note

There are no default transformation functions, as there were in the first generation of ModSecurity (1.x).

In the following example, the request parameter values are converted to lowercase before matching:

SecRule ARGS "xp_cmdshell" "t:lowercase"

Multiple transformation actions can be used in the same rule, forming a transformation pipeline. The transformations will be performed in the order in which they appear in the rule.

In most cases, the order in which transformations are performed is very important. In the following example, a series of transformation functions is performed to counter evasion. Per- forming the transformations in any other order would allow a skillful attacker to evade detection:

SecRule ARGS "(asfunction|javascript|vbscript|data|mocha|livescript):"  

"t:none,t:htmlEntityDecode,t:lowercase,t:removeNulls,t:removeWhitespace"

Warning

It is currently possible to use SecDefaultAction to specify a default list of transfor- mation functions, which will be applied to all rules that follow the SecDefaultAction directive. However, this practice is not recommended, because it means that mistakes are very easy to make. It is recommended that you always specify the transformation functions that are needed by a particular rule, starting the list with t:none (which clears the possibly inherited transformation functions).

The OWASP ModSecurity CRS makes extensive use of transformation functions.  Each rule applies a specific transformation pipeline that was developed from user feedback and testing and aims to avoid false negative issues.  The following example rule is taken from the modsecurity_crs_41_sql_injection.conf file:

SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "bunionb.{1,100}?bselectb" 
 "phase:2,rev:'2.0.8',capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,t:replaceComments,t:compressWhiteSpace,ctl:auditLogParts=+E,pass,nolog,auditlog,msg:'SQL Injection Attack',id:'959047',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"

The goal of this transformation pipeline is to try and counter-act typical evasion attempts that are used by SQL Injection attacks (which we describe more in depth in the following section).

Why are transformation functions so important?  One word - EVASIONS.  We have blogged about the term Impedance Mismatch many times in the past.  The issue is that there are many ways in which an attacker may be able to alter the format of an inbound payload, so that it may not match an input validation filtering scheme, however it is still functionally equivalent code and will be executed by the back-end application.

Example SQL Injection Evasion Techniques:

delete from -- lowercase

DELETE FROM -- upper-case

deLeTe fRoM -- mixed-case

Delete From -- more than 1 space between keywords

DELETEtFROM -- t represents a TAB character

DELETE/* random data */ FROM -- use of SQL Comments

Let's take a look at an example SQL Injection attack payload:

http://localhost/vulnerable_app.php?foo=1'%20UniOn%09(/*blah%20blah%20blah*/SeLeCt%20%20%20%20%20%20%20'1','2',PASSword%20from%20USERS)%20--%20-a

This payload has a number of the same evasion techniques described in the previous section.  Let's take a look at the modsecurity debug log (set to level 9) and see how the transformation pipeline used in CRS rule id 959047 handles the payload:

[31/Aug/2010:11:34:17 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) urlDecodeUni: "1' UniOnt(/*blah blah blah*/SeLeCt '1','2',PASSword from USERS) -- -a"
[31/Aug/2010:11:34:17 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) htmlEntityDecode: "1' UniOnt(/*blah blah blah*/SeLeCt '1','2',PASSword from USERS) -- -a"
[31/Aug/2010:11:34:17 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) lowercase: "1' uniont(/*blah blah blah*/select '1','2',password from users) -- -a"
[31/Aug/2010:11:34:17 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) replaceComments: "1' uniont( select '1','2',password from users) -- -a"
[31/Aug/2010:11:34:17 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) compressWhitespace: "1' union ( select '1','2',password from users) -- -a"
[31/Aug/2010:11:34:17 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][4] Transformation completed in 36 usec.
[31/Aug/2010:11:34:17 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][4] Executing operator "rx" with param "\bunion\b.{1,100}?\bselect\b" against ARGS:foo.
[31/Aug/2010:11:34:17 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] Target value: "1' union ( select '1','2',password from users) -- -a"

As you can see from the debug_log, the ARGS:foo parameter payload data was normalized to remove the evasion techniques before the payload was inspected by the @rx operator.

While transformation pipelines work fairly well at identifying most evasion attacks, they are by no means perfect.  In fact, attackers may abuse the fact that ModSecurity only applies the specified operator only once, at the end of the transformation pipeline.  Here is an example attack payload that indeed evaded previous versions of the CRS which were only inspecting more generic payloads such as REQUEST_URI:

http://localhost/vulnerable_app.php?foo=%2f*&bar=%E2%80%98+UNION+SELECT+*+FROM+user+%26%23x2f*

The evasion trick this payload is attempting is to spread the SQL C-style comment across multiple parameter payloads.  Let's look at how the previous CRS rule would have processed this REQUEST_URI payload and applied the transformation pipeline:

[31/Aug/2010:11:56:15 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) urlDecodeUni: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 UNION SELECT * FROM user /*"
[31/Aug/2010:11:56:15 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) htmlEntityDecode: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 UNION SELECT * FROM user /*"
[31/Aug/2010:11:56:15 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) lowercase: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 union select * from user /*"
[31/Aug/2010:11:56:15 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) replaceComments: "/vulnerable_app.php?foo= "
[31/Aug/2010:11:56:15 --0400] [localhost/sid#10080d708][rid#1025d2aa0][/vulnerable_app.php][9] T (0) compressWhitespace: "/vulnerable_app.php?foo= "

Opps... As you can see, once the replaceComments transformation function is applied, it effectively removes the SQLi payload before the operator is applied.  This is a perfect example of Impedance Mismatch, were the WAF is normalizing data in a different way as the target application.

So, how do we combat this evasion issue?

By default, operators are only applied once after the entire transformation pipeline is completed.  This is a sound approach for normal everyday use as it strikes a balance between detecting attacks and not adversely affecting performance.  Keep in mind that there is a latency cost each time that ModSecurity has to apply an operator to data.  

There is a seldom used action called multiMatch and its purpose is to change when operators are applied to data.  

With multiMatch, the operator is actually applied to data each time that the individual transformation function alters the data.  With this approach, it is now possible to detect the previous SQL Injection bypass attempt.  Here is how the multiMatch operator execution looks now:

[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Executing operator "rx" with param "\bunion\b.{1,100}?\bselect\b" against REQUEST_URI_RAW.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][9] Target value: "/vulnerable_app.php?foo=%2f*&bar=%E2%80%98+UNION+SELECT+*+FROM+user+%26%23x2f*"
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Operator completed in 1 usec.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][9] T (0) urlDecodeUni: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 UNION SELECT * FROM user /*"
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Transformation completed in 42 usec.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Executing operator "rx" with param "\bunion\b.{1,100}?\bselect\b" against REQUEST_URI_RAW.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][9] Target value: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 UNION SELECT * FROM user /*"
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Operator completed in 1 usec.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][9] T (0) htmlEntityDecode: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 UNION SELECT * FROM user /*"
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Transformation completed in 78 usec.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Executing operator "rx" with param "\bunion\b.{1,100}?\bselect\b" against REQUEST_URI_RAW.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][9] Target value: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 UNION SELECT * FROM user /*"[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Operator completed in 0 us
ec.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][9] T (0) lowercase: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 union select * from user /*"
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Transformation completed in 109 usec.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][4] Executing operator "rx" with param "\bunion\b.{1,100}?\bselect\b" against REQUEST_URI_RAW.
[31/Aug/2010:16:22:45 --0400] [localhost/sid#10080d708][rid#1040020a0][/vulnerable_app.php][9] Target value: "/vulnerable_app.php?foo=/*&bar=xe2x80x98 union select * from user /*"

In order to balance out the latency hit and its chance for higher false positives, we have implemented use of the multiMatch action into the OWASP ModSecurity Core Rule Set by only conditionally using it if the Admin configures the PARANOID_MODE variable in the modsecurity_crs_10_config.conf file.  When this is set, many of the rules will then inspect more generic variables and use the multiMatch action.  As indicated by the name, PARANOID_MODE is mainly meant for people who want to get more aggressive with detection and have a higher tolerance for false positives.

Transformation Function Tips

Here are a few recommended tips for using transformation functions.

Start with t:none

Due to the fact that transformation functions pipelines are cumulative, it is possible that you could unintentionally inherit transformation functions from a previous SecDefaultAction.  It is therefore good practice to start each transformation function pipeline with "t:none" as this will clear out any existing ones.

Choose the right transformations

There is no "one size fits all" magic transformation function pipeline.  You need to analyze what type of attack you are targeting and then identify the methods in which attackers may try evade detection.  For instance, the transformation pipelines for detecting Cross-site Scripting (XSS) is much different then what you would use for SQL Injection.

Beware of performance

The larger the payload is, the longer it will take to complete the transformation pipeline.  This is not that big of a concern for inbound request data as they are generally small in size.  Where you can run into higher latency hits is when you are attempting to inspect outbound data (RESPONSE_BODY variable).  It is for this reason that you should try to limit the use of transformations when inspecting RESPONSE_BODY and instead specify mixed-case within your regular expression.

While this is certainly exciting news and will help to further promote ModSecurity and the Core Rule Set, there is still much work left to be done on the project.  We will be expanding the CRS documentation, re-organizing the rules to more accurately categorize the quality of the rules (with relation to false positive potential), as well as, cross-referencing rules with the OWASP AppSensor project.

Keep your eyes open as we are just getting started with the CRS.

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.

This week's feature is on the use of the @validateByteRange operator.

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.

ASCII Byte Range Chart

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).

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

%u3008scr%u0131pt%u3009%u212fval(%uFF07al%u212Frt(%22XSS%22)%u02C8)%u2329/scr%u0131pt%u2A

〈scrıpt〉ℯval(＇alℯrt(”XSS”)ˈ)〈/scrıpt〉

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

eval('alert("XSS")')

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 -

Message: Found 3 byte(s) in REQUEST_URI outside range: 32-126. [file "/usr/local/apache/conf/modsec_current/base_rules/modsecurity_crs_20_protocol_violations.conf"] [line "251"] [id "960018"] [rev "2.0.6"] [msg "Invalid character in request"] [severity "WARNING"] [tag "PROTOCOL_VIOLATION/EVASION"] [tag "WASCTC/WASC-28"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE3"] [tag "PCI/6.5.2"] [tag "http://i-technica.com/whitestuff/asciichart.html"]

Here are are few things that we having going on right now:

• Website Updates - We are in the process of refreshing the website to reflect its new home within SpiderLabs but also clean out any dusty content and replace it with fresh new material. Look for phases of changes over the next several weeks.
• Recruiting - We are actively looking to hire full-time developers for ModSecurity. Those developers will be part of the SpiderLabs research team. If you or anyone you know is interested, please let us know.
• Internal Development Team - We have formed a team of people within SpiderLabs that will be actively contributing to ModSecurity. This team is comprised of many very experienced individuals including many OWASP, Black Hat and DEFCON researchers/speakers in the area of web application security. This team is excited to breath new life into this project.
• End User Survey - In the next few weeks, we will be sending out a survey to the ModSecurity mailing lists to ask for feedback on features to include in the next release.
• Blog Updates - Each week we'll be writing about an Advance Feature in ModSecurity that the community and end users may not be aware of. The idea is here is that with increased usage of these advanced, we'll get better feedback on how to improve the product.
• Twitter - We have just linked this blog to the ModSecurity Twitter account. Follow us!

And so, it is with mixed feelings that I also announce that I am stepping down from the project. I have enjoyed working on ModSecurity with Breach for the past 3 1/2 years, but it is time for me to move on to another exciting project (more on that later). While I may be stepping down as a leader, I am not leaving, just changing roles. I plan to stay an active member of the community and to contribute where I can. I expect to see a lot of innovation from ModSecurity in the near future and I look forward to see where ModSecurity will go with all its new resources.

Cheers to ModSecurity's new home in Spider Labs and to a successful future!

P.S. -- I'll be around at Black Hat/DEFCON next week in Vegas if anyone wants to hook up.

We will be hosting a ModSecurity happy hour during Black Hat USA. It is open to anyone who contributes, uses or wants to learn more about the project. You'll also get a chance to meet the members of Trustwave's SpiderLabs team that will be supporting the ModSecurity project moving forward. 

• What: ModSecurity Happy Hour
• Where: munchbar @ Caesar's Palace LV (next to Sports Bar & Pure Night Club)
• When: Wednesday, July 28th, 2010 - 4:00-6:00 PM

There will be appetizers, drinks, and Nintendo Wii action!

Look forward to meeting you next week!

Senior Vice President, SpiderLabs

Trustwave

The article's example is roughly this:

1) Take an attack string: <script>alert(1)</script>
2) Base64 encode it to: PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
3) Now add an illegal character: P.HNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
4) Notice that most decoders will not work, but PHP's will (act surprised)

PHP will apparently just skip the invalid characters (RFC-2045) and so something like this (article's example, not mine) will of course fail:

SecRule ARGS:b64 "alert" "t:base64decode,log,deny,status:501"

The Base64 decoder in ModSecurity is based off the RFC-4648 implementation of Base64. There are many other variants. Well, as it turns out it is important to know a bit more about your platform on which your app is based and the above trivial rule is just not going to cut it.

For PHP and possibly others you will need to go a little further and validate the character set first using a positive rule. Something like this is going to be required for the article's example:

SecRule ARGS:b64 "!^[A-Za-z0-9+/]*={0,2}$" 
  "phase:2,t:none,log,deny,status:403,msg:'Invalid Base64 Encoding'"
SecRule ARGS:b64 "alert" 
  "phase:2,t:none,t:base64decode,log,deny,status:403,msg:'Badness in b64'"

And now you get some better coverage:

# For PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
ModSecurity: Access denied with code 403 (phase 2). Pattern match "alert" 
at ARGS:b64. [file "test.conf"] [line "3"] [msg "Badness in b64"] 
[hostname "myhost"] [uri "/foo"] [unique_id "S8-4-X8AAQEAACGOJcoAAAAA"]

# For P.HNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
ModSecurity: Access denied with code 403 (phase 2). Match of 
"rx ^[A-Za-z0-9\\+/]*={0,2}$" against "ARGS:b64" required. 
[file "test.conf"] [line "1"] [msg "Invalid Base64 Encoding"] 
[hostname "myhost"] [uri "/foo"] [unique_id "S8-5BX8AAQEAACJSKBYAAA@i"]

Though I am picking on PHP a bit here, this may be true in many other areas if you have decoders/parsers that accept out-of-the-norm data. You really do have to know your apps to write targeted rules like the example in this article. You cannot detect encodings like Base64 generically and I would not expect to find such a rule as this in a generic rule set such as ModSecurity's CRS.

Edited: Added details on which RFCs I was referring to and removed blame on PHP after further investigation as it really is just an issue with multiple variants of base64.