WP-Cron blocked

[Zoey2936]

see:
2024/03/09 08:45:26 [error] 2711#2711: *1414 [client <internal-ip-of-wp-docker-container>] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Ge' with parameter `5' against variable `TX:BLOCKING_INBOUND_ANOMALY_SCORE' (Value: `5' ) [file "/usr/local/nginx/conf/conf.d/include/coreruleset/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"] [maturity "0"] [accuracy "0"] [tag "anomaly-evaluation"] [hostname "<external-ip>"] [uri "/wp-cron.php"] [unique_id "170997032676.301850"] [ref ""], client: <internal-ip-of-wp-docker-container>, server: <domain>, request: "POST /wp-cron.php?doing_wp_cron=1709970326.3545379638671875000000 HTTP/1.1", host: "<domain>"

[azurit]

@Zoey2936 Hi. Can you post also other logs? This one is only an information about blocking the request, it does not contain why it was blocked. Thank you.

[Zoey2936]

What logs exactly?
The access log would be this:
[09/Mar/2024:08:45:26 +0100] <domain> <internal-ip-of-wp-docker-container> 0.000 "POST /wp-cron.php?doing_wp_cron=1709970326.3545379638671875000000 HTTP/1.1" 403 172 640 - WordPress/6.4.3; <domain>

[EsadCetiner]

@Zoey2936 It looks like you got the other log line from your Nginx error log?
The log line you provided is for rule 949110 which is an anomoly scoring rule. There is another rule that has added +5 to the anomoly score that resulted in 949110 blocking the request, we can't see the rule that's added +5 to the anomoly score.
You can try checking your modsec_audit.log (normally in /var/log/modsec_audit.log or if your using Nginx, enable info level error logging.

[Zoey2936]

2024/03/09 09:42:40 [info] 4897#4897: *3504 ModSecurity: Warning. Matched "Operator `ValidateByteRange' with parameter `1-255' against variable `TX:tf_1_hexDecode_ARGS:doing_wp_cron' (Value: `\x17\x09\x977`\xe0D\x95\x00\x089#3\x98Cu' ) [file "/usr/local/nginx/conf/conf.d/include/coreruleset/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "542"] [id "920270"] [rev ""] [msg "Invalid character in request (null character)"] [data "TX:tf_1_hexDecode_ARGS:doing_wp_cron=\x17\x09\x977`\xe0D\x95\x00\x089#3\x98Cu"] [severity "2"] [ver "OWASP_CRS/4.0.0"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272"] [hostname "<external-ip>"] [uri "/wp-cron.php"] [unique_id "170997376069.776165"] [ref "o8,1t:urlDecodeUni"], client: 172.22.0.2, server: <domain>, request: "POST /wp-cron.php?doing_wp_cron=1709973760.0449500083923339843750 HTTP/1.1", host: "<domain>"

[azurit]

@Zoey2936 Are you using Automatic Decoding Plugin?

[Zoey2936]

yes

[dune73]

Wow, we have a user!

[Zoey2936]

does this issue need to be fixed here or in the decoding plugin?

[azurit]

@Zoey2936 In here but first i need to understand this more. Can you share the data which were blocked? Should be in doing_wp_cron argument. Thanks.

[Zoey2936]

wp-cron.php?doing_wp_cron=1709973760.0449500083923339843750

[azurit]

wp-cron.php?doing_wp_cron=1709973760.0449500083923339843750

@dune73 Can you share some of your knowledge? Why was this value decoded by Automatic Decoding Plugin? It's definitely a unix timestamp and decoding it generated some 'random' binary data which triggered rule 920270.

[azurit]

@dune73 ping

[RedXanadu]

It looks like the hexDecode transformation function turned the

9500

part of the input parameter into \x95 and a null byte, \x00. The presence of a null byte triggered rule 920270, which matches on null bytes.

The auto-decoding plugin attempts to decode all input parameters.

I suppose the solution would be up to the user. Some ideas:

• Exclude the problematic parameter from all auto-decoding attempts?
  • "We don't care what the contents of this parameter are: it's never executed in any way, so it's safe to ignore."
• Exclude the problematic parameter from the hex decode rule only?
  • "We want to continue auto-decoding this parameter, but we don't care about hex decoding and acknowledge that performing it causes false positives."
• Exclude the output of the hex decode rule from the null byte rule?
  • "We want to continue performing full auto-decoding of this parameter, but this can cause null bytes to appear, so we want to stop rule 920270 from causing false positives in this very specific circumstance. Other false positives may well appear in the future."
• Disable auto-decoding altogether.
  • "We don't need this super high level of security. The benefits are completely outweighed by the added complexity."