Issue with ResourceSpace app and mod_security

Question

I have a project (its an old project its actually only used as archive as we moved on from this app) with ResourceSpace, that sometimes needs to be accessed to download some images.

We have this issue now where users are unable to download as we're getting the following error:

[Mon Feb 14 13:30:15.118594 2022] [:error] [pid 3078:tid 140588028520192] [client 12.34.56.78:38860] [client 12.34.56.78] ModSecurity: Warning. Pattern match "(?i)(?:;|\\{|\\||\\|\\||&|&&|\\n|\\r|`)\\s[\\(,@\\'\"\\s] (?:[\\w'\"\\./]+/|[\\\\'\"\\^]\\w[\\\\'\"\\^] :.\\\\|[\\^\\.\\w '\"/\\\\] \\\\)?[\"\\^](?:s[\"\\^] (?:y[\"\\^]s[\"\\^] (?:t[\"\\^]e[\"\\^] m[\"\\^](?:p[\"\\^] r[\"\\^]o[\"\\^] p[\"\\^]*e ..." at ARGS:url. [file "/etc/httpd/modsecurity.d/activated_rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf"] [line "294"] [id "932115"] [msg "Remote Command Execution: Windows Command Injection"] [data "Matched Data: &sort found within ARGS:url: https://jlam.com/rs/pages/download_progress.php?ref=18275&search=%21collection1887494+&order_by=date&offset=0&restypes=&starsearch=&archive=&per_page=120&default_sort_direction=DESC&sort=DESC&context=Root&k=&curpos=&size=&ext=jpg"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.0"] [tag "application-multi"] [tag "language-shell"] [tag "platform-windows"] [tag "attack-rce"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/152/248/88"] [tag "PCI/6.5.2"] [hostname "jlam.com"] [uri "/rs/pages/terms.php"] [unique_id "YgpZZ1rt9JAgpUSzT3i4UwAAAAc"], referer: https://jlam.com/rs/pages/view.php?search=%21collection1887494+&k=&modal=&display=thumbs&order_by=date&offset=0&per_page=120&archive=&sort=DESC&restypes=&recentdaylimit=&foredit=&noreload=true&access=&ref=18275

[Mon Feb 14 13:30:15.127329 2022] [:error] [pid 3078:tid 140588028520192] [client 12.34.56.78:38860] [client 12.34.56.78] ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. [file "/etc/httpd/modsecurity.d/activated_rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "93"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "jlam.com"] [uri "/rs/pages/terms.php"] [unique_id "YgpZZ1rt9JAgpUSzT3i4UwAAAAc"], referer: https://jlam.com/rs/pages/view.php?search=%21collection1887494+&k=&modal=&display=thumbs&order_by=date&offset=0&per_page=120&archive=&sort=DESC&restypes=&recentdaylimit=&foredit=&noreload=true&access=&ref=18275

A colleague posted about this on the "Google Groups" as that is the only "forum" they have, but we've had zero replies. I'm unsure about if this is a false positive, or if there is actually something wrong that should be considered? Thank you.

Answer 1

Core Rule Set Developer on Duty here. To confirm: when a user takes a legitimate action (making a download, as you mentioned) then that is the error log entry that appears? And the URL in your error message:

https://jlam.com/rs/pages/download_progress.php?ref=18275

looks legitimate? If so, then your intuition is correct: that is indeed a false positive. Core Rule Set rule 932115 is matching in error.

False positives need to be tuned away to make a given web application fully usable through a WAF. We've written extensively about how to do this in our official documentation, which you can find here: https://coreruleset.org/docs/configuring/false_positives_tuning/

Let's look at the exact issue from your example:

[data "Matched Data: &sort found within ARGS:url: https://jlam.com/rs/...&sort=DESC...

Rule 932115 looks for Windows commands, one of which is sort , hence why this rule is matching.

If you're happy that this is indeed a false positive and that the use of sort here is legitimate (it looks innocent, in context) then you could try applying a rule exclusion like the following:

# CRS Rule Exclusion: 932115 - Remote Command Execution: Windows Command
#                              Injection
#
# Prevent "sort=DESC" from setting off this rule when it appears in the URL
# argument.
SecRule REQUEST_URI "@beginsWith /rs/pages/terms.php" \
    "id:1000,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleRemoveTargetById=932115;ARGS:url"

This rule exclusion will exclude the argument url from rule 932115 for the location beginning /rs/pages/terms.php only. If this false positive also appears at other locations then you'll need to take that into account, but, based on the error log you provided, this rule exclusion (RE) should do the trick.