One of the ways we help to improve the security of WordPress plugins, not just for our customers of our service, but for everyone using them, is our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. Through that we caught an authenticated option update vulnerability in the plugin HandL UTM Grabber, which can also be exploited through cross-site request forgery (CSRF).
This post provides the details of a vulnerability in the WordPress plugin ND Shortcodes not discovered by us, where the discoverer hadn’t provided the details needed for us to confirm the vulnerability while we were adding it to the data set for our service, so its contents are limited to subscribers of our service.
This post provides the details of a vulnerability in the WordPress plugin One Click SSL not discovered by us, where the discoverer hadn’t provided the details needed for us to confirm the vulnerability while we were adding it to the data set for our service, so its contents are limited to subscribers of our service.
This post provides the details of a vulnerability in the WordPress plugin WebP Express not discovered by us, where the discoverer hadn’t provided the details needed for us to confirm the vulnerability while we were adding it to the data set for our service, so its contents are limited to subscribers of our service.
The line between the open source project WordPress and the company Automattic is often blurry. You can find journalists referring to the latter as owning the former, despite that not being true. The person who resigned a couple of week as the Marketing and Communications Lead for WordPress mentioned that they were often assumed to be an Automattic employee or as the token non-Automattic team member:
My position is unclear, not just to me, but to many people which makes me uncomfortable. I’ve been asked dozens of times on Twitter, Facebook and at WordCamps why I now work for Automattic, which of course I don’t but that is the perception for a lot of people. On other occasions I seem to be the token non-Automattician, which I’m also uncomfortable with. [Read more]
One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. Through that we caught just such a vulnerability, an authenticated option update vulnerability, in the plugin WPMktgEngine. This vulnerability likely would have been widely exploited by now if the plugin was more popular, considering how easy it would be to detect it.
When it comes to the security of WordPress plugins what other security companies generally do is to add protection against vulnerabilities after they have already been widely exploited, which obviously won’t produce great results since there is a good chance the websites using their service have already been hacked by the time they do that. One of the ways we keep ahead of that is to monitor the closure of the 1,000 most popular WordPress plugins in the Plugin Directory, since that closure can be due to a security issue and even if it is not, we have found the plugins being closed often contain security vulnerabilities, and as was the case with one less than two weeks ago, ones likely to be exploited. Hackers seem to be doing that type of monitoring as well. Through that we found that the plugin Visual CSS Style Editor, which has 30,000+ active installs and was closed yesterday, has two vulnerabilities that when combined lead to a type of vulnerability hackers would be likely to exploit.
When we started to do a quick check of the security of the plugin after we were notified by our monitoring that it was closed, we found that were multiple basic security failures. For example, our Plugin Security Checker, which is an automated tool anyone can use to check plugins for possible security issues, correctly identified the possibility of a reflected cross-site scripting (XSS) vulnerability. But that isn’t a serious issue, so we went to look if there was something more serious that we should be warning our customers about instead. We found something that fit the bill, but there could be other issues as well. [Read more]
As the finding and exploitation of an authenticated option update vulnerability in the Freemius library, which is used by many WordPress plugins, by hackers shows is that there has not been enough focus on making sure that code that can lead to option update vulnerabilities is properly secured. Through our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities we have been on the lookout for some of those since November and we keep finding them, though as with the one we found in the plugin Estatik sometimes things are coded in way that limits the worst possible result of that (that doesn’t always appear to have been intentional). In this case of this plugin, poor security isn’t a new issue as we spotted the possibility that another vulnerability due to poor security was being exploited back in June of 2016.
The plugin registers for the function remove() in the class Es_Data_Manager_Item to be accessible through WordPress’ AJAX functionality to anyone logged in: [Read more]
On Monday while disclosing another option update vulnerability we noted that in the wake of one of those being widely exploited recently we had focused on finding more of those vulnerabilities, while it appears no one else in the WordPress security has done that (maybe because they can get away with lying about failing to protect against the widely exploited one). And no sooner than the next day did we find yet another vulnerability. We spotted it during our proactive monitoring of changes being made to WordPress plugins to try to catch serious vulnerabilities when they are introduced in to plugins, though the vulnerable code was not flagged by the software that we use to identify possible issues for us to review, instead that had flagged another possible instance of that same type of vulnerability in the same code and when we went to manually review the code we found the issue.
While the vulnerability doesn’t appear to allow for takeover of a website, it would allow for anyone logged in to WordPress to disable the website with a single request. Since the plugin in question, Dokan, is only usable with the WooCommerce eCommerce plugin, which is often set to create WordPress accounts for those making orders, that means that many or most of the 10,000+ active installations of the plugins (according to wordpress.org) would be impacted. It could also be exploited by getting someone logged in to WordPress to access a page controlled by an attacker. [Read more]
Back in June of last year we started doing proactive monitoring of changes being made to WordPress plugins to try to catch serious vulnerabilities when they are introduced in to plugins. Elements of that then became part of the basis of our Plugin Security Checker, an automated tool any one can use to check for possible security issues in plugins, which was introduced in October of last year. This week we replaced the previous system we had for handling the initial checking done as part of the proactive monitoring before a human becomes involved, with an expanded system that now incorporates more complex checking based off of code already included with the Plugin Security Checker. Just days into using that is has already help to detect a pretty nasty vulnerability in the plugin Smart Marketing SMS and Newsletters Forms, though one that looks like it could be used to knock a website offline, but not hack the website to gain control of it. The vulnerability is another one involving usage of the option_update() WordPress function that we have spotted recently, that function has recently been involved in the hacking of websites running WP GDPR Compliance and likely Kiwi Social Share as well.
Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then only trying to notify the developer through the WordPress Support Forum. You can notify the developer of this issue on the forum as well. Hopefully the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). [Read more]