Login
2 Nov 2018

With a Source Like This It is No Wonder Security Journalism Is Making WordPress Websites Less Secure

Recently an instance of security journalism received a significant spotlight and significant pushback. Bloomberg claimed that a malicious chip had been found in servers used by Apple and Amazon, which both Apple and Amazon categorically denied. Either there is a significant cover up or Bloomberg got things very wrong. The latter possibility wouldn’t surprise us since from what we have seen over the years security journalism is filled with inaccurate and outright false claims, much of that coming from people in the security industry that either don’t know what they are talking about or are intentionally spreading false information. Security journalists seem to not be interested in avoiding that.

Last week we discussed a situation where security journalists were spreading false information due in part to relying on a single source that didn’t really know what he was talking about. Since then, we had an interaction with that source that made it clear that they are not a source that should be relied on alone (or maybe at all) as these journalists had done and that seems to be a good example of why security journalism is in such bad shape, which in turn is actually making WordPress websites (and websites in general) less secure.

The source for their stories was Larry Cashdollar, a security researcher for Akamai’s SIRT (Security Intelligence Response Team). As we noted in the previous post, what we had seen in the past is that he doesn’t always provide accurate information. Specifically we noted a recent situation where he had claimed that vulnerabilities in a WordPress plugin had been fixed when they hadn’t. At the time of his disclosure we tried to notify him of that on Twitter:

It was until last week that he responded:

The follow up to that sounds like a reasonable explanation as to what happened:

We have seen situations in the past were developers had done just, so it sounds reasonable, but in reality it is totally false, which could easily be checked on since all changes made to WordPress plugins in the Plugin Directory are easily accessible through the underlying Subversion repository.

Here is how CVE-2018-1002002 was listed in his report:

CVE-2018-1002002

bft_list.html.php:28:
<div><label><?php _e(‘Filter by email’, ‘broadfast’)?>:</label> <input type=”text” name=”filter_email” value=”<?php echo @$_GET[‘filter_email’]?>”></div>

That code outputs the value user input, in the form of the GET input “filter_email”, without escaping it, which is a reflected cross-site scripting (XSS) vulnerability.

In version 2.5.15 the code is exactly the same:

<div><label><?php _e(‘Filter by email’, ‘broadfast’)?>:</label> <input type=”text” name=”filter_email” value=”<?php echo @$_GET[‘filter_email’]?>“></div>

After we contacted the developer about the lack of a fix they released version 2.5.17, which fixed the vulnerability by escaping the value:

<div><label><?php _e(‘Filter by email’, ‘broadfast’)?>:</label> <input type=”text” name=”filter_email” value=”<?php echo esc_attr(@$_GET[‘filter_email’])?>”></div>

No change was made to that code in version 2.5.18.

After we tried to explain that to him, Larry he responded with this:

That simply isn’t true.

So what explain all this, the explanation is supposed to be the following:

From our interaction with the developer it was quite clear they didn’t understand at all was at issue, so relying on them would have been a bad idea. Developers of plugins with vulnerabilities often don’t have a good understanding of what is at issue and incorrectly believe they have fixed issue that they haven’t fairly often. That is why it is important for the discoverer of vulnerabilities to check to make sure things have been fixed, which is why we contacted Larry in the first place. What seems the most problematic with that is that he did not indicate that he didn’t know if the vulnerabilities were actually fixed in his report, instead it just states “Fixed v2.5.1.5”.

We don’t know what the Plugin Directory team actually told Larry, but at best Larry is repeating claims made by others without indicating that he is doing that and without much concern if they were true. That he doesn’t seem to have much concern for the truth seems problematic in general, much less someone working in the job he does. Where it gets more problematic is when a bunch of journalists rely on him as their sole source for their stories, where we would assume that they believed that he would be telling the truth.

The outlets that relied on him as their sole source for the issue we discussed last week included Bleeping Computer, Naked Security, The Register, SC Media, ThreatPost and ZDNet.

It seems as though at least one of the journalists involved in this doesn’t even understand what sources are, as the author of the Threatpost post, Tara Seals , responded to our comment on her post in part with this:

Hi again! Here is the response that Larry Cashdollar gave me: “It’s not a sole source. The author of Blueimp and I verified it.

How her sole source saying he isn’t the sole source for the article is supposed to make sense is not something we could follow (the author the software discussed was not even mentioned in the story, much less quoted).

Considering that she works for a news outlet that somehow promoted itself in the same sentence as “an independent news site” and the “Kaspersky Lab security news service” (Kaspersky Lab being a security company), they may not really be big on journalistic standards.

Security Journalist Are Making Websites Less Secure

The inaccurate information presented in those articles about that situation isn’t one off issue, from what we have seen that is probably the default situation. Beyond misleading the public about the specific situations discussed in those articles, overall this leads to people having a bad understanding of what is going wrong with security (of which there is plenty) meaning that problems that could have been fixed long ago don’t get fixed and that websites are insecure in ways that they shouldn’t be. The poor handling of the security of WordPress plugins by the people on the WordPress side of things could definitely use the spotlight of security journalists (instead they are providing cover for that).

The problems caused by security journalists don’t end with that though, security companies certainly get promotional value from having their claims covered by these journalists. The public would likely believe that these journalists wouldn’t rely on companies that don’t know what they are doing. That would be a very bad assumption, as our discussion of another Threatpost article from a little over a month ago showed. In that instance they relied on security company, Sucuri, which had written a post about a vulnerability for which they somehow had no understanding of it. It was the kind of situation where there should have been coverage that you have a security company that is unfit to be in business instead of covering them as a legitimate source, as was done.

You don’t have to look any farther than Sucuri to see that security companies believe that being a source has reputational boost as they promote their “research” being covered, right on their homepage:

From what we have seen over the years is that company doesn’t even try to do the work they claim to be doing, so not only does their service not effectively protect websites, but they don’t try to properly clean up websites. While that failure to properly clean up website has a big impact on their customers (far too many of them have had to hire us to re-clean their websites over at our main business), but it makes everyone less secure since they usually don’t attempt to determine how websites have been hacked, which means that, for example, zero-day vulnerabilities can go unfixed longer, leading to more websites being hacked.

No related posts.

Leave a Reply

Your email address will not be published. Required fields are marked *