The plugin 404page was closed on the WordPress Plugin Directory on Saturday. As that is one of 1,000 most popular plugins our systems alerted us to its removal and then we checked things over to see if there was a security issue that might have led to it being removed. While no reason had been given for its removal, in a quick check we found a minor, but rather nasty vulnerability that could an attacker to cause WordPress users to disable their access to the website without intending it. We then used WPDirectory to see if other plugins might have similar code and found that a number of other plugins by the same developer do. Subsequently to us doing that, the vulnerability was fixed in 404page and then subsequently that was credited to Julio Potier, so it appears that was the cause of the closure, but the other plugins have not been fixed yet.
When we announced a protest of the continued inappropriate behavior of the WordPress Support Forum moderators, one of the changes we suggested to resolve that was:
Yesterday one of the 1,000 most popular WordPress plugins, SMTP Mailer, was closed on the Plugin Directory. We are not following why it appears to be closed, as subsequent to the closure a new version was released with the following accurate chagelog entry, “SMTP Mailer no longer shows the saved password in the settings.”, and the plugin was reopened. Seeing as the password was shown on a page normally only accessible by Administrators and they normally have the ability to just about anything it isn’t clear what the issue was here that would justify the closure. When we went to try to get a better understanding of that we noticed there is a clear security vulnerability in the most recent version of the plugin, which could allow an attacker to cause logged in WordPress Administrators to send out emails without intending it.
Yesterday we noted how two of the most popular WordPress plugins were insecurely using the function extract(), as they were extracting the $_POST variable, which involves untrusted user input and the documentation for that function warns against:
One of the ways we keep ahead of others when it comes to vulnerabilities in WordPress plugins, so that we can provide our customers with better security is that we monitor third-party data for indications that hackers are targeting WordPress plugins. Through that we just ran across someone possibly probing for usage of the plugin Simple Ajax Shoutbox by requesting the readme.txt file for it. That isn’t a very popular plugin, with only 1,000+ active installations according to wordpress.org, and hasn’t been updated in two years.
In our previous post we detailed an authenticated arbitrary file upload that our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities caught in the plugin Child Themes Helper. It looks like there is quite a bit of inadequately secured code in the plugin, but one other issue that stood out is an authenticated arbitrary file viewing vulnerability.
One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. Through that we caught an authenticated arbitrary file upload vulnerability in the plugin Child Themes Helper, which is also exploitable through cross-site request forgery (CSRF). That occurs in an AJAX accessible function and it looks like a number of other ones are also insecure and contain vulnerabilities, one of the more serious we will detail in a follow up post.
One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities. Through that we caught a less serious variant of a local file inclusion (LFI) vulnerability, which allows for evaluating the code in a specified file, in the plugin Social Share Buttons & Analytics by GetSocial.io. In this case through cross-site request forgery (CSRF) an attacker could cause a logged in Administrator to include cause a file with the .php extension to be included in the context of a WordPress page being loaded (so it could, for example, be used to access a plugin’s .php files that have code to restrict direct access to them).
Last week through our proactive monitoring of changes made to WordPress plugins in the Plugin Directory to try to catch serious vulnerabilities we found a vulnerability that would be likely to be exploited in the plugin Social Warfare, which has 70,000+ active installations according to wordpress.org. Due the continued unwillingness of Matt Mullenweg or anyone on the WordPress team to rein in the inappropriate behavior of the moderators of the WordPress Support Forum the vulnerability got full disclosed and a lot of websites got hacked when they didn’t need to. The plugin was removed from the Plugin Directory after our disclosure and subsequently restored with the vulnerability removed, but the insecure code that surrounded it remained unchanged. That seems like something that team running the Plugin Directory should have caught since our post went through what the insecure code was, but they don’t seem to have a great grasp of security, which the inappropriate behavior of the moderators of the Support Forum helps to hide.