How To Remove False Positives in Sophos UTM's Web Application Firewall

Sophos UTM's Web Application Firewall (WAF) may detect vulnerabilities in your web application that are not necessarily a problem. This article provides tips on how to investigate and remove these false positives, with the least impact on overall security.

Background

Web application firewalls apply a set of rules to match known web application vulnerabilities. In theory these rules only find a match when something unusual is happening.

Your web application should be written in such a manner that it will not generate, request or receive instructions that violate these rules. In practice however, it is extremely likely that your WAF's rules will flag certain behavior in your web application and display false 'attacks' (false positives).

When you deploy your WAF, you initially have the option to Monitor and not Block. Enabling the Monitor mode shows you the many attacks that the WAF would block, once the full blocking mode is enabled.

While blocking all these threats would seem like a good and safe idea, it could have serious impacts on your web application, to the point of breaking it completely.

Identifying the Attacks

Fortunately, all of the attacks are logged. Some attacks include a lot of information in the log, and others do not. An example of this is the event below. This is from the log /var/log/reverseproxy.log

2016:01:14-09:32:55 sutm01-2 reverseproxy:

[Thu Jan 14 09:32:55.157927 2016] [security2:error] [pid 5665:tid 4080061296]  [ client ipaddress] ModSecurity: Warning. Pattern match "(/\\\\*!?|\\\\*/|[';]--|--[\\\\s\\\\r\\\\n\\\\v\\\\f]|(?:--[^-]*?-)|([^\\\\-&])#.*?[\\\\s\\\\r\\\\n\\\\v\\\\f]|;?\\\\x00)" at REQUEST_COOKIES:JSESSIONID. [file "/usr/apache/conf/waf/modsecurity_crs_sql_injection_attacks.conf"] [line "49"] [id "981231"] [rev "2"] [msg "SQL Comment Sequence Detected."] [data "Matched Data: --WUj26od6_zdZ0vvgnu06rGccvvGdI0b5Yg- found within REQUEST_COOKIES:JSESSIONID: saA_BXlXRUX--WUj26od6_zdZ0vvgnu06rGccvvGdI0b5Yg-RQhN!167446550"] [severity "CRITICAL"] [ver "OWASP_CRS/2.2.7"] [maturity "8"] [accuracy "8"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] [hostname "www.onlinestore.co.za"] [uri "/store/cat/Food/Food/_/N-1z13sk4"] [unique_id "VpdPJqwQGQoAABYhMDEAAADP"] At first this looks ridiculously complicated. But once you split the fields (mostly delimited by [ ]) and put them in the right order, it is much easier to understand. Let's step through the components of the event:

Source: [ client 165.255.71.174]

Destination: [hostname "www.onlinestore.co.za"] [uri "/store/cat/Food/Food/_/N-1z13sk4"]

Evidence: Pattern match "(/\\\\*!?|\\\\*/|[';]--|--[\\\\s\\\\r\\\\n\\\\v\\\\f]|(?:--[^-]*?-)|([^\\\\-&])#.*?[\\\\s\\\\r\\\\n\\\\v\\\\f]|;?\\\\x00)" at REQUEST_COOKIES:JSESSIONID.

[data "Matched Data: --WUj26od6_zdZ0vvgnu06rGccvvGdI0b5Yg-

found within

REQUEST_COOKIES:JSESSIONID: saA_BXlXRUX--WUj26od6_zdZ0vvgnu06rGccvvGdI0b5Yg-RQhN!167446550"]

Information about the vulnerability: [msg "SQL Comment Sequence Detected."][severity "CRITICAL"][ver "OWASP_CRS/2.2.7"][maturity "8"][accuracy "8"]

[tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"]

Local Database used: [file "/usr/apache/conf/waf/modsecurity_crs_sql_injection_attacks.conf"] [line "49"]  [id "981231"] [rev "2"]

This particular log entry tells us quite a lot about the vulnerability. The most important field here is the ID, "981231". This is the rule that has detected the threat, and the rule that will need to be skipped if indeed this is a false positive.

The msg is a brief description of what the vulnerability is. The maturity and accuracy speak of how successful or strong the detection method is. A low maturity and accuracy would lead to many false positives or incorrect detections.

The version and tag fields give you additional information about the detected vulnerability. One particularly interesting note here is the PCI/6.5.2 tag. This indicates a Payment Card Industry compliance requirement, so pretty serious stuff.

Investigating Sophos UTM's WAF Definitions

Sophos UTM uses the OWASP (The Open Web Application Security Project) for its web application firewall. You can find more information about the project here: https://www.owasp.org/

The vulnerabilities are stored local on the UTM in configuration files. The actual path to them is /var/storage/chroot-reverseproxy/usr/apache/conf/waf.

The files are split between the different attack types such as SQL injection, XSS Cross site scripting. and so on. You can open these files and have a look at them and sometimes they contain more details about the vulnerability and sample payloads.

In the case above, the file is shown in the log: /usr/apache/conf/waf/modsecurity_crs_sql_injection_attacks.conf. Opening the file shows the following example payloads:

# Example Payloads Detected: # ------------------------- # OR 1# # DROP sampletable;-- # admin'-- # DROP/*comment*/sampletable # DR/**/OP/*bypass blacklisting*/sampletable # SELECT/*avoid-spaces*/password/**/FROM/**/Members # SELECT /*!32302 1/0, */ 1 FROM tablename # ‘ or 1=1# # ‘ or 1=1-- - # ‘ or 1=1/* # ' or 1=1;\x00 # 1='1' or-- - # ' /*!50000or*/1='1 # ' /*!or*/1='1 # 0/**/union/*!50000select*/table_name`foo`/**/ # -------------------------

So now that we know what the rule is looking for, lets examine the evidence of the detected vulnerability.

[data "Matched Data: --WUj26od6_zdZ0vvgnu06rGccvvGdI0b5Yg- found within REQUEST_COOKIES:JSESSIONID: saA_BXlXRUX--WUj26od6_zdZ0vvgnu06rGccvvGdI0b5Yg-RQhN!167446550"]

In this case, the alert was triggered by the -- characters (two dashes) found in the cookie data of the web request.

Now we know how the vulnerability was detected, the real question is whether it a threat, or normal behavior of the web application. This is normally where you take the information to the application team or application vendor, and ask them to investigate.

In this case, it was determined that the application has the potential to use special characters such as - @ and ! in generating cookies. This means that it is likely they were not injected from an external source, and as such it was a false positive.

Removing the False Positive

Unless you remediate the issue, you cannot switch the WAF mode from Monitor to Block as it would start dropping packets, or at worst, break the application.

Option 1: Fix the Web Application Hopefully the application team or vendor can tweak their app to avoid the behavior that is matching the WAF vulnerability definition. This is the ideal and preferred method as your application would work correctly without triggering alerts on the UTM, or on client side security devices. In the real world however, the web application team or vendor might be slow moving, or they might simply refuse to fix it.

Option 2: Configure an Exception on the Web Application Firewall Fortunately, you can configure your WAF to ignore this specific vulnerability for this particular site. You need to be a specific as possible since you are now willingly and knowingly reducing the protection potential of the WAF. I would also make sure I run this past some sort of governance or risk assessment committee.

Adding Exceptions in Sophos UTM's Web Application Firewall

Rather than creating an exception that excludes the entire category of vulnerabilities, you specify the individual rule (by id) that you want to exclude. This is applied to the individual firewall profile. You must therefore ensure that only the relevant virtual web server(s) has this policy specified.

1. Retrieve the ID from the log file
2. On the UTM, go to Webserver Protection | Web Application Firewall | Firewall Profiles
3. Edit the relevant policy for your Web Application.
4. In Skip Filter Rules click +
5. Add the ID and click Apply
6. Click Save

If you monitor your log, you should no longer see any detection for that specific event.

Summary

Tuning your Web Application Firewall can be a detailed and time consuming process that often requires extensive interaction with the application team or vendor.

Many of the false positives you encounter will share similarities, but each needs to be treated on its own merits. Being too liberal with WAF exclusion will leave you vulnerable, but being too restrictive may break or impact the application.

By understanding the process of identifying and remediating these false positives in the WAF, you can achieve the desired balance between security and usability.