Snicco Falsely Claiming Competing WordPress Security Plugins Contain Vulnerabilities
Yesterday, the WPTavern ran a story with the headline “MalCare, Blogvault, and WPRemote Plugins Patch Vulnerabilities Allowing Site Takeover Through Stolen API Credentials” despite there not being a vulnerability. Instead, a competitor named Snicco had been successful in getting themselves press coverage with a false claim of a vulnerability in competing WordPress security plugins. Making the whole situation more unseemly, Snicco cites a situation that in reality highlights that not only does their very expensive plugin not deliver the claimed results but also that they appear to lack basic security knowledge.
WordPress Firewall Plugins Can Provide Unique Protection
That situation cited by Snicco involved a authenticated option update vulnerability that was widely exploited earlier this year, which had been in the WordPress plugin Elementor Pro. That vulnerability, like previously disclosed vulnerabilities of that type, was exploited to create new WordPress accounts with the Administrator role. There were a number of key takeaways from that situation that highlight issue with the security of WordPress websites and how that can be improved.
One takeaway is that lots of WordPress websites are not having plugin updates applied in a timely manner, as this vulnerability was widely exploited over a week after the fixed was released. That should give pause to ethical folks in the security industry, since security basics are often not being done while they are selling additional security (which isn’t necessarily going to provide better security over doing security basics).
Another takeaway is that the WordPress security industry isn’t doing a good job on improving security. This wouldn’t have been a vulnerability if not for the fact another plugin, WooCommerce, had an unaddressed security issue. The discoverer of the vulnerability, a security provider, disclosed a security bypass in WooCommerce, but it appears didn’t bother to notify the developer, Automattic, of it. Neither did Automattic’s own security provider businesses. Before the bypass was disclosed, we had notified the discoverer that would be a bypass. We assumed they would have notified Automattic about that. About two months later, upon running across another situation that would involve the bypass and finding it still existed, we notified Automattic’s security team, and they quickly resolved the issue.
The final takeaway from this that we will mention is that it is possible for WordPress firewall plugins to provide protection against how this type of vulnerability is widely exploited without having to know about the particular instance. That is possible when they are tightly integrated in to WordPress in a way that other security solutions can’t. While it is possible, only two plugins that we are aware of do that. Those are NinjaFirewall and our own Plugin Vulnerabilities Firewall. Notably, other more popular WordPress security plugins don’t provide that type of protection. Snicco’s very expensive plugin doesn’t either, while they claim that it “only targets security threats that can be most effectively handled at the plugin level”.
Snicco Fortress
Snicco’s security plugin, Snicco Fortress, is marketed with incredible claims. Here, for example, is the start of their marketing page for that:
Despite claiming that it is the “only WordPress plugin smashing real security threats“, it wouldn’t protect against the vulnerability we just discussed. Not only does it fail to provide protection against real threats that other plugins do, on that page they suggest using a firewall plugin is a bad idea:
A general-purpose WAF that checks for bad request parameters, SQL injection, or similar offenses is orders of magnitude faster and more effective at the web server level or CDN level.
We recommend the 7G Firewall for NGINX by Jeff Star.
Neither a web server level or CDN level web application firewall (WAF) can provide the same protection as those firewall plugins do, because they don’t tightly integrate in to WordPress. In line with that, the 7G Firewall they recommend provides very little of the protection those firewall plugins provide. In a test we did a year ago, we found that it provides significantly less protection than both those firewall plugins. Snicco cites nothing to back their claim that runs counter to a basic understanding of how firewall plugins can work and testing results.
Snicco’s plugin doesn’t appear to even be trying to provide needed additional security for any real security threats that almost any WordPress websites would face, despite claiming they are the only ones doing that. And despite that, for businesses they are charging $600 a year for the plugin and for enterprises their starting price is $12,000 a year.
“It Rather Involved Being on the Other Side of This Airtight Hatchway”
Instead of focusing on creating a better security plugin or even one focused on real threats, Snicco has taken to making false claims of vulnerabilities in competing security plugins.
Getting back to where we started, with the WP Tavern story, that was based on a claim of vulnerabilities in competing security plugins. The proof of concept Snicco provided for that would create a malicious WordPress Administrator user. Before you did that, though, there was this step:
Go into your database, and copy the “bvSecretKey” option from the wp_options table.
So the “vulnerability” would involve the website’s database being compromised already. How do they propose that happening? One of three ways was the Elementor Pro vulnerability we discussed earlier:
Other methods that allow reading or updating WordPress options (wp_options), such as this wildly exploited Elementor vulnerability.
Also, as we mentioned earlier, that vulnerability was widely exploited to create new Administrator accounts. So the attacker could already do what Snicco is claiming to be the vulnerability here without the security plugin they were smearing. There is a quote from the Hitchhiker’s Guide to the Galaxy that is referenced by security professionals for that type of claim, “it rather involved being on the other side of this airtight hatchway”.
Again, Snicco’s own plugin doesn’t even attempt to protect against a vulnerability they themselves acknowledge was widely exploited.
Another example they provide of how this could be exploited linked to a disclosure by GoDaddy of a security breach:
That involved an attacker gaining access to the Administrator passwords for websites, as well as other access that would allow them to gain that access:
- The original WordPress Admin password that was set at the time of provisioning was exposed. If those credentials were still in use, we reset those passwords.
- For active customers, sFTP and database usernames and passwords were exposed. We reset both passwords.
The remaining way they mention is at least not ridiculous, as it is through a SQL injection vulnerability that allows reading the contents of the website’s database. If there is that type of vulnerability, though, it could be significant on its own if sensitive information is stored in the database.
Another problem with them citing SQL injection as the way to exploit these “vulnerabilities”, is that they do that even with a security plugin that contains protection against that type of issue. In fact, they did it not once, but twice with Wordfence Security without even acknowledging that it has protection against that type of issue, much less showing how that protection could have been bypassed in a real-world situation.
Snicco Has Been Told This Before
While we have no evidence that Snicco has been informed that some of the misinformation they putting out there, like the claims about WAFs, are not true, they have stated that others in the space have told that these “vulnerabilities” are not vulnerabilities:
The vendors and WPScan now categorized the vulnerabilities as “security enhancements.”
Upon hearing this, we gave the code in question another 30-minute glance. We quickly found a way to elevate the “security enhancement” to a total site takeover by logging in as any user with 2FA enabled.
Understandably having lost faith in WPScan’s ability to resolve said vulnerabilities promptly, we contacted Patchstack with our findings, but they would/could not process them either due to the vulnerability requiring a (very commonly present) precondition.
(It’s unclear why Snicco was contacting third-party security providers instead of the WordPress Plugin Directory team if they were trying to get vulnerabilities in WordPress plugins resolved.)
You can read more about that in a post from WPScan. (We should note that WPScan itself frequently mislabels security issues as being vulnerabilities as well, but even they draw a line on that before Snicco does.)
WordPress Security Plugins Could Use More Criticism
Part of what makes what Snicco is doing so bad is that there is plenty of legitimate criticism that could be made of WordPress security plugins and services. Unfairly smearing a security provider, when there is plenty of legitimate criticism to be made about them, is unlikely to open up space for legitimate criticism.
Security providers are often pushing security features that are not needed on most websites and, as Snicco has themselves noted, can introduce additional security risk. Incredibly, though, Snicco doesn’t take that as an opportunity to suggest focusing on security that websites really need, but pushing some of the same security features they know can introduce additional security risk.