pluginvulnerabilities

Relying on a black box security score to determine whether you should use a plugin doesn’t seem like a good idea in general. In this case not only does the company behind it not have a great understanding of security based on what we have seen in the past, but another plugin that has what would probably be described as a moderately serious vulnerability in its current version, which is flagged as a possible issue by another automated tool, gets a score of 0 with this tool, so the results don’t seem all that reliable.

In regards to database queries, in our checking we only found that there were only five that could run (one more is commented out) and all them look to be properly secured using prepared statements, so there doesn’t appear to be any issue in that regard or any reason to change the plugin’s usage of database queries.

Our plugin tells you if the installed version of a plugin contains a vulnerability that we have seen hackers trying to exploit, not that “something is bad”. The best way to protect against those vulnerabilities is for plugins to be updated to a version that fixes the vulnerability. We have helped to get many of the vulnerabilities listed in this data fixed and in many cases we were also the ones that spotted that hackers had discovered and were exploiting them as well. That means we have helped a lot of people without them ever knowing it. If the vulnerabilities haven’t been fixed, then removing the plugins is going to provide as good or, based on our testing, much better protection than any claimed active protection provided by plugins and services.

The other company you seem to be a fan of, is instead focused on making websites reliant on their plugin and service, which is probably why you are not aware that we have done a lot more to improve the security of the WordPress ecosystem than them. In the past they have even intentionally not credited us when posting about a vulnerability we discovered and disclosed.

If you had actually visited our blog you would have seen that one of the most recent posts detailed how our contacting the developer of a plugin with a publicly disclosed vulnerability helped to get it fixed in less than four hours later. That is the kind of thing we are doing all the time, but it isn’t something that gets much coverage.

If you are aware of evidence that there is another company that does more than we do when it comes to improving security of the WordPress ecosystem we would love to see it, because we haven’t seen anything that indicates that even much bigger companies are doing more.

The post you are linking to, which is from our website, relates to a vulnerability that had previously been in the plugin Save Contact Form 7, not Contact Form 7.

If a website has been hacked through a plugin there should be evidence in log file(s) of HTTP activity, so that is what you would want to be reviewing to determine the source of the hack.

It looks like the problem is that the version number listed in the file /tags/4.1.14.1/business-directory-plugin.php is 4.1.14 instead of 4.1.14.1.

@jonryan
If you read the posts above, what is being reported is that there are people abusing the ability to upload image files through this plugin. The change made in 1.26.2 only “Prevents use of Ajax file upload endpoint for visitors who aren’t logged in”, it isn’t clear what vulnerability that was supposed to resolve since by default anyone can still upload image files through the plugin after that change.

@etheos proposal seems like it might be a reasonable thing to try to resolve the abuse of this.

Plugin Vulnerabilities here, our only involvement with this plugin was to notify the developer that the first time they attempted to fix a vulnerability in it, the fix was incomplete. We had nothing to do with the removal of this plugin from the Plugin Directory and we can’t do anything to restore it.

As cravaus mentioned, the return of the plugin would involve the developer and the people behind the Plugin Directory resolving the issues they have.

@ipstenu
We were providing them a reminder because we had not gotten a response yet (which in another recent situation helped to get an issue resolved), not anything else.

We easily found the vulnerability after coming across this thread, so if someone wasn’t already exploiting the vulnerability (the issue of a vulnerability being exploited was raised before we joined in the thread), there isn’t a reason to believe that others could have figured out without us saying anything (we certainly don’t have unique expertise when it comes to doing that).

Considering that you should know that there are vulnerabilities being exploited in plugins that never get fixed, your continued stance to “err on the side that limits public exposure before a fix is out” is irresponsible at best.

We are probably going to take a pause notifying the Plugin Directory of disclosed vulnerabilities because doing work that people on the WordPress side should be handling, when they continue taking actions that are harmful to security of WordPress websites, doesn’t seem to be the best use of our resources.

@macmanx
We haven’t done any public disclosure yet, we privately notified the developer and included a reminder that we had contacted them in the part of our message you removed (so the public can’t see what really happened). You don’t seem to understand what disclosure is and you have made a mess of this situation, which is unfortunate (even worse is that once again the moderators here don’t seem to be even consider that they don’t what they are doing).

Removing the plugin slows down the process of getting a fix out if the developer is responsive, that is why it is suggested that “Every attempt to contact the developer directly should be made before you reported the plugin to us”. The Plugins Team will only remove the plugin and inform the developer again, but they don’t fix it. If the plugin wasn’t removed the developer could simply put out a fixed version and people could start updating, but with it removed additional steps will have to happen that slow things down.

Now we will need to disclose the vulnerability before it is fixed, which is what we were trying to avoid.

@macmanx
We didn’t disclose any vulnerability here, but no one can see that because you have removed the rest of our message despite nothing inappropriate being in that.

If you actually read the page you linked to you would see that it says:

In the case of serious exploits, please keep in mind responsible and reasonable disclosure. Every attempt to contact the developer directly should be made before you reported the plugin to us (though we understand this can be difficult – check in the source code of the plugin first, many developers list their emails).

Which is what we were in the process of doing, but now you have gotten in the way of that.

If you can undo your actions we can delay disclosure, but otherwise we will need to go ahead with that to warn our customers and the users of our plugin that they are vulnerable.

@dualcube
The files listed earlier still contain malicious code, so you really need to do more than just create a new demo as the page for the plugin here and probably others still link the old demo that contains malware due to those files.

[removed by moderator]

• This reply was modified 7 years, 11 months ago by James Huff.
• This reply was modified 7 years, 11 months ago by James Huff.

@maggieymae
There hasn’t been any evidence that the plugin is vulnerable provided so far, only that a potential vulnerability exists.

The developer can easily fix the issue. We have sent them an email to let them know about this discussion and the issue.

@tommarshall
You are spreading the claim though and you didn’t provide any disclaimer as to the reliability of the claim when doing so originally. Raising the issue is fine; it is how you raised it that is the issue.

The WPScan Vulnerability Database doesn’t verify vulnerabilities before including them in their data, so the real issue is with services and people spreading their information without proper warning about that and other known reliability issues (including them incorrectly marking vulnerabilities as being fixed). If the monitoring you are using doesn’t do that you should take that up with them and or get your data from a source that actually checks claimed vulnerabilities before adding them to their data (full disclosure: we provide just such a service).

A lot of those attempts are trying to exploit malicious code that might be on a website due to another attack, so they wouldn’t be of any use in terms of protecting against vulnerabilities in the WordPress core, plugins, or themes.

As for the claim of numerous honeypots at big security vendors to record these behaviors, they either don’t exist or they are not useful in catching many vulnerabilities being exploited in the current versions of WordPress plugins at the very least, as we are the only ones that are spotting many of those vulnerabilities. It isn’t that we are just faster at spotting them and making sure that something is done about them, since before we started doing that there were many not being spotted, as we have found vulnerabilities that existed in the current version of plugins that hackers were likely exploiting for a year or more before we started doing that. It would probably be good for WordPress to start monitoring for that type of activity, since relying on a single company to do that is far from ideal.

As for the claim that the probing is for un-updated stuff, it would be great if that was true as well, but in many cases it isn’t. We are currently seeing a lot of probing for plugins from a set intentionally malicious plugins that were in the Plugin Directory several years ago. Since they were intentionally malicious, they were never going to get fixed by the developer and WordPress hasn’t fixed them in the years since they were discovered, so anyone still using them (and there are websites still using at least some of them recently) is open to be exploited.

As for the data on wpvulndb.com, it is important to note that there are a lot of known vulnerabilities that are not included in their data, so just checking there won’t provide a full listing of vulnerabilities that have existed in a plugin. Also the vulnerabilities are not tested when added to their data, so among other issues, the vulnerability might be listed as being fixed in a certain version despite that not being true. So when looking at their data you should double check that the vulnerability has actually been fixed or use a data source that actual does that checking for you.

When you say that it can be “can be manipulated by the visitor”, were you actually able to cause this to be exploitable?

We were contacted by the person behind this claimed vulnerability a couple days ago and we asked if they were actually able to cause it to be exploitable, but haven’t gotten a response. In our looking into this it looks like it might not be possible to do that, since it looks like the value of HTTP_HOST would not be able to be manipulated in a web browser.

At the top of that report it states that the vulnerability was patched in version 2.1.79 of the plugin.

That looks to have fixed the issue they identified. Thank you.