On Friday the plugin myStickymenu was closed on the WordPress Plugin Directory. In a quick check over the plugin we found that it contained two minor vulnerabilities. The next day changes were made to address both of those vulnerabilities. The more serious of those is a cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability that existed on the plugin’s settings page.
…
The Subversion log entry for a recent revision of the plugin Zoho SalesIQ is “added security bug fix”. Looking at the changes made in that version we found that a cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability had been fixed.
…
The changelog for the latest version of the WordPress plugin Ultimate FAQ is “Fixes a minor possible XSS issue”, we don’t know where the possible part comes from since that fixes a vulnerability and when we contacted the developer about that vulnerability we offered to provide them a proof of concept that confirmed that vulnerability was in fact exploitable. Vulnerabilities being inaccurately referred to as a possible or potential vulnerability isn’t an uncommon issue. By comparison the changelog for the latest version of Custom Field Suite is “Fix: prevent possible XSS for logged-in editors or admins (props reddy.io)” and what was fixed there would actually be a described as a possible vulnerability, since it involves allowing those users to do something they normally are permitted to do anyway due to them normally having the “unfiltered_html” capability.
Unfortunately, unlike us, other data sources don’t seem to care much for accuracy as that was added to the CVE’s data without that important qualifier: [Read more]
The changelog for the latest version of Pretty Links is “Fixed some security issues”. Looking at the changes made we found that protection against cross-site request forgery (CSRF) was added for various actions that are restricted to users the “manage_options” capability (so Administrators). Those included the actions to create, update, and delete links handled by the plugin. We found that when creating a link you can also cause cross-site scripting (XSS) to happen, which isn’t normally a vulnerability for users with the “manage_options” capability, though should probably be fixed as well.
…
One of the changelog entries for the latest version of Advanced Woo Search is “Dev – Update security checks”. That description isn’t entirely accurate as when we looked into what was changed we found that security checks were previously missing and had in fact been added, not updated, in the new version. At least from our quick check over it looks the most serious issue fixed by that change was that there was previously a cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability on the plugin’s settings page.
…
As part of our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities we manually look at a lot of code that doesn’t end up leading to the vulnerability that is being flagged as possibly being caused by the automated portion of that, but sometimes, as is the case of LeaderBoard LITE (LeaderBoard Plugin), we find another vulnerability in the same block of code as where the possible vulnerability was flagged. That is a brand new plugin that was supposed to go through a security review before being allowed in the Plugin Directory. The situation could actually be worse, if not for some of the insecure code in the plugin being broken.
In the plugin, what was flagged was this line which handles a file upload: [Read more]
The WordPress plugin ARI Adminer was recently flagged by monitoring we do due to a possible security issue, though what was flagged turned out to not be an issue. Seeing as database administration tools introduce increased security risk over the average plugin we did a little further checking over the plugin to see if it had any obvious security issues and we found that it contains a vulnerability. What we found was that the functionality to add a new database connection lacks protection against cross-site request forgery (CSRF), though unlike some recent vulnerabilities where that problem was the tip off the iceberg toward a more serious issue, this time it looks like it only would allow an attacker to cause malicious JavaScript code to be included on some of the plugin’s admin pages.
In looking over the underlying code what we found was that it would be hard to actually follow how it works, which is a reminder that just looking at code can be a bad way to effectively identify security issues. That is something we are well aware from our security reviews of plugins, where we combine both checks of the underlying code as well as accessing functionality in a web browser. [Read more]
Three of the 1,000 most popular plugins in the WordPress Plugin Directory were closed on Saturday and all three contain vulnerabilities. With the plugin Social Login, Social Sharing by miniOrange (WordPress Social Login (Facebook, Google, Twitter)) what immediately stood out as we started doing a quick check of its security is that the code looks incredibly insecure, so the vulnerability we are disclosing may not be the most serious and certainly doesn’t look like it is the only one.
While our Plugin Security Checker flags the possibility of a reflected cross-site scripting (XSS) vulnerability, which in a quick glance seems to exist, that would take more time to look into than something else that we came across. When changing the plugin’s settings there is no check for a valid nonce, so an attacker could cause a logged in Administrator to change the settings without intending it, otherwise known as cross-site request forgery (CSRF). That cSocial Login, Social Sharing by miniOrangean be used to cause malicious JavaScript code to be shown on the plugin’s admin page (and possibly on frontend pages), which is cross-site scripting (XSS). [Read more]
The changelog entry for the latest version of Import users from CSV with meta is “Security fixes to prevent Reflected Cross Site Scripting (XSS) and Cross Site Request Forgery (CSRF), thanks to Application Security for reporting”. Looking at the changes made in that version we confirmed that a cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability was fixed in that version. That isn’t the first time someone has reported CSRF vulnerability in the admin functionality, as we did that related to other functionality in September of 2016. Looking further we found that they still didn’t fully resolve the issues with that, which we will detail in a follow up post.
…
Recently we detailed an attempt to fix a reflected cross-site scripting (XSS) vulnerability in the plugin Smart Forms after noticing the changelog entry for the version that occurred in was “Security fix.”, it turns out there were other vulnerabilities that were actually fixed in that version, though confusingly the discoverer of one of them states that it was fixed in a different version and they missed the full scope of what they noticed. Earlier today the JPCERT/CC released a report crediting Masaki Saito of TDU Cryptography Lab for discovery of a cross-site request forgery (CSRF) vulnerability in the plugin. The report states that “Smart Forms 2.6.15 and earlier” were impacted. When went to check over things though we found that there were no changes in the subsequent version, 2.6.16, that would have fixed that type of issue despite the suggested solution being “Update the plugin”.
…