Wordfence Falsely Claimed Their Wordfence Premium Service Provided Rule to Protect Against Vulnerability
Two days ago, the WordPress security company Wordfence put out a blog post about a PHP object injection vulnerability they had found in the plugin Sassy Social Share. (We had detailed that vulnerability for our customers the same day it was fixed in September.) The post heavily markets their Wordfence Premium service, as in three separate instances they claim that they first provided a rule to protect against this vulnerability to customers of their paid Wordfence Premium service, which wasn’t available to those only using their plugin:
Wordfence Premium users received a firewall rule to protect against exploits targeting this vulnerability on August 31, 2021. Sites still using the free version of Wordfence received the same protection on September 30, 2021.
Disclosure Timeline
August 31, 2021 – Conclusion of the plugin analysis that led to the discovery of a vulnerability in the Sassy Social Share WordPress plugin. We develop a firewall rule to protect Wordfence customers and release it to Wordfence Premium users.
September 1, 2021 – The vendor confirms the inbox for handling the discussion.
September 2, 2021 – We send over full disclosure details. The vendor responds confirming they will begin working on a fix.
September 2-17, 2021 – We work closely with the vendor to ensure an optimal security patch is released by verifying the implemented fixes before they are released to customers.
September 17, 2021 – The patched version is released as 3.3.24.
September 30, 2021 – Wordfence free users receive the firewall rule.
Wordfence Premium users received a firewall rule to protect against any exploits targeting this vulnerability on August 31, 2021. Sites still using the free version received the same protection on September 30, 2021.
Looking back at the changes made to their free rules, these were only changes made on September 30 or the couples of days around it:
if (match(‘#/wp\-admin/admin\-ajax\.php$#i’, server.script_filename) and equals(‘pa_dismiss_admin_notice’, request.body.action, request.queryString.action) and currentUserIsNot(‘administrator’, server.empty)):
block(id=396, category=’auth-bypass’, score=100, description=’Premium Addons for Elementor < 4.5.2 Subscriber+ Arbitrary Options Update’, whitelist=0)if ((lengthGreaterThan(‘0’,request.files[‘rp_wcdpd_settings’], request.body[‘rp_wcdpd_export_settings’], request.queryString[‘rp_wcdpd_export_settings’]) or identical(”, request.body[‘rp_wcdpd_export_settings’], request.queryString[‘rp_wcdpd_export_settings’])) and currentUserIsNot(‘administrator’, server.empty)):
block(id=397, category=’auth-bypass’, score=100, description=’WooCommerce Dynamic Pricing & Discounts < 2.4.2 – Unauthenticated Settings Import/Export’, whitelist=0)
Neither of those are relevant to this vulnerability.
If you try to exploit the vulnerability on a website using their Wordfence Security plugin, it is blocked though. The log message for the block indicates that it was blocked due to this rule:
Thrive Plugins < 2021-05-11 Object Injection in POST
As you might guess from the date listed there, the rule has existed since June in the free version of the plugin. It hasn’t been changed since then.
If you are not familiar with how Wordfence operates, you would reasonably think there must have been a big mistake here, but if you are familiar, it isn’t really surprising. As they have gotten away with telling blatant lies to market themselves years without consequence. This lie is much less of a problem than, say, claiming there firewall “stops you from getting hacked” when it doesn’t and it is missing much of the protection it should provide. But with trust being such an important part of security, it doesn’t say good things about the state of it that a company clearly trusted by so many is so dishonest.
Wordfence Is Holding Back Important Protection
A security company lying should be a big deal, but even if you don’t care about that, there is a bigger issue here. The rule that protected against this instance of PHP object injection only applies in limited circumstances when malicious code is passed through inputs with certain names. That means that for many PHP object injection vulnerabilities, the plugin won’t protect against exploitation, despite it being easy for protection to be provided since all they would need to is to remove that limitation. We can’t think of a good reason not do to that. We say that based on that type protection being applied generally with our new Plugin Vulnerabilities Firewall without any issue (other protection the plugin provides has very degrees of possible false positives). One explanation for why they don’t do it is that the more general protection they provide, the less reason there is for people to buy the Wordfence Premium service.