Modsecurity exclusion not working. Big WordPress problems.
Hi everyone. Please chime-in if you have any suggestions. I'm in serious need of some help as I have a time-sensitive critical situation involving the migration of a large number of WP sites to new servers, and I have spent over a week searching / reading / banging my head against the wall over this.
The new servers that have this issue are running OWASP ModSecurity Core Rule Set V3.0 (SpiderLabs OWASP curated ModSecurity rule set) , Provider: cPanel.
What is happening - there is a popular page editor plugin that almost all of my customers use, and modsec is preventing edits from being saved as follows:
------------
[Wed Jun 12 05:38:17.955298 2024] [security2:error] [pid 349775:tid 22358505871104] [remote XX.XX.XX.XX:55248] [client XX.XX.XX.XX] ModSecurity: Warning. detected XSS using libinjection. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "37"] [id "941100"] [rev "2"] [msg "XSS Attack Detected via libinjection"] [data "Matched Data: <div id=\\x22sp-page\\x22 class=\\x22spBgcover sp-content-4\\x22 style=\\x22background-color: rgb(255, 255, 255); font-family: Open Sans, sans-serif; font-weight: 400;\\x22><section id=\\x22sp-m7rics\\x22 data-mobile-visibility=\\x22#sp-m7rics|false\\x22 data-tablet-visibility=\\x22#sp-m7rics|false\\x22 data-desktop-visibility=\\x22#sp-m7rics|false\\x22 data-mobile-css=\\x22\\x22 data-tablet-css=\\x22\\x22 class=\\x22sp-el-section \\x22 style=\\x22width: 660px; max-width: 100%; padding: 10px;\\x22><div id=\\x22sp..."] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "1"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-xss"] [tag "OWASP_CRS/WEB_ATTACK/XSS"] [tag "WASCTC/WASC-8"] [tag "WASCTC/WASC-22"] [tag "OWASP_TOP_10/A3"] [tag [hostname "www.example.com"] [uri "/wp-admin/admin-ajax.php"] [unique_id "ZmlsiYi3cXM6dN5HhOM3GgAABxc"], referer: https://www.example.com/wp-admin/admin.php?page=pageb_lite_builder&id=447
[Wed Jun 12 05:38:17.958791 2024] [security2:error] [pid 349775:tid 22358505871104] [remote XX.XX.XX.XX:55248] [client XX.XX.XX.XX] ModSecurity: Warning. Pattern match "(?i)(?:<(?:(?:apple|objec)t|isindex|embed|style|form|meta)\\\\b[^>]*?>[\\\\s\\\\S]*?|(?:=|U\\\\s*?R\\\\s*?L\\\\s*?\\\\()\\\\s*?[^>]*?\\\\s*?S\\\\s*?C\\\\s*?R\\\\s*?I\\\\s*?P\\\\s*?T\\\\s*?:)" at ARGS:lpage_html. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "65"] [id "941140"] [rev "3"] [msg "XSS Filter - Category 4: Javascript URI Vector"] [data "Matched Data: <style type=\\x22text/css\\x22> found within ARGS:lpage_html: <div id=\\x22sp-page\\x22 class=\\x22spBgcover sp-content-4\\x22 style=\\x22background-color: rgb(255, 255, 255); font-family: Open Sans, sans-serif; font-weight: 400;\\x22><section id=\\x22sp-m7rics\\x22 data-mobile-visibility=\\x22#sp-m7rics|false\\x22 data-tablet-visibility=\\x22#sp-m7rics|false\\x22 data-desktop-visibility=\\x22#sp-m7rics|false\\x22 data-mobile-css=\\x22\\x22 data-tablet-css=\\x22\\x22 class=\\x22sp-el-section \\x22 style=\\x22widt..."] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "1"] [accuracy "8"] [tag "application-multi" [hostname "www.example.com"] [uri "/wp-admin/admin-ajax.php"] [unique_id "ZmlsiYi3cXM6dN5HhOM3GgAABxc"], referer: https://www.example.com/wp-admin/admin.php?page=pageb_lite_builder&id=447
[Wed Jun 12 05:38:17.959231 2024] [security2:error] [pid 349775:tid 22358505871104] [remote XX.XX.XX.XX:55248] [client XX.XX.XX.XX] ModSecurity: Warning. Pattern match "(?i)<[^\\\\w<>]*(?:[^<>\\"'\\\\s]*:)?[^\\\\w<>]*(?:\\\\W*?s\\\\W*?c\\\\W*?r\\\\W*?i\\\\W*?p\\\\W*?t|\\\\W*?f\\\\W*?o\\\\W*?r\\\\W*?m|\\\\W*?s\\\\W*?t\\\\W*?y\\\\W*?l\\\\W*?e|\\\\W*?s\\\\W*?v\\\\W*?g|\\\\W*?m\\\\W*?a\\\\W*?r\\\\W*?q\\\\W*?u\\\\W*?e\\\\W*?e|(?:\\\\W*?l\\\\W*?i\\\\W*?n\\\\W*?k|\\\\W*?o\\\\W*?b\\\\W*?j\\\\W*?e\\ ..." at ARGS:lpage_html. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "74"] [id "941160"] [rev "2"] [msg "NoScript XSS InjectionChecker: HTML Injection"] [data "Matched Data: <div id=\\x22sp-page\\x22 class=\\x22spBgcover sp-content-4\\x22 style=\\x22background-color: rgb(255, 255, 255); font-family: Open Sans, sans-serif; font-weight: 400;\\x22><section id=\\x22sp-m7rics\\x22 data-mobile-visibility=\\x22#sp-m7rics|false\\x22 data-tablet-visibility=\\x22#sp-m7rics|false\\x22 data-desktop-visibility=\\x22#sp-m7rics|false\\x22 data-mobile-css=\\x22\\x22 data-tablet-css=\\x22\\x22 class=\\x22sp-el-section \\x22 style=\\x22width: 660px; max-width: 100%; padding: 10px;\\x22><div id=\\x22sp..."] [seve [hostname "www.example.com"] [uri "/wp-admin/admin-ajax.php"] [unique_id "ZmlsiYi3cXM6dN5HhOM3GgAABxc"], referer: https://www.example.com/wp-admin/admin.php?page=pageb_lite_builder&id=447
[Wed Jun 12 05:38:18.180759 2024] [security2:error] [pid 349775:tid 22358505871104] [remote XX.XX.XX.XX:55248] [client XX.XX.XX.XX] ModSecurity: Warning. Pattern match "(?i:<style.*?>.*?((@[i\\\\\\\\])|(([:=]|(&#x?0*((58)|(3A)|(61)|(3D));?)).*?([(\\\\\\\\]|(&#x?0*((40)|(28)|(92)|(5C));?)))))" at ARGS:lpage_html. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "95"] [id "941190"] [rev "3"] [msg "IE XSS Filters - Attack Detected."] [data "Matched Data: <style type=\\x22text/css\\x22>\\x0a #sp-o86pkf .sp-col-top .pageb-shape-fill {fill: undefined;} #sp-o86pkf .sp-col-top svg {width: undefined%;height: undefinedpx;transform: translateX( found within ARGS:lpage_html: <div id=\\x22sp-page\\x22 class=\\x22spBgcover sp-content-4\\x22 style=\\x22background-color: rgb(255, 255, 255); font-family: Open Sans, sans-serif; font-weight: 400;\\x22><section id=\\x22sp-m7rics\\x22 data-mobile-visibility=\\x22#sp-m7rics|false\\x22 data-tablet-visibility=\\x22#s..."] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "8"] [accuracy "8"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "atta [hostname "www.example.com"] [uri "/wp-admin/admin-ajax.php"] [unique_id "ZmlsiYi3cXM6dN5HhOM3GgAABxc"], referer: https://www.example.com/wp-admin/admin.php?page=pageb_lite_builder&id=447
[Wed Jun 12 05:38:18.204918 2024] [security2:error] [pid 349775:tid 22358505871104] [remote XX.XX.XX.XX:55248] [client XX.XX.XX.XX] ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "30"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 20)"] [severity "CRITICAL"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "www.example.com"] [uri "/wp-admin/admin-ajax.php"] [unique_id "ZmlsiYi3cXM6dN5HhOM3GgAABxc"], referer: https://www.example.com/wp-admin/admin.php?page=pageb_lite_builder&id=447
[Wed Jun 12 05:38:18.205240 2024] [security2:error] [pid 349775:tid 22358484858624] [client XX.XX.XX.XX:55248] [client XX.XX.XX.XX] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/RESPONSE-980-CORRELATION.conf"] [line "37"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 20 - SQLI=0,XSS=20,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): IE XSS Filters - Attack Detected."] [tag "event-correlation"] [hostname "www.example.com"] [uri "/wp-admin/admin-ajax.php"] [unique_id "ZmlsiYi3cXM6dN5HhOM3GgAABxc"], referer: https://www.example.com/wp-admin/admin.php?page=pageb_lite_builder&id=447
-----------
So...
In WHM / Home / Security Center / ModSecurity Tools > Edit Custom Rules , I have tried adding exclusions based what I had done 6 years ago based on the amazing help of @fuzzylogic in this other OP's thread 6 years ago - https://support.cpanel.net/hc/en-us/community/posts/19677141021335-ModSecurity-Rules-and-Alt-Languages - but with no success on these new servers. And also based on that, I see it's not a good idea disable master rules 941100 and 980130 , so now I'm really at a loss.
I'm virtually at the end of my rope and don't know where to go from here. The only exclusions I could manage to find are from long ago and they aren't working.
Immense gratitude for any responses, please and thank you!
-
PS - I'm really hoping fuzzylogic is still around and that maybe cPRex might also be able to chime-in on this. I'm in a bad place with this and could really use some help. Thanks guys!
0 -
Hey hey! Just in case, are we sure we aren't misreading the numbers? 941190 is the one you don't want to whitelist, but your logs show 949110. Close, but not the same, so could it be that easy?
It's also completely possibly/likely that after you whitelist one number, another will come up.
Here's the new method: https://support.cpanel.net/hc/en-us/articles/360060009754-How-to-disable-a-mod-security-rule-rule-set-globally
0 -
cPRex - that was a typo on my part, thank you for alerting. From all the documentation I can find, globally disabling 941100 essentially disables modsecurity , so that one needs to stay active.
Thank you for the link to the article, it is helpful. I'll see what I can find out about 949110 and if it's safe to disable that one globally or not, and whether or not that helps with the issue I'm facing.
Thanks very much for the response!
0 -
Sure thing!
0 -
Quick update for anyone that might care or that this might help - using ConfigServer ModSecurity Control (to test on just one site, rather than throwing caution to the wind and disabling these globally) - I disabled these rules one by one, in order, testing WP after each one at a time:
941140
941160
941190
949110It wasn't until I disabled all four of them that the issue was resolved.
Now to go through the various combinations of enabling / disabling them one by one back & forth to see if all four actually need to be disabled, or if it's only one (or two, or three) of them.
The thing that's a little scary is that a couple of those rules are definitely properly stopping some bad actors / vulnerability seekers.
1 -
Nice work!
0 -
Thank you Rex, but I certainly don't deserve any compliments here lol! I needed to look closer, and obviously needed your nudge to get my sleep-deprived brain to focus. This is something I should have been able to figure out over a week ago on my own. SMH... but anyway...
Bittersweet update...
I had to disable all four of these:
941140
941160
941190
949110I tested all of the combinations / variations, and although just disabling two of those stopped the error of "page could not be saved" in the WP page editor plugin, and some text and format changes were successful, I still had to disable the other two in order for it to properly allow handling of images in the editor.
With those disabled everything works so that's good, but when using the editor plugin in question, Apache error log still throws this with every edit save:
[Wed Jun 12 16:44:34.458012 2024] [security2:error] [pid 669113:tid 22358518478592] [remote XX.XX.XX.XX:61388] [client XX.XX.XX.XX] ModSecurity: Warning. detected XSS using libinjection. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "37"] [id "941100"] [rev "2"] [msg "XSS Attack Detected via libinjection"] [data "Matched Data: <div id=\\x22sp-page\\x22 class=\\x22spBgcontainscroll sp-content-4\\x22 style=\\x22background-color: rgb(255, 255, 255); font-family: Raleway, sans-serif; font-weight: 400;\\x22><section id=\\x22sp-m7rics\\x22 data-mobile-visibility=\\x22#sp-m7rics|false\\x22 data-tablet-visibility=\\x22#sp-m7rics|false\\x22 data-desktop-visibility=\\x22#sp-m7rics|false\\x22 data-mobile-css=\\x22\\x22 data-tablet-css=\\x22\\x22 class=\\x22sp-el-section \\x22 style=\\x22width: 600px; max-width: 100%; padding: 10px; margin-top: ..."] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "1"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-xss"] [tag "OWASP_CRS/WEB_ATTACK/XSS"] [tag "WASCTC/WASC-8"] [tag "WASCTC/WASC-22"] [tag "OWASP_TOP_10/A3"] [tag [hostname "example.com"] [uri "/wp-admin/admin-ajax.php"] [unique_id "ZmoIss75iq376xGW5okU9wABGBE"], referer: https://example.com/wp-admin/admin.php?page=pageb_lite_builder&id=119
But that's much more preferable to having customers unable to do their edits and moving to a different host.
And while the upshot is this - the popular page editor plugin that almost all of my WP customers use can now work if I disable all 4 rules.
The somewhat scary downside is this - a couple of those rules are correctly stopping bad actors attempting to do bad things. Especially 949110 - that throws hits every minute from many known IPs with 100% bad reps on AbuseIPDB for being hackers / DDoS'ers etc...
So, having to disable all 4 globally, especially 949110, worries me. But alas, I have no choice as I have to get a bunch of accounts moved off of older servers still running EOL cPanel 110.0.34 / CL 6.10 / MySQL 5.7 / PHP 7.4 and transferred to new cPanel 120.0.10 / CL 8.10 / MySQL 8 / PHP 8.3 boxes in a hurry.
I'm sure that someone who lives & breathes modsecurity (or is at least highly proficient with it) would know to just adjust those rules with exclusion parameters rather than completely disabling them. Speaking of such a person, fuzzylogic are you still around these days? ;) I do hope so, and that you'll consider replying with your excellent insights as well.
In the meantime, I hope that something in this thread will help someone else someday.
0 -
More headaches... I just found more items on the web that indicate 949110 should not be disabled. Once again, at a loss. :/
0 -
Maybe it would be better to reach out to the developer of that plugin to see if they have ideas? If it's tripping the core ModSec rules, that isn't something that can be easily avoided.
0 -
Thanks cPRex , but unfortunately this has turned out to be a much bigger problem than I originally noticed.
It's not just one plugin being affected, and not even just WordPress.
In addition to the popular page builder plugin I mentioned in previous posts, I've discovered as I migrate customers from old servers to new servers:
1. For all of the Woocommerce sites that I host, the OWASP Core rules are completely blocking the Checkout page. That makes now two major plugins / functions that the default OWASP core rules are killing during normal operations.
2. There is another modern CMS type of script that a large number of my customers use, also e-commerce related / detrimental to their site functions and sales, in which their normal process of generating an email receipt from within the CMS triggers a 403 from OWASP core modsecurity rules.
At this point I'm completely out of time to get everyone off of the old servers and onto the new ones, and have absolutely have no choice but to disable the cPanel / OWASP modsecurity entirely.
Six months of painstaking efforts to overcome one obstacle after another, only to finally hit this brick-wall as I move customer accounts to the new boxes.
I did bring up the topic previously in tickets with my new data center / server provider, but to no avail. Truly at the end of my rope and don't know what to do next, just hoping that I don't start taking-on too much damage by having to disable modsecurity on every WordPress (and another modern CMS) in order to avoid going out of business. FML
0 -
This is what happens with OWASP cPanel core rules enabled when someone tries to checkout on a modern WooCommerce cart:
[Wed Jun 19 06:48:45.243690 2024] [security2:error] [pid 409922:tid 22717533611776] [remote xx.xx.xx.xx:60528] [client xx.xx.xx.xx] ModSecurity: Warning. Matched phrase "=" at ARGS:post_data. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf"] [line "71"] [id "933120"] [rev "1"] [msg "PHP Injection Attack: Configuration Directive Found"] [data "Matched Data: = found within ARGS:post_data: wc_order_attribution_source_type=typein&wc_order_attribution_referrer=(none)&wc_order_attribution_utm_campaign=(none)&wc_order_attribution_utm_source=(direct)&wc_order_attribution_utm_medium=(none)&wc_order_attribution_utm_content=(none)&wc_order_attribution_utm_id=(none)&wc_order_attribution_utm_term=(none)&wc_order_attribution_utm_source_platform=(none)&wc_order_attribution_utm_creative_format=(none)&wc_order_attribution_utm_marketing_tactic=(none)&wc_order_..."] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "1"] [accuracy "8"] [tag "application-multi"] [tag "language-php"] [tag "platform-multi"] [tag "attack-injection-php"] [tag "OWASP_CRS/WEB_ATTACK/PHP_INJECTION"] [tag "OWASP_TOP_10/A1"] [hostname "www.example.com"] [uri "/"] [unique_id "ZnK3jcMrFImDYlZf9CfMnwABwxc"]
[Wed Jun 19 06:48:45.253305 2024] [security2:error] [pid 409922:tid 22717533611776] [remote xx.xx.xx.xx:60528] [client xx.xx.xx.xx] ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "30"] [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 "www.example.com"] [uri "/"] [unique_id "ZnK3jcMrFImDYlZf9CfMnwABwxc"]
[Wed Jun 19 06:48:45.253596 2024] [security2:error] [pid 409922:tid 22717521004288] [client xx.xx.xx.xx:60528] [client xx.xx.xx.xx] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/RESPONSE-980-CORRELATION.conf"] [line "37"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5 - SQLI=0,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=5,HTTP=0,SESS=0): PHP Injection Attack: Configuration Directive Found"] [tag "event-correlation"] [hostname "www.example.com"] [uri "/"] [unique_id "ZnK3jcMrFImDYlZf9CfMnwABwxc"]
(edited because I accidentally included one trigger that was legit from a known bad IP. the above is from a legit test)
0 -
It does look like WooCommerce was aware of some issues earlier this year:
but I'm not sure if that's the same behavior you're seeing.
Ultimately, I don't have much else I can provide on my end - if the sites are tripping ModSecurity you'll have to choose to either turn it off or handle the blocks individually. That's really the only two options.
0 -
Thanks very much for your input cPRex
I know there's not much you can do or suggest, but I really do appreciate you trying. You go above and beyond to try to help as many people as you can on this forum. It would be easier on you (and all of us) if we could at least have chronological results in searches here. Digging through 6,543 "results" for the word modsecurity is darn near impossible.
The odd thing about this modsec situation - all of the sites I'm moving are on older CloudLinux 6.10 , older cPanel 110.x.x EOL with cPanel/OWASP modescurity enabled for years now with no problems. It is only the new servers creating these issues. I've compared the modsec main configs and settings between the old ones and the new ones, and cannot find any reason why modsec is getting triggered like a cat at a dog show on the new boxes.
I have a feeling there's outdated rules info on the new boxes, despite being new. Not sure how to "update" it, but still digging.
Thanks again for the responses and support. You are very much appreciated.
PS - I'm definitely reading the info at the link you sent, but FWIW - the same sites running on the old servers with modsec have zero problems with Woo - it is not until I transfer them to the new boxes that the trouble begins.
1 -
I actually upvoted this feature request to get a search order option included:
so hopefully they consider that one!
0 -
Hopefully they actually pay attention to that. The lack of valuable filters here is just a hot mess.
1
Please sign in to leave a comment.
Comments
15 comments