We think that good security journalism is something that could greatly help to improve the poor state of not just the security surrounding WordPress plugins, but security in general. Unfortunately what we have found is that security journalists seem to almost uniformly seem to do a very bad job. As a less serious example of that, recently we have seen odd responses from security journalists to us including proof of concepts with vulnerabilities we are disclosing.

Some of that seems like it could originating with the security company behind the Wordfence Security plugin, Defiant, who make claims like this (while waiting until after vulnerabilities are widely exploited to warn people that they are using plugins likely to be exploited, which is too late):

On Tuesday a security researcher made the irresponsible and dangerous decision to publish a blog post including a proof of concept (POC) detailing how to exploit a set of two software vulnerabilities present in the plugin.

A proof of concept largely reiterates information already provided with the walking through the vulnerable code, which Defiant does in their own posts describing the same vulnerabilities. So they either don’t understand something they should or are intentionally trying to mislead others (both possibilities would match with their past behavior).

There are certainly pros and cons related to releasing proof of concepts, but the reality is that they are not something that is usually hard to create. Take how we explained that with one recent vulnerability we discovered and disclosed:

It is important to note that the proof of concept was created by simply changing a single setting from the plugin’s default to include JavaScript code and another one to have the plugin’s functionality included on the home page, so that isn’t something hackers would have an issue creating on their own.

An example of the odd response from a journalist to proof of concepts came in relation to the vulnerability we wrote the previous comment about. They wrote this:

I purposely didn’t link to your post because it contained a PoC that was actively being used in the wild.

Payloads Are Okay

Another example of this odd response from Friday seemed much worse.

A Threatpost article linked to post from another security company, which basically copied their information from our post about an arbitrary file upload vulnerability we discovered and disclosed, but not to our post. A good reason for linking to the original source of information is that oftentimes people copying information get things wrong. And in this case that was true in a very serious way. In our post about the vulnerability we first talked about the fact that while it appeared at first glance that the file upload capability of the plugin was disabled by default, so there wouldn’t be a vulnerability by default, it turned out the setting wasn’t connected to the actual upload capability. Despite copying information from our post, somehow the other security company originally claimed that in fact you would only be impacted by the vulnerability if that setting was enabled, which they should have known wasn’t true (after we happened to notice them mentioning that false claim on Twitter their post was corrected). That also seems like a good indication that company isn’t a reliable source, but they are the cited source for the article (usage of unreliable sources is a common issue with the Threatpost).

Thought that actually is less of an issue than the other thing we noticed. As the article also includes this quote from a post unrelated to this vulnerability:

“We continue to see an increase in the number of plugins attacked as part of a campaign that’s been active for quite a long time,” according to John Castro with Sucuri in a recent post. “Bad actors have added more vulnerable plugins to inject similar malicious scripts.”

If you follow that link you will see there isn’t much content there, with a major chunk of it being this:

Those payloads are what actual hackers are sending to try to exploit vulnerabilities. If linking to proof of concepts is a problem, linking to that should be even more of an issue, but that was done, without it even relating to the vulnerability that was the subject of the article. It would be hard to make things up that were absurd than what is actually happening with security journalism.

Making linking to that seem problematic in another way is that at least one and maybe both of those payloads don’t work. Not because Sucuri removed something, but because hackers were exploiting vulnerabilities in ways that wouldn’t work. In the case of the first one, they were trying to exploit it as if the vulnerability was a different kind than it is. That Sucuri is apparently unaware of that seems like a good indication they are not the experts they claim to be (which isn’t something that isn’t already known) and seems like a good reason not to be given them free press coverage like that.