Owasp-modsecurity-crs: Problem with exclusion rules and ruleRemoveTargetByTag

[j0k2r]

Hi guys,

I use OWASP CRS to protect a WordPress application, and I noticed some suspicious behavor (or I misunderstand how exclusion rules work).

For example, the request:

POST /wp-login.php HTTP/1.1
Accept: '*/*'
Content-Length: '124'
Content-Type: application/x-www-form-urlencoded
Host: example.fr
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36

log=abc&redirect_to=https%3A%2F%2Fexample.fr%2Fwp-admin%2F&wp-submit=log+In&testcookie=1&rememberme=forever&pwd=abc%21%40%23

is blocked by the rule 942100, caused by pwd=abc%21%40%23:

[155955490319.192434] [/wp-login.php] [9] Target value: "abc!@#" (Variable: ARGS:pwd)
[155955490319.192434] [/wp-login.php] [4] detected SQLi using libinjection with fingerprint 'novc' at: 'abc!@#'
[155955490319.192434] [/wp-login.php] [7] Added DetectSQLi match TX.0: novc
[155955490319.192434] [/wp-login.php] [9] Matched vars updated.
[155955490319.192434] [/wp-login.php] [4] Running [independent] (non-disruptive) action: setvar
[155955490319.192434] [/wp-login.php] [8] Saving variable: TX:anomaly_score_pl1 with value: 5
[155955490319.192434] [/wp-login.php] [4] Running [independent] (non-disruptive) action: setvar
[155955490319.192434] [/wp-login.php] [8] Saving variable: TX:sql_injection_score with value: 5
[155955490319.192434] [/wp-login.php] [4] Running [independent] (non-disruptive) action: setvar
[155955490319.192434] [/wp-login.php] [8] Saving variable: TX:msg with value: SQL Injection Attack Detected via libinjection
[155955490319.192434] [/wp-login.php] [4] Running [independent] (non-disruptive) action: setvar
[155955490319.192434] [/wp-login.php] [8] Saving variable: TX:942100-OWASP_CRS/WEB_ATTACK/SQL_INJECTION-ARGS:pwd with value: abc!@#

But since I enabled WordPress exclusion rules, this should not be trigggered (exclusion rule 9002100):

[155955490319.192434] [/wp-login.php] [8] Saving variable: TX:crs_exclusions_wordpress with value: 1

The exclusion rule (9002100) "ctl:ruleRemoveTargetByTag=CRS;ARGS:pwd" , should prevent 942100 to be trigggered.

PS: When I explicitly set "CRS" tag in rule 942100 (tag:'CRS'), it works like charm.

Environment

Modsecurity V3/master c7fe50e
CRS version v3.1.0

Confirmation

[X] I have removed any personal data (email addresses, IP addresses,
passwords, domain names) from any logs posted.

Seems to be related to: #1419

[theMiddleBlue]

Hi @j0k2r

thanks for reporting it. I can confirm that it's related to https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1419. A few days ago, it was merged a fix for this problem on the latest v3/master. Can you do some tests with the latest commit (c7fe50e)?

If you have configured the SecEngine to DetectionOnly, please take a look at this too before using the latest v3 https://github.com/SpiderLabs/ModSecurity/issues/1960. Unfortunately, v3 execute a disruptive action even if SecEngine is DetectionOnly. There's a PR that fixes it, but it's not merged yet: https://github.com/SpiderLabs/ModSecurity/pull/2032

I'm going to close this. Anyway, it would be helpful for all v3 users if you can share here your test related to this issue.

Thanks!

[j0k2r]

Hi,

I use the latest commit (c7fe50e) with a python binding to test the rules so there no disruptive action, it only tests transactions and return the log.

Even when I try with the SpiderLabs/ModSecurity#2032 patch, I have the same problem.

[theMiddleBlue]

Even when I try with the SpiderLabs/ModSecurity#2032 patch, I have the same problem.

yes, this patch https://github.com/SpiderLabs/ModSecurity/pull/2032 fixes only the problem described here https://github.com/SpiderLabs/ModSecurity/issues/1960.

Uhm sorry: I missed this:

PS: When I explicitly set "CRS" tag in rule 942100 (tag:'CRS'), it works like charm.

I've done some test, and you're right. I can confirm that this is a different bug on v3... 😞
My test:

SecRule ARGS:foo "@rx ^bar$" "id:999,\
    phase:1,\
    pass,\
    log,\
    msg:'arg foo contains bar, removing tag CRS',\
    ctl:ruleRemoveTargetByTag=CRS;ARGS:z"

SecRule ARGS:z "@rx ^xxx$" "id:1000,\
    phase:1,\
    block,\
    log,\
    msg:'arg z contains xxx',\
    tag:'OWASP_CRS/WEB_ATTACK/TEST'"

the request curl -v 'http://localhost/?foo=bar&z=xxx' is blocked anyway. Just by adding tag:'CRS' on the rule 1000 it works as expected...

Testing it on v2, it works by matching CRS inside the tag string (as expected):

[Mon Jun 03 13:22:03.494227 2019] [:error] [pid 77:tid 139980258780928] [client 127.0.0.1:35796] [client 127.0.0.1] ModSecurity: Warning. Pattern match "^bar$" at ARGS:foo. [file "/etc/apache2/modsecurity.d/modsecurity.conf"] [line "234"] [id "999"] [msg "arg foo contains bar, removing tag CRS"] [hostname "localhost"] [uri "/"] [unique_id "XPUe@1Vic4UT1IQXSsNGawAAAEA"]

I'm going to open an issue to ModSecurity and reopen this for keep track of this bug.

[theMiddleBlue]

Done: https://github.com/SpiderLabs/ModSecurity/issues/2109
unfortunately, this makes all CRS3 exclusion rule set incompatible with the current modsecurity v3/master.

[dune73]

Adding it to tonight's agenda.

[dune73]

We decided to replace all rule exclusions that work with tag CRS with a rule exclusion by id (910000-999999), which will have the same effect, but works on all ModSec versions.
@theMiddleBlue was kind enough to volunteer to create said PR.

[theMiddleBlue]

Hi @j0k2r

it would be helpful if you could do some test using this PR: https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/1445

thank you for your support!

[j0k2r]

Hi @theMiddleBlue,

Same problem, it works when I explicitly specify the target rule:

ctl:ruleRemoveTargetById=942100;ARGS:pwd

But not with the range ID:

ctl:ruleRemoveTargetById=910000-999999;ARGS:pwd

[j0k2r]

But not with the range ID:
ctl:ruleRemoveTargetById=910000-999999;ARGS:pwd

Can you confirm that @theMiddleBlue ?

[airween]

Did you got any error message, eg:
Not able to convert '910000-999999' into a number?

[j0k2r]

Did you got any error message

No, the rules are parsed correctly

[155964061981.931234] [/wp-login.php] [4] (Rule: 9002100) Executing operator "EndsWith" with param "/wp-login.php" against REQUEST_FILENAME.
[155964061981.931234] [/wp-login.php] [9] Target value: "/wp-login.php" (Variable: REQUEST_FILENAME)
[155964061981.931234] [/wp-login.php] [9] Matched vars updated.
[155964061981.931234] [/wp-login.php] [4] Rule returned 1.
[155964061981.931234] [/wp-login.php] [9] Running action: log
[155964061981.931234] [/wp-login.php] [9] Saving transaction to logs
[155964061981.931234] [/wp-login.php] [9] Running action: auditlog
[155964061981.931234] [/wp-login.php] [9] Running action: nolog
[155964061981.931234] [/wp-login.php] [9] Running action: ctl
[155964061981.931234] [/wp-login.php] [4] Not running disruptive action: pass. SecRuleEngine is not On.

[...]

[155964037689.889786] [/wp-login.php] [9] Target value: "abc!@#" (Variable: ARGS:pwd)
[155964037689.889786] [/wp-login.php] [4] detected SQLi using libinjection with fingerprint 'novc' at: 'abc!@#'
[155964037689.889786] [/wp-login.php] [7] Added DetectSQLi match TX.0: novc
[155964037689.889786] [/wp-login.php] [9] Matched vars updated.
[155964037689.889786] [/wp-login.php] [4] Running [independent] (non-disruptive) action: setvar
[155964037689.889786] [/wp-login.php] [8] Saving variable: TX:anomaly_score_pl1 with value: 5
[155964037689.889786] [/wp-login.php] [4] Running [independent] (non-disruptive) action: setvar
[155964037689.889786] [/wp-login.php] [8] Saving variable: TX:sql_injection_score with value: 5
[155964037689.889786] [/wp-login.php] [4] Running [independent] (non-disruptive) action: setvar
[155964037689.889786] [/wp-login.php] [8] Saving variable: TX:msg with value: SQL Injection Attack Detected via libinjection
[155964037689.889786] [/wp-login.php] [4] Running [independent] (non-disruptive) action: setvar
[155964037689.889786] [/wp-login.php] [8] Saving variable: TX:942100-OWASP_CRS/WEB_ATTACK/SQL_INJECTION-ARGS:pwd with value: abc!@#
[155964037689.889786] [/wp-login.php] [9] This rule severity is: 2 current transaction is: 2

[airween]

Okay, thanks, have to check, what's the expected behavior.

[theMiddleBlue]

Can you confirm that

Unfortunately, I've test ruleRemoveTargetById using a specific ruleId and not a range. I just assumed that it would have worked with range too. I've done a regression test and yes... I can confirm that there're two different bugs in ruleRemoveTargetById and in ruleRemoveById :(

I'm going to open another issue to ModSecurity. Thanks for your support.

[theMiddleBlue]

Following the two issues:

• https://github.com/SpiderLabs/ModSecurity/issues/2110
• https://github.com/SpiderLabs/ModSecurity/issues/2111

[lifeforms]

This is fixed in v3.2.0. We worked around the problem in ModSecurity 3 by adding the explicit tag to all the rules. Thanks for reporting!