18 Jun

Why Did ZDNet Allow Disgruntled Security Journalist Catalin Cimpanu To Publish a Fictional Story on Their Zero Day Blog?

When it comes to security journalism, things are not in very good shape, which has a decided negative impact on improving security, whether with WordPress plugins or otherwise. Part of that seems to stem from the fact that many of the people doing security journalism don’t seem to have the skills necessary to do that. As an example of that, take something we ran across earlier this year when we were looking over someone’s Twitter account for more information related to a claim of a vulnerability in a WordPress plugin and ran across this tweet that they had retweeted:

The claim made by Catalin Cimpanu of ZDNet’s Zero Day blog made there isn’t true as can be seen by reading the linked to web page and as was noted in multiple replies, including:

Following journalistic standards, you would expected him to post a correction with or without also deleting the original tweet, but that didn’t happen.

We later used that as an example of the poor state of security journalism leading to this response from him:

What he appears to be referencing there, which he didn’t credit as his source, also doesn’t make the claim he did.

If that was a one off thing on Twitter we wouldn’t have mentioned it in the first place, but we have long seen him mentioning things in his story that are disputed by among other things, his cited sources for the claims.

A Fictional Story

So it probably isn’t surprising when he covered something involving us it is almost entirely fiction. Yesterday we noted how Automattic through the WooCommerce has been installing by default an insecure plugin by Facebook and that another Facebook plugin was also insecure. There is a lot that security journalists could be cover there considering that Automattic is closely connected to WordPress. What instead you got from him was “Disgruntled security firm discloses zero-days in Facebook’s WordPress plugins“. You don’t get past the headline without a mistake as we didn’t disclose any zero-days, which someone writing for a blog named the Zero Day should know (it isn’t the first time that has happened). But that is a small problem in comparison with other claims.

As protest of the continued inappropriate behavior of the moderators of the WordPress Support Forum we have been full disclosing vulnerabilities and only notifying the developers through that forum, until that inappropriate behavior is stopped. You can certainly criticize that or us for doing that, but instead this journalist makes up a different reality. It starts with this:

In a dispute that’s been raging for years, the Plugin Vulnerabilities team decided they wouldn’t follow a policy change on the WordPress.org forums that banned users from disclosing security flaws through the forums, and instead required security researchers email the WordPress team, which would then contact plugin owners.

None of that is true. We are not aware of any policy change nor have we disclosed security flaws through that forum, we always have done that on our own website.

It goes on:

For the past years, the Plugin Vulnerabilities team has been disclosing security flaws on the WordPress forums in spite of this rule — and having its forum accounts banned as a result of their rule-breaking behavior.

Again that isn’t true. Our account was banned, but that was due to our protest, not disclosing security flaws, since we didn’t do that in the first place. And then it gets real strange:

Things escalated this past spring when the Plugin Vulnerabilities team decided to take their protest a step further.

Instead of creating topics on the WordPress.org forums to warn users about security flaws, they also started publishing blog posts on their site with in-depth details and PoC code about the vulnerabilities they were finding.

Huh? We have seen similar claims in the past and it seems that people are getting false information from somewhere and when confronted with the fact it doesn’t match up with what they clearly see they create a fiction like this instead of realizing that they were getting false information to start with. Again we have always disclosed vulnerabilities we find on our own website, it doesn’t even make sense to us why we would do otherwise. That isn’t hard to see, if you go back through the post in the Vulnerability Reports category there are currently 41 pages and the first report is from March of 2016.

Concluding Fiction

If you look at either of our posts about the vulnerabilities we explain the full disclosures:

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 leaving a message about that for 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). You would think they would have already done that, but considering that they believe that having plugins, which have millions installs, remain in the Plugin Directory despite them knowing they are vulnerable is “appropriate action”, something is very amiss with them (which is even more reason the moderation needs to be cleaned up).

You can certainly disagree or criticize that, but instead he concludes his article with more fiction about that:

Their excuses are flimsy, to say the least, as their record of past disclosures shows they aren’t really trying that hard to notify developers, and are merely making a spectacle on the WordPress forums about their ability to find vulnerabilities as part of some misguided marketing stunt for a commercial WordPress security plugin they are managing.

We don’t have a commercial WordPress security plugin, so there couldn’t be marketing stunt for that.

The person here that seems to be misguided is not us.

Missing the Point Entirely

Earlier he wrote:

In an explainer the company posted on its blog, Plugin Vulnerabilities tried to justify its course of action by claiming Facebook’s bug bounty program isn’t clear if the company’s WordPress plugins are eligible for rewards, and tried to pin the blame on the social network for limiting access to the program only for users with a Facebook account.

We didn’t say anything like that, here is what he seems to be referring to, though from a post that as you can guess from its title, is very different, “Hey Facebook, a Bug Bounty Program Isn’t a Replacement for Properly Reviewing the Security of Your Code“:

(Even if we were not currently full disclosing vulnerabilities we likely couldn’t participate in that program since they state “You give us reasonable time to investigate and mitigate an issue you report before making public any information about the report or sharing such information with others.” and we need to notify our customers in a timely manner about vulnerabilities in the plugins they use. You also need a Facebook account to be even be able to report a vulnerability to them, which seems like an unnecessary hindrance in people trying to notify them of vulnerabilities.)

As you might guess from the parenthesis, that was an aside from what the post was focused on and that refers to not participating in a bug bounty program, not the method of disclosures. You can notify a developer about vulnerabilities without participating in a bug bounty program.

Getting Security Details Wrong To

Even when sticking to disclosing the vulnerabilities in question he gets things wrong, the title for one of our posts was “Facebook’s WordPress Plugin Messenger Customer Chat Contains an Authenticated Settings Change Vulnerability” and yet the story claims:

They published details about two cross-site request forgery (CSRF) flaws that impact the two aforementioned Facebook WordPress plugins.

While there was CSRF competent, that was not the main vulnerability, which was mentioned right in the title.