Login

Tag Archives: ZDNet

18 Jun 2019

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.

11 Apr 2019

Why Are Journalist Spreading Wordfence’s (aka Defiant’s) Lies About Us?

Here’s a timeline of the recent situation with the WordPress plugin Related Posts (Yuzo Related Posts):

Yet here was Lawrence Abrams at the Bleeping Computer yesterday:

On March 30th, 2019, the developer of Yuzo Related Posts removed the plugin from the WordPress plugin directory after a WordPress security company publicly disclosed the vulnerability. While this prevented new users from being infected, the 60,000+ existing installs were not notified and thus were vulnerable.

 

The Yuzo developer took down the plugin on March 20th after the researchers at Pluginvulnerabilities.com publicly disclosed a proof of concept of the vulnerability.

And here was Catalin Cimpanu at ZDNet’s Zero Day:

Today’s massive hacking campaign could have been avoided if only the web developer who found the Yuzo Realted Posts plugin vulnerability would have reported the issue to its author instead of publishing proof-of-concept code online.

As a result of making this proof-of-concept code available for everyone, the plugin was removed from the official WordPress Plugins repository on the same day, preventing future downloads until a patch was to be made available.

However, this didn’t remove the plugin from all the sites around the world, which all remained vulnerable. At the time of its removal, the plugin had been already installed on more than 60,000 sites, according to official WordPress.org stats.

Things got so desperate today in the early hours of the attacks that the plugin’s author called on users to “remove this plugin immediately” from their sites until an update would be available.

If you read our original post it is largely is focused on the impact of closing plugins with security vulnerabilities, since it paints a target on them, yet somehow these article miss that the plugin was already closed when we warned about the vulnerability. What was going on? Well noticeable neither links to our post, but they do link to a post from Wordfence (aka Defiant) that lies about what happened. Right at the beginning they lie about the timeline:

The Yuzo Related Posts plugin, which is installed on over 60,000 websites, was removed from the WordPress.org plugin directory on March 30, 2019 after an unpatched vulnerability was publicly, and irresponsibly, disclosed by a security researcher that same day.

Here they make no sense, seeing as there was plenty of time to fix this and this was exploited well after our post, so who knows if the hacker was aware of our post:

As was the case a few weeks ago, the irresponsible actions of a security researcher has resulted in a zero-day plugin vulnerability being exploited in the wild. Cases like this underscore the importance of a layered security approach which includes a WordPress firewall.

Security journalists seem to have blindly repeated that line of thought and didn’t think through the fact that there was plenty of time for this to have been fixed before it was exploited, but it wasn’t. We have repeatedly offered to provide fixes for unfixed vulnerabilities likely to be exploited, which the WordPress Plugin Directory team could then check over and apply, but they have shown no interest in that. That would be something to cover.

Repeating claims made by Wordfence is not a good idea since we have seen for years that they don’t seem to have a problem with lying, especially if it involves a lie that makes them look better or makes someone else look worse.

One reason they might want to lie about this and not link to our post, is that not only could people could see they are lying, but also that we noted this in it:

If you were relying on other security companies, you were in trouble as they didn’t even know about that until well after the fact. For example, Wordfence wrote about this being exploited only on November 20 and started their post:

News broke last week disclosing a number of vulnerabilities in the AMP For WP plugin, installed on over 100,000 WordPress sites.

News didn’t break that previous week, which started November 11, seeing as we had already warned that hackers were targeting this as of six days before that (the person that wrote their post has the title of “threat analyst”, which apparently doesn’t mean much). That was rather problematic when you consider that Wordfence had to write a new rule to protect against this:

The Wordfence firewall has a new rule that defends sites against this exploit.

So they couldn’t protect against that until after they knew about it, which was well after the fact. At the point they were warning about this, the plugin had already been reopened, so they provided protection slower than simply keeping your plugins up to date.

We left this comment on Wordfence’s post:

We are the “security researcher” you are referring to here, though we are actually a service provider named Plugin Vulnerabilities. If you actually read our post on this vulnerability, https://www.pluginvulnerabilities.com/2019/03/30/wordpress-plugin-team-paints-target-on-exploitable-settings-change-vulnerability-that-permits-persistent-xss-in-related-posts/, you will see that we only became aware and warned about the vulnerability after the plugin was already closed. That occurred on March 30, so there was plenty of time for this to have been fixed before it was exploited.

Well they approve it? Probably not.

24 Sep 2018

ZDNet’s Zero Day Blog Claims to Have Revealed Something That We Had Already Discussed Well Beforehand

When it comes to actually trying to improve the poor state of web security one of the big impediments are security journalists, who often act not as journalists, but as stenographers repeating claims made by security companies with little concern for their accuracy or actual significance. A case in point with that comes from  a post from ZDNet’s Zero Day blog (which at least in the past was run by people that didn’t even understand what a zero-day is), titled “Thousands of WordPress sites backdoored with malicious code”, which we got notified due to a Google alert we have set related to WordPress plugin vulnerabilities.

It is not clear exactly how many websites are running WordPress, but one figure put out by Forbes was 75 million, so thousands of websites running it being hacked seems less than significant. In fact there doesn’t really seem to be anything significant about what is being described in the post. The problem with covering things like that is that it gives an inaccurate picture of security of WordPress, since certainly many more than thousands of website not running WordPress are also hacked each month and this can cause people to choose less secure software to use on their website because of skewed coverage. There are also plenty of issues surrounding the security WordPress that could be covered instead of this type of thing, but journalists don’t seem to be interested in covering more significant issues.

What could have made this significant is if the cause of the websites being hacked was something that people wouldn’t already know about and it requiring needing to do something new to protect themselves, but that wasn’t the case:

Researchers believe intruders are gaining access to these sites not by exploiting flaws in the WordPress CMS itself, but vulnerabilities in outdated themes and plugins.

It seems like it would be better to covering why themes and plugins are not being updated and what can be done about that, than trying to make a story of a few websites being hacked.

The worst part of the post comes at the end:

Last week, ZDNet revealed that attackers had been scanning the Internet in an attempt to exploit a recent vulnerability in a popular WordPress plugin.

While Sucuri did not find confirm that this vulnerability was now being used in this recent wave of site hacks, the company did confirm our initial report, based on WordFence’s telemetry.

ZDNet claims to have revealed that on September 12. What they are supposed to have revealed is actually just repeating a claim from Defiant (aka Wordfence), that hackers were doing scanning for a vulnerable file related to the Duplicator plugin. The thing about this is that we discussed that was already being exploited on September 7, based on discussions that had occurred on the WordPress Support Forum the day before. We notified the author of both ZDNet’s posts about that on September 13, but they not only didn’t update the first post, but acted like their being behind on this was actually revealing something in the second one.

Looking at the original post there are a couple of things that stick out there as well, first is this:

Several researchers who did not want to share their names for this piece told ZDNet that they found the Duplicator plugin installed on several top Alexa sites.

What would the researchers name matter there? But more importantly the security issue isn’t in the plugin itself, but in a file generated by it, so that would be what would matter if it existed on the websites.

The other is that the person from Defiant that is quoted in the article is the “Director of Threat Intelligence”, that is quite a title for someone that is less informed than someone that simply has an email alert set for the WordPress Support Forum, which is how we knew that vulnerability was being exploited apparently while Defiant was still only at the point of noticing probing going on (they have history of being behind or worse when it comes to that sort of thing).