REQUEST-949: Increase msg verbosity of rule 949110

[pmjdebruijn]

No description provided.

[dune73]

@pmjdebruijn : Thank you for this contribution.

You are basically repeating the information in 980130. While I personally do not like 980130, your PR creates redundancy and I wonder if that is what you really intend and if so why.

[pmjdebruijn]

I've made this change to be able to troubleshoot an issue we were having... It seems 980130 didn't get triggered for us... Presumably because 980130 evaluates TX.INBOUND_ANOMALY_SCORE while my change evaluates TX.ANOMALY_SCORE

[dune73]

That's very odd, since the former is defined in 949110 based on the latter. This means if 949110 triggers, 980130 triggers too. I plan to overhaul this whole anomaly score logging, but that's the way it is meant to run right now and you introduce redundancy and if it's only in order to get this info, then the PR does not really add value since the info is already there.

If you consistently do not get 980130, then we're open to investigate this with you, since it might be a bug.

If I do a vanilla installation and the following curl call, then I get 949110 and 980130.

curl -v http://localhost/index.html?test=/etc/passwd

error.log:

[2020-12-07 16:12:49.734405] [-:error] 127.0.0.1:35912 X85GcaS@1gnke8m2Vh5wpQAAAAE [client 127.0.0.1] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/home/dune73/data/git/crs-pull-1911/rules/RESPONSE-980-CORRELATION.conf"] [line "87"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 15 - SQLI=0,XSS=0,RFI=0,LFI=5,RCE=5,PHPI=0,HTTP=0,SESS=0): individual paranoia level scores: 10, 0, 0, 5"] [ver "OWASP_CRS/3.3.0"] [tag "event-correlation"] [hostname "localhost"] [uri "/403.html"] [unique_id "X85GcaS@1gnke8m2Vh5wpQAAAAE"]

I'm closing this for the time being.

[pmjdebruijn]

While I can reproduce your example case, for us this wasn't true for a false positive flagged via libinjection
client9/libinjection#151
as libinjection javascript function matching is rather naive, and generates false positive on "onedrive"

[dune73]

Can you provide a onedrive-example call (ideally curl) so I can check this out, please. I do not get a FP with this. I'm interested in learning about this.

But it does not matter how what triggers the score. The deciding factor on 980130 is whether the request hit the anomaly score limit or not (in 949110).

[pmjdebruijn]

curl --insecure --verbose https://MYHOST/?url=https://whatever.com/onedrive.aspx?id=test

Triggers the issue, however, it seems, proper logging does happen to modsecurity.log. Now I've noticed this in a test setup, where I cleared all logs before reproducing, so I'm guessing I must have missed this in our production situation due to modsecurity.log being a multiline format, which is much harder to grep/read through reliably.

So I still think there is still some value in including slightly more information in error.log which is much easier to grep/parse.

[dune73]

I confirm the libinjection false positive for this one.

Here are my logs, including 980130.

[2020-12-08 10:31:30.735666] [-:error] 127.0.0.1:42958 X89H8kbRs0p8Gv-gDMwEcwAAAAA [client 127.0.0.1] ModSecurity: Warning. detected XSS using libinjection. [file "/home/dune73/data/git/crs-official/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "60"] [id "941100"] [msg "XSS Attack Detected via libinjection"] [data "Matched Data: XSS data found within ARGS:url: https://whatever.com/onedrive.aspx?id=test"] [severity "CRITICAL"] [ver "OWASP_CRS/3.2.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-xss"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "OWASP_CRS/WEB_ATTACK/XSS"] [tag "WASCTC/WASC-8"] [tag "WASCTC/WASC-22"] [tag "OWASP_TOP_10/A3"] [tag "OWASP_AppSensor/IE1"] [tag "CAPEC-242"] [hostname "localhost"] [uri "/"] [unique_id "X89H8kbRs0p8Gv-gDMwEcwAAAAA"]
[2020-12-08 10:31:30.736015] [-:error] 127.0.0.1:42958 X89H8kbRs0p8Gv-gDMwEcwAAAAA [client 127.0.0.1] ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. [file "/home/dune73/data/git/crs-official/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "91"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [severity "CRITICAL"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "localhost"] [uri "/"] [unique_id "X89H8kbRs0p8Gv-gDMwEcwAAAAA"]
[2020-12-08 10:31:30.739206] [-:error] 127.0.0.1:42958 X89H8kbRs0p8Gv-gDMwEcwAAAAA [client 127.0.0.1] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/home/dune73/data/git/crs-official/rules/RESPONSE-980-CORRELATION.conf"] [line "86"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5 - SQLI=0,XSS=5,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): individual paranoia level scores: 5, 0, 0, 0"] [tag "event-correlation"] [hostname "localhost"] [uri "/403.html"] [unique_id "X89H8kbRs0p8Gv-gDMwEcwAAAAA"]

You are right, that the logging is tricky to read correctly, namely when you work with the audit log. And I think this also explains why you did not notice your initial 980130 entry.

One key to successful logging is usually to filter by the unique-ID which has the last position in the alert message that is written to the error.log.

My tutorials at netnea.com advocate to write this unique-ID to the access.log as well.

If you want to be a good web citizen, you could open a false positive report over at libinjection. But I have to admit, the bugs are piling up and development is not going anywhere. But at least it would be documented.

[pmjdebruijn]

As I already mentioned, it was already reported: client9/libinjection#151

I polished up that code, and created a proper pull request: client9/libinjection#153

[dune73]

Ah, sorry. I'm juggling too many issues in parallel here.

Thank you for your work and submitting a PR. Now if only libinjection would return from the dead.

[pmjdebruijn]

It seems it's been resurrected by the libmodsec folks:
libinjection/libinjection#10

[dune73]

We'll see if that gets any traction.