Plugin triggers ModSecurity

  • Hello Matt and Devin,

    I thought you might want to know that I can confirm the same issue that user “artxlb” posted in https://www.ads-software.com/support/topic/server-security-problems-caused-by-give?replies=1 does indeed exist. I have no relation to “artxlb” but I noticed his thread when I arrived here this morning researching the same issue for a hosting client of mine.

    I can also provide you some more detailed information that could be useful to you.

    Server Environment – CloudLinux 6.7 (based CentOS 6) with cPanel 11.56 latest “release” tier, suPHP, ModSecurity 2.5.x with WAF Comodo rules, Apache 2.4.18, PHP 5.5.49

    WordPress – version 4.5.3 with Twenty Sixteen default theme

    “Give” Donation Plugin – version 1.5.2

    Symptom Brief – When admin user logs in to Dashboard, the Give Plugin triggers ModSecurity rule # 220030 multiple times and user IP is blocked in server’s firewall as the Give Plugin calls the icomoon.ttf and icomoon.woff font files.

    Detailed Symptom Output (with user IP address and actual domain changed for security) from Apache log during the trigger looks like this:

    [Sun Jul 24 05:30:03.337332 2016] [:error]  [client xxx.xxx.xxx.xxx] ModSecurity: Access denied with code 403 (phase 1). Pattern match "^(-(a|b|C|q|T|c|n|d|e|f|h|\\\\?|i|l|m|r|B|R|F|E|S|t|s|v|w|z)|--(interactive|bindpath|no-chdir|no-header|timing|php-ini|no-php-ini|define|profile-info|file|help|usage|info|syntax-check|modules|run|process-begin|process-code|process-file|process-end|server ..." at QUERY_STRING. [file "/usr/local/apache/conf/modsec_vendor_configs/comodo_apache/22_PHP_PHPGen.conf"] [line "17"] [id "220030"] [rev "2"] [msg "COMODO WAF: Vulnerability in PHP before 5.3.12 and 5.4.x before 5.4.2 (CVE-2012-1823)||www.example.com|F"] [hostname "www.example.com"] [uri "/wp-content/plugins/give//assets/fonts/icomoon.ttf"] 

[Sun Jul 24 05:36:12.493234 2016] [:error] [client xxx.xxx.xxx.xxx] ModSecurity: Access denied with code 403 (phase 1). Pattern match "^(-(a|b|C|q|T|c|n|d|e|f|h|\\\\?|i|l|m|r|B|R|F|E|S|t|s|v|w|z)|--(interactive|bindpath|no-chdir|no-header|timing|php-ini|no-php-ini|define|profile-info|file|help|usage|info|syntax-check|modules|run|process-begin|process-code|process-file|process-end|server ..." at QUERY_STRING. [file "/usr/local/apache/conf/modsec_vendor_configs/comodo_apache/22_PHP_PHPGen.conf"] [line "17"] [id "220030"] [rev "2"] [msg "COMODO WAF: Vulnerability in PHP before 5.3.12 and 5.4.x before 5.4.2 (CVE-2012-1823)||www.example.com|F"] [hostname "www.example.com"] [uri "/wp-content/plugins/give//assets/fonts/icomoon.woff"]

    The strange thing is that, as you can see, the vulnerability being detected is an old one apparently from 2012 with PHP versions below 5.4.2, and yet the server is running PHP 5.5.49. It seems as if the Give Plugin code reflects or references older PHP version syntax despite the Plugin being the most recent version update (1.5.2 , 3 weeks ago) from WordImpress.

    Troubleshooting and verification method:

    – Ensure latest version of WordPress properly installed
    – Used WordPress default Twenty Sixteen theme
    – Disabled Plugins one at a time while testing

    * Problem goes away only when “Give – Donation Plugin” is deactivated *

    Temporary work-arounds:

    – Deactivate / don’t use “Give – Donation Plugin” OR
    – Disable ModSecurity Rule ID 220030 for user’s hosting account on server

    Since disabling the ModSecurity rule is not a permanent nor ideal solution as it’s there to protect user’s site & scripts, I’m hoping that the information I’ve provided above might help lead to a permanent fix.

    I’m sure you guys are extremely busy, so I’m wondering – do you think a near-future fix for this is possibly forthcoming?

    If there is any other information I could provide that might be helpful just let me know and I’ll do my best.

    Thanks guys!

    https://www.ads-software.com/plugins/give/

Viewing 11 replies - 1 through 11 (of 11 total)
  • Plugin Author Matt Cromwell

    (@webdevmattcrom)

    HI there,

    Thanks for the detailed response. I’m not sure whether this requires a fix from Give yet. It could be a false-flag, or potentially you are running an older version of ModSecurity. Regardless, I’m digging into replicating the issue locally in order to understand the source of the problem better.

    Regarding the PHP notice, naturally, we do have to occassionally use older PHP syntax in order to be compatible with hosting environments which run on older versions of PHP. That still doesn’t mean there is a vulnerability.

    Lastly, if you are ever concerned about anything security related, please do not post here in the forum. If you did find a security issue, you would effectively be making it public where nefarious types could then exploit anyone running our plugin. Instead of posting here, contact us directly through our contact page and choose the option “I am reporting a security vulnerability”.

    I’ll keep you posted on my progress. Thanks!

    Plugin Author Matt Cromwell

    (@webdevmattcrom)

    Can you direct me to where you are getting your ruleset from? Is this a default ruleset from your host? If so, what host are you using? If not, can you point me to a public place where I can download the ruleset?

    Thanks!

    Plugin Author Matt Cromwell

    (@webdevmattcrom)

    In the meantime, let’s also try this. Please download this zip file:
    https://www.dropbox.com/s/ti2biwyeoa5e3hk/give-fonts.zip?dl=0

    These are the icomoon fonts that we use, but I just re-generated them directly from the iconmoon App. Please do the following:

    1) Unzip the file
    2) Upload the contents (4 font files total) to your Give plugin folder to the following location:
    /wp-content/plugins/give/assets/fonts/
    3) Activate the plugin again and let me know if you get the same warnings.

    Thanks!

    Thread Starter anotherdave

    (@anotherdave)

    Hi Matt,

    Thank you very much for responding.

    Sorry I wasn’t as detailed / clear in the original post – I am the host. I’ve been running a small hosting service since 1996 (before Godaddy and Google even existed) and I started hosting WordPress sites in early 2004. Currently about 200 of the web sites I host are customers using WordPress, many of which I installed WP for them and several of which I do the basic WordPress maintenance for (since many users either aren’t aware that they need to keep WP and Plugins / Themes updated or are afraid to do it themselves). Many of them have very extensive sets of Plugins installed and no issues.

    The ModSecurity ruleset in use on my servers is the common one that is built into the latest version of cPanel/WHM 11.56 – COMODO ModSecurity Apache Rule Set , latest version 1.87 – and you can see the complete ruleset at https://waf.comodo.com/user/cwaf_revisions (you can also download the ruleset there, with a free account).

    If you have root admin access to a cPanel server running cPanel/WHM 11.48 or higher, you can log in to WHM and then go to Security Center > ModSecurity Vendors to view / enable / disable / edit the ruleset just like you can see in this old thread on the Comodo forums from over a year ago when the Comodo WAF rulset was first integrated and implemented by cPanel – https://forums.comodo.com/free-modsecurity-rules-comodo-web-application-firewall/comodo-as-a-modsecurity-vendor-in-cpanel-t110147.0.html

    Given the fact that the CVE is from 2012 and the rule being triggered by Give is:

    [id “220030”] [rev “2”] [msg “COMODO WAF: Vulnerability in PHP before 5.3.12 and 5.4.x before 5.4.2 (CVE-2012-1823)

    It’s possible that it’s a false positive due to some older syntax mixed in with your plugin, but either way it will still cause users on servers running the latest version of cPanel with the latest version of Comodo WAF ModSecurity for Apache to run into problems and/or get blocked from their server when they attempt to access their WP Admin Dashboard with Give installed / enabled.

    I followed your suggestion and downloaded the zip file of the icomoon fonts that you’ve provide at https://www.dropbox.com/s/ti2biwyeoa5e3hk/give-fonts.zip?dl=0 and then unzipped / uploaded them to the /wp-content/plugins/give/assets/fonts/ folder (overwriting the existing ones already there). I then re-enabled ModSecurity rule ID 220030 on the user’s account and logged into his WP admin Dashboard, and it still triggers the rule.

    I’m disabling the Give plugin on the user’s account for now so that they can log in to their Dashboard without getting firewalled and letting them know that I’m working with you to find a better solution than disabling the ModSecurity rule.

    By reading through your support forum here I can see that you are a responsive developer who actually cares about your plugin, so kudos for that! Since I host hundreds of WordPress sites I have to deal with a lot of plugins on behalf of customers and I wish all of them cared about their product as much as you do.

    In fact, I would be more than happy to set you up with a test hosting account on one of my servers with a clean fresh installation of WordPress for you to experiment with in my very modern server environment, and would be happy to work directly with you on this if you’d like. If you’re interested just send me a private message with your direct email and I’ll contact you via my direct email (and phone if you’d like) since I do not post my company information here on the www.ads-software.com forum (mainly because I think it would break the rules & possibly considered spam, but also because you know I’d have everyone on the forums contacting me for support day & night).

    It would be great to work with you directly outside of this forum, so just shoot me a private message if you’re interested. It would be good for both of us – for you because I can give you a real-time troubleshooting environment to assist you with this, and for me because we could eventually resolve this issue for my customer using your plugin ??

    Side note – I’m preparing to upgrade the native PHP from 5.5 to 5.6 on all of my servers, but I do have the ability to set individual accounts to any version from PHP 5.4 to PHP 7 for testing purposes. Nice for development / troubleshooting.

    Hope to speak with you soon,
    Dave

    Plugin Author Matt Cromwell

    (@webdevmattcrom)

    Hey Dave,

    We’re looking deeper into this and can’t reproduce it without the ModSecurity setup you have. Please contact us at https://givewp.com/contact so we can discuss in more detail.

    Thanks!

    Plugin Author Matt Cromwell

    (@webdevmattcrom)

    HI Dave,

    We want to experiment with just removing that icomoon.ttf file. We don’t believe any modern browser or mobile device will actually load it. Please try deleting your current copy of Give, and install this copy instead:

    https://www.dropbox.com/s/srv2i1clpbg33fe/give.zip?dl=0

    Then run your ModSecurity rule and let us know what you find.

    Thanks!

    Did anyone ever come up with a fix to this. I am having this same issue right now with the give plug -in.

    Plugin Author Devin Walker

    (@dlocc)

    @rfelton What version of the plugin are you using? This should be fixed in the latest version as the .ttf file being flagged was removed. Do you know which file is being flagged now?

    Hi Devin
    Looks like Version 3.
    wp-content/plugins/give/assets/fonts/icomoon.woff

    Requires at least: 4.2
    Tested up to: 4.7
    Stable tag: 1.7.2
    License: GPLv3
    License URI: https://www.gnu.org/licenses/gpl-3.0.html

    Plugin Author Devin Walker

    (@dlocc)

    Thanks @rfelton – do you have any additional information as to why this is being flagged?

    All I really could get was it was triggering a rule on the mod security. Im on a vh server. I had the plug in running for a month before this happened and it only happened while I was working on it. Im guessing that it may have happened because I had set up a couple of wp installs in other sub domains as a test environment. I had the plug in on all of them so it may have been making calls from all those installs. When they white listed it at first it wasn’t working. I finally un-installed it except for one location and they did a global whitelist and since then I havent had any issues.
    Thanks for looking out. I can get the chat transcripts from the support chat if you want but what was outlined by this other gentleman is exactly what happened to me but of course with a different font file.

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘Plugin triggers ModSecurity’ is closed to new replies.