Modsecurity: SecRuleUpdateTargetById does not work anymore (since version 3.0.4)

[matthijs]

Describe the bug

Due to a security bug in libmodsecurity version 3.0.3 we decided to upgrade to version 3.0.4. After we did the upgrade one of our SecRuleUpdateTargetById didn't work anymore.

To be more precise, we have an incoming JSON request which contains a SSL-certificate. This certificate causes libinjection to detect a XSS. Which is obviously not true. So we have the following configuration to exclude that specific parameter:
SecRuleUpdateTargetById 941100 "!ARGS:json.data.certificate.certificates.intermediate"

Logs and dumps

Output of:

1. DebugLogs (level 9)
   See attachment debug.log.gz

1. AuditLogs
   See attachment audit.log.gz

2. Error logs
   2020/01/28 16:55:15 [error] 30675#30675: *1 [client ] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator Ge' with parameter5' against variable TX:ANOMALY_SCORE' (Value:5' ) [file "/usr/share/modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "79"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname ""] [uri "/url"] [unique_id "158022691566.663811"] [ref ""], client: , server: ccp.cacholong.nl, request: "POST /url HTTP/2.0", host: "host"

3. If there is a crash, the core dump file.
   No crash.

To Reproduce

Steps to reproduce the behavior:

1.) Have the core rule set installed (version 3.2.0) with the following configuration in nginx:
Include /etc/modsecurity/modsecurity.conf
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
Include /usr/share/modsecurity-crs/rules/*.conf
SecRuleUpdateTargetById 941100 "!ARGS:json.data.certificate.certificates.intermediate"
Include /etc/modsecurity/crs/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf

2.) curl command to reproduce: (postdata.json.gz)
curl -D - -o /dev/null -s -H 'Content-Type: application/json' -H 'Signature: sha256=9555eb4df0540088409847235897b5f99c298678157baf90f3670f5ddb3990f7' -X POST -d @postdata.json https://somehost/url

Expected behavior

I expect that modsecurity leaves the request alone and does not return with a 403 error. To be precise the rule 941100 should not be triggered because of the updated target (!ARGS:json.data.certificate.certificates.intermediate).

Server (please complete the following information):

• ModSecurity v3.0.4 with nginx-connector v1.0.1
• WebServer: nginx 1.16.1
• OS (and distro): Linux, Debian GNU/Linux

Rule Set (please complete the following information):

• Running any public or commercial rule set?
  Modsecurity core rule set (debian package installed on this system)
• What is the version number?
  3.2.0

Regards, Matthijs

[airween]

Try to replace the variable argument as regex, I mean:

SecRuleUpdateTargetById 941100 "!ARGS:/json.data.certificate.certificates.intermediate/"

Hope this helps.

[matthijs]

Thanks, that fixed my problem. According to the documentation my configuration should work too right?

[airween]

Thanks, that fixed my problem.

Cool,

According to the documentation my configuration should work too right?

If I could be funny (and I apologize to everyone for this joke), I could write that the documentation is made for the enemies to confuses them :). It less and more less to know what's the good and what's the unexpected behavior. May be... if your issue will be corrected, then your configuration is right.... I don't know.

Anyway, I just searched in the closed issues/PR's, and found this one which is related to your issue.

[matthijs]

If I could be funny (and I apologize to everyone for this joke), I could write that the documentation is made for the enemies to confuses them :). It less and more less to know what's the good and what's the unexpected behavior. May be... if your issue will be corrected, then your configuration is right.... I don't know.

Haha, no problem.

Anyway, I just searched in the closed issues/PR's, and found this one which is related to your issue.

Hm, I should have read that issue better especially the third reply.

Thanks.

[martinhsv]

Hi @matthijs

According to the documentation my configuration should work too right?

Yes. And it would have worked in v3.0.3.

I can see the code change the resulted in the modified behaviour in v3.0.4 and I'll follow up on that.

[zimmerle]

Hi @matthijs,

You don't need to upgrade ModSecurity due to the DOS issue. The patch is available for those who want to keep using v3.0.3. There is a patch available here: https://github.com/SpiderLabs/Misc/blob/master/ModSecurity_cookie_parsing_fix_303.patch

[matthijs]

Hi @zimmerle

I know, but there were more issues fixed in the v3.0.4 release which I could use. For example the empty JSON body.

[martinhsv]

Hi @matthijs ,

The non-regex version of SecRuleUpdateTargetById that you had originally should now work in v3/master.

This is as of https://github.com/SpiderLabs/ModSecurity/commit/1b1fdc055b8071ad3b24573abfe9b96e546c7abf