15 Apr

Ars Technica and Dan Goodin’s Idea of Good Faith (or You Can Find a Much Better Security Reporter Ars Technica)

While the news outlet Ars Technica seems to do good journalism in general, when it comes to security, at least with their writer Dan Goodin, you get the kind of poor excuse for journalism that is so much of security journalism. Five years ago over at our main business we happened to look at one of his articles  “Ancient Linux servers: The blighted slum houses of the Internet” and found that the basic premise of the article was false, as the hacked websites were not even all running Linux. That led to someone leaving a comment on the story that ended:

Step up your security report Ars. Or stop it altogether. The choice is yours. Or our choice should be not to read your security reporting.

Five years on his reporting hasn’t gotten better, and it seems Ars Technica doesn’t have a problem employing someone that lacks the basic skills to properly report on security, like reading comprehension. Furthermore he seems interested in insecurity, instead of security, much to the detriment to Ars Technica’s readers.

A few weeks ago we emailed him about a story on the exploitation of vulnerabilities in couple of WordPress plugin, one thing we noted was this:

It also worth noting that vulnerabilities related to the vulnerability
exploited in Easy WP SMTP still haven’t been fixed:

The response to that was:

Can you  point me to the specific part of the post that says the Easy WP SMTP vulnerabilities under active exploit have not been fixed?

We are not sure how he got from what we said to what he said. If you look at the story you will notice that it wasn’t updated to note that, which seems like something that would have been done if this guy was concerned about security. The rest of that story isn’t really focused on security, as the advice given is:

As noted earlier, sites that use either of these WordPress plugins are at immediate risk of being compromised and should update at once. In the event updating isn’t immediately possible—for instance, if updates cause crashes as some users of Social Warfare claim—website developers should disable the plugin until an update is successful

Telling people to take an action after widespread exploitation does nothing for the next time it happens. Just telling people to keep their plugins up to date at all times would have been worlds better.

Good Faith

Last week we got an email from him, reading it, what came across was that he was preparing a hit piece since it seem overly focused on when vulnerabilities were disclosed and not the other issue that surrounded those disclosures (like the closure of plugins):


Ars Technica reporter Dan Goodin here.

I’m working on a story about the recent WordPress plugin vulnerabilities that have come under active exploit. It seems that in several of the cases, Plugin Vulnerabilities disclosed vulnerabilities and then those same vulnerabilities came under active attack.

That seems to be the case with the the following:

— On March 21, Plugin Vulnerabilities disclosed a settings change/persistent XSS in Social Warfare. This post mentioned the same Full Disclosure policy in protest of inappropriate behavior.

Full Disclosure of Settings Change/Persistent Cross-Site Scripting (XSS) Vulnerability in Social Warfare

At the time this post went live, there was no patch available. There were also no reports of in-the-wild exploits. Shortly after the Plugin Vulnerabilities post went live, the vulnerability was exploited in the wild.

— Related Posts plugin. On March 30, Plugin Vulnerabilities reported Related Posts had a “settings change vulnerability that permits persistent cross-site scripting (XSS).”

WordPress Plugin Team Paints Target on Exploitable Settings Change Vulnerability That Permits Persistent XSS in Related Posts

This vulnerability was disclosed before there was a patch available. There were no reports of in-the-wild exploits at the time. In this post, the authors said they are pursuing a full-disclosure policy to protest inappropriate behavior by moderators of the WordPress Support Forum.

11 days later, this exploit came under active attack.

— Visual CSS Style Editor. On April 9, Plugin Vulnerabilities reports a privilege escalation vulnerability in CSS Style Editor. At the time, there was no patch and no reports of exploits in the wild.

Recently Closed Visual CSS Style Editor WordPress Plugin Contains Privilege Escalation Vulnerability That Leads to Option Update Vulnerability

Like the other Plugin Vulnerabilities posts, this one says Plugin Vulnerabilities is pursuing a Full Disclosure policy to protest the forum behavior. On Thursday, the same vulnerability came under attack.

I have a few questions:

— First, without expressing any opinions or interjecting any new arguments of facts, can you help me make sure I have the timeline, links and facts correct in everything above? Also, are there other events I’m missing?

— Second, after you do that, is there anything else you want to add?

— Third, can you tell me a bit more about Plugin Vulnerabilities? Is it a single person, a for-profit company, a hobby? If it’s a company, how much does it make per year, how many customers does it have. Do you have a picture?

— Fourth, Plugin Vulnerabilities seems to be good at finding serious vulnerabilities in WordPress plugins. How do you do it?

— Fifth, it seems like Plugin Vulnerabilities is committed to disclosing serious bugs even when there’s no patch in place. Does Plugin Vulnerabilities at least contact the plugin developer ahead of time, or does it just go ahead and publish the post without ever contacting the developer?

— Sixth, do you believe the disclosing of these vulnerabilities before a patch is available plays any role in the in-the-wild exploits that have hit these plugins? Why or why not? If you do believe the disclosure plays a role, do you feel bad for the innocent end users who are harmed by these exploits?

–Seventh, several of the plugins at issue have been removed from the WorldPress plugin repository around the time Plugin Vulnerabilities disclosed the vulnerabilities. Any idea why?

I’ve read some of your criticism of journalists and other security researchers. I’d be grateful if you and I could work together in good faith. It would help greatly if you could give concise answers that don’t stray too far afield and aren’t too argumentative 🙂

Kind regards,

Dan Goodin

But at the end of it he stated that he’d “be grateful if you and I could work together in good faith”, the resulting article that we won’t link to, showed that our first instinct was right. Though we thought the story would have been even worse in some ways (possibly claiming that we were in cahoots with hackers), but more accurate in other ways, than it turned out.

If he wanted to write a critical article of what we have done that would have been fine, but instead the resulting article is widely inaccurate just at the level of basic terminology.

As an example of how he doesn’t seem have good reading comprehension take, his final question.

Seventh, several of the plugins at issue have been removed from the WorldPress plugin repository around the time Plugin Vulnerabilities disclosed the vulnerabilities. Any idea why?

If he had read the posts on our blog he referenced, he would have known that two of three were removed before we came across them. The first paragraph of the third post mentioned, not only brings that up that in regards to the vulnerable plugin mentioned in that post, but also to the second one:

When it comes to the security of WordPress plugins what other security companies generally do is to add protection against vulnerabilities after they have already been widely exploited, which obviously won’t produce great results since there is a good chance the websites using their service have already been hacked by the time they do that. One of the ways we keep ahead of that is to monitor the closure of the 1,000 most popular WordPress plugins in the Plugin Directory, since that closure can be due to a security issue and even if it is not, we have found the plugins being closed often contain security vulnerabilities, and as was the case with one less than two weeks ago, ones likely to be exploited. Hackers seem to be doing that type of monitoring as well. Through that we found that the plugin Visual CSS Style Editor, which has 30,000+ active installs and was closed yesterday, has two vulnerabilities that when combined lead to a type of vulnerability hackers would be likely to exploit.

Considering that he managed to miss that, it isn’t surprising that much of his article is not accurate.

In our communication with him we got the sense there was something not quite right here. For example, he ask for a picture at one point in that first message. Is he trying to use his role at Ars Technica to pick up me or women?

The lack of attention to detail, but strange digging culminated in a reply where he wrote this:

I noticed that pluginvulnerabilities.com is registered to White Fir Design LLC. Whitefirdesign.com is also registered to White Fir Design LLC. Both sites were registered through NameCheap.

Why he was doing that we don’t know, seeing as right footer of this website is this:

© 2016-2019 White Fir Design LLC

In the original version of the article we were then falsely tied to a similarly named business that closed years ago.

In general, he seemed to be ignoring what is right in front of his face.

That Isn’t a Zero-Day

Like the first articles of his we mentioned, the inaccuracies start right in the title, “A security researcher with a grudge is dropping Web 0days on innocent users”. We have never claimed to security researchers, we are a service provider, and our focus is not on research, but actionable information for our customers, otherwise known as telling them if there are vulnerable WordPress plugins they might be using.

The larger issue with the title is that we were not dropping zero-days nor do we  “readily admit” to do that as is claimed in the body of the article. A zero-day is a vulnerability being exploited before the developer knows about it. We never claimed any of those vulnerabilities were a zero-days and in fact you won’t find us even claiming that unfixed vulnerabilities that are being exploited are those unless there is evidence of the developer didn’t know. Somehow we have a higher standard than most journalists on when it comes to that.

Nowhere does he point to any evidence these were zero-days and in fact the only evidence he provides actually disputes that for one of them. Maybe he doesn’t know what a zero-day is despite having been a security journalist for at least five years, in which case he probably should find a new profession.

In our communication he never even brought up zero-days, so claiming we “readily admit” to that is putting words in month, which seems particular troubling in regards to his journalism. We also wouldn’t use the word dropping with what we do.

We Are Not Disclosing Vulnerabilities on Public Forums

We could go through so much of the article and point to widely inaccurate stuff, but take this paragraph as an example:

The crux of the author’s beef with WordPress support-forum moderators, according to threads such as this one, is that they remove his posts and delete his accounts when he discloses unfixed vulnerabilities in public forums. A recent post on Medium said he was “banned for life” but had vowed to continue the practice indefinitely using made-up accounts. Posts such as this one show Plugin Vulnerabilities’ public outrage over WordPress support forums has been brewing since at least 2016.

We disclose vulnerabilities we discover on this website, not on “public forums”, how you get that wrong when you are writing about how we disclosed them on this website is hard to understand. Since that isn’t happening that isn’t our “beef” either. We explained our reason for starting our full disclosures here.

Then a highly inaccurate post by someone named “xorloop” on medium.com is cited, which isn’t exactly a reliable source.

What “made-up accounts” is supposed to refer to we don’t know. We do create a new account each time we we leave a message on the Support Forum to let the developer know of the vulnerability, but they all have our name. If our main account hadn’t been banned we would have just posted those through that and they would have been stuck in moderation, making things easier for everyone. Our only intent with that is for the moderators to make an active choice to hide the information from the developer instead of simply letting them know there is an issue, they have chosen to the former and it causes a lot of problems.

The last thing linked to there is a post of ours, “WordPress Doesn’t Fix Severe Vulnerability in Plugin And Doesn’t Want To Have An Honest Discussion About the Issue”, which is a post about how an unfixed vulnerability being exploited wasn’t fixed and then an attempt to discuss it with the person that is the head of the moderation team and also one of six members of the ream running the Plugin Directory was deleted. That would be the sort of thing worth discussing, but he only uses it to point us having an issue since 2016. In that situation, over a year later thousands of websites continued to use the plugin despite the exploited vulnerability being unfixed.

We Didn’t Scour Anything

As one final example, in the article it is claimed that we “scoured” plugins:

The author said s/he scoured both Yuzo Related Posts and Yellow Pencil for security after noticing they had been removed without explanation from the WordPress plugin repository and becoming suspicious.

In reality we didn’t thoroughly review either of the plugins, the vulnerabilities were easy to spot, which obviously paints a different picture of what happened then it looks like Mr. Goodin wanted to paint.

Corrections Please

We have contacted Ars Technica to point out that this article seems to be beneath their standards and highly inaccurate. We have offered to work with them in good faith to correct it and hopefully corrections will be made.