Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

REQUEST-949: Increase msg verbosity of rule 949110 #1924

Closed
wants to merge 1 commit into from

Conversation

pmjdebruijn
Copy link

No description provided.

@dune73
Copy link
Member

dune73 commented Dec 7, 2020

@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
Copy link
Author

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
Copy link
Member

dune73 commented Dec 7, 2020

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.

@dune73 dune73 closed this Dec 7, 2020
@pmjdebruijn
Copy link
Author

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
Copy link
Member

dune73 commented Dec 8, 2020

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
Copy link
Author

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
Copy link
Member

dune73 commented Dec 8, 2020

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
Copy link
Author

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
Copy link
Member

dune73 commented Dec 9, 2020

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
Copy link
Author

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

@dune73
Copy link
Member

dune73 commented Dec 9, 2020

We'll see if that gets any traction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants