coreruleset / coreruleset

OWASP CRS (Official Repository)
https://coreruleset.org
Apache License 2.0
2.21k stars 367 forks source link

Media Wiki Visual Editor #2314

Closed caswal closed 2 years ago

caswal commented 2 years ago

Description

MediaWiki's Visual Editor is causing false positives. Especially when editing pages with tables, parenthesis etc. This has occurred to me on Dreamhost's Shared Hosting, so I'm not sure how much log/info I can pull due to my limited ssh account rights.

Audit Logs / Triggered Rule Numbers

Warning. Pattern match "(?i)(?:;|\\\\{|\\\\||\\\\|\\\\||&|&&|\\\\n|\\\\r|`)\\\\s*[\\\\(,@\\\\'\\"\\\\s]*(?:[\\\\w'\\"\\\\./]+/|[\\\\\\\\'\\"\\\\^]*\\\\w[\\\\\\\\'\\"\\\\^]*:.*\\\\\\\\|[\\\\^\\\\.\\\\w '\\"/\\\\\\\\]*\\\\\\\\)?[\\"\\\\^]*(?:s[\\"\\\\^]*(?:y[\\"\\\\^]*s[\\"\\\\^]*(?:t[\\"\\\\^]*e[\\"\\\\^]*m[\\"\\\\^]*(?:p[\\"\\\\^]*r[\\"\\\\^]*o[\\"\\\\^]*p[\\"\\\\^]*e ..." at ARGS:text. [file "/dh/apache2/template/etc/mod_sec3_CRS/REQUEST-932-APPLICATION-ATTACK-RCE.conf"] [line "294"] [id "932115"] [msg "Remote Command Execution: Windows Command Injection"] [data "Matched Data: \\x0a\\x0aSelect found within ARGS:text: == Wiki Page Text with \ and html < >, brackets, etc"] [severity "CRITICAL"] [ver "OWA [hostname "wiki.mydomain.com"] [uri "/api.php"] [unique_id "YZSBFgWrkk2MdmeA-R9YRgAAAAE"], referer: https://wiki.mydomain.com/index.php?title=A_WIKI_PAGE&action=edit
[Tue Nov 16 20:12:07.220330 2021] [:error] [pid 9183:tid 3807039907584] [client 10.x.y.z:52708] [client 10.x.y.z] ModSecurity: Rule 3766f90c4e0 [id "932140"][file "/dh/apache2/template/etc/mod_sec3_CRS/REQUEST-932-APPLICATION-ATTACK-RCE.conf"][line "412"] - Execution error - PCRE limits exceeded (-8): (null). [hostname "wiki.mydomain.com"] [uri "/api.php"] [unique_id "YZSBFgWrkk2MdmeA-R9YRgAAAAE"], referer: https://wiki.mydomain.com/index.php?title=A_WIKI_PAGE&action=edit
[Tue Nov 16 20:12:07.276735 2021] [:error] [pid 9183:tid 3807039907584] [client 10.x.y.z:52708] [client 10.x.y.z] ModSecurity: Rule 3766ee5d400 [id "942190"][file "/dh/apache2/template/etc/mod_sec3_CRS/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"][line "183"] - Execution error - PCRE limits exceeded (-8): (null). [hostname "wiki.mydomain.com"] [uri "/api.php"] [unique_id "YZSBFgWrkk2MdmeA-R9YRgAAAAE"], referer: https://wiki.mydomain.com/index.php?title=A_WIKI_PAGE&action=edit
[Tue Nov 16 20:12:07.281782 2021] [:error] [pid 9183:tid 3807039907584] [client 10.x.y.z:52708] [client 10.x.y.z] ModSecurity: Rule 3766ee3c490 [id "942240"][file "/dh/apache2/template/etc/mod_sec3_CRS/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"][line "254"] - Execution error - PCRE limits exceeded (-8): (null). [hostname "wiki.mydomain.com"] [uri "/api.php"] [unique_id "YZSBFgWrkk2MdmeA-R9YRgAAAAE"], referer: https://wiki.mydomain.com/index.php?title=A_WIKI_PAGE&action=edit

Your Environment

I can't seemingly make calls to apache2, httpd, apachectl etc. No sudo rights, so can't go poking around in /var/ etc

Confirmation

[ ] I have removed any personal data (email addresses, IP addresses, passwords, domain names) from any logs posted.

airween commented 2 years ago

Hi @caswal, thank you for your report.

(I've edited your comment: I've put the logs between ``` characters)

Unfortunately, a false positive like this can sometimes occur, even if the paranoia level is lower - this rule is activated in PL1.

I've made a quick research about possible solutions in case of Dreamhost, but unfortunately I didn't find any method how can you make an exclusion - looks like you can't access the rules, and using of .htaccess is also disabled. I'm afraid the only thing is you can do that contact the support, and notice them about this issue, and/or ask an exclusion, like this:

SecRule REQUEST_URI "@beginsWith /api.php" \
    "id:10001,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleRemoveById=932115"

Please let us know if we can help anything.

dune73 commented 2 years ago

Let me add that the subsequent alerts were not due to rule violations, but due to PCRE match limit hits. That means the PCRE Match limits are overly low (a frequent problem we see when people leave the default settings or do not raise it enough) or your wiki payload is very large.

caswal commented 2 years ago

Thanks for the support guys, is appreciated. It looks like this issue is pretty common: https://www.mediawiki.org/wiki/Topic:Vv23nm75ef2cyxtn

Various topics about it, and so far no mention that it could be that ModSecurity rules are catching it. At least I have made a comment letting people know a possible solution.

@dune73 from my googling, I did learn that the PCRE Match limit was a rate-limiting error, and noticed it came from editing large wiki pages.

Not sure if asking for an exclusion like that really works. It will end up being a game of whack-a-mole, checking over the logs, other pages have also triggered 921130, 921110, 932100, 932105, 932110, 932130, 932140, 942190, 942240.

This won't make for a good user experience, when a user edits a wiki page, attempts to save it and gets an HTTP 500 Error, triggering a rule that hasn't been excluded.

Dreamhost has the ability to turn off ModSecurity, so I have opted for this as a solution, and rely on that MediaWiki is robust, and Dreamhost keeps the shared hosting fully up to date.

airween commented 2 years ago

Hi @caswal,

thanks for feedback - if you need any help, please let us know.

If you think we can't help anymore in this problem, please close this issue.

dune73 commented 2 years ago

@caswal: Securing a free form text entry application, namely a wiki, is a whack-a-mole. We have rule exclusion packages for other software, including dokuwiki, but it takes a certain effort. It's an effort we can not do on ourselves, it takes support from the community behind said software. So if the Media Wiki crowd wants to be able to run CRS seamlessly, then we would be more than happy to cooperate and come up with a rule exclusion package.

Until then, I think disabling ModSec is a pragmatic step given your situation.

github-actions[bot] commented 2 years ago

This issue has been open 120 days with no activity. Remove the stale label or comment, or this will be closed in 14 days