Login

Tag Archives: Steve Ragan

28 Nov 2016

What worse than security journalism? Security journalism by security companies.

When it comes to poor state of security a big cause is the poor state of the security industry, in which most of the companies don’t know or care much about security. There is obviously role for journalism to shine light on how bad things are, but unfortunately they are often a part of the problem instead. For example, it seems like that the poor state of security journalism actually leads to some of the inaccurate and sometimes all together false research being put out by security companies, as sensational claims are more likely to get coverage from journalists and those journalist often don’t do any due diligence as to whether the claims have a basis in fact. So a security company could spend a lot of time doing real research and hope that it gets covered or they could skip the hard work and just make claims that are likely to pique the interest of journalists knowing that it is unlikely the journalists will look into the accuracy of the claims.

When it comes to the security of WordPress plugins we often see inflated claims about minor issues, while at the same time other issues that are serious issues don’t get coverage. Take for example a situation that we have been trying unsuccessfully for years to get fixed, where WordPress is refusing to warn people that they are using plugins that have been removed from the Plugin Directory due to security vulnerabilities. Considering that some of those plugins will never be fixed by the plugin’s developers and others are already being exploited when the plugin is removed, warning people is necessary and not doing it is leading to websites being hacked. At the same time you get overblown coverage of minor vulnerabilities that have already been fixed. A recent situation along those lines, shows that sometimes security journalists can actually be better than that, but that security journalism done by a security company can come in to keep the bad situation going.

As part of our monitoring for security issues in WordPress plugins to add them to the  data set for our service we monitor for news coverage of WordPress plugin vulnerabilities. Through that last week we came across a Threat Post article “WordPress Plugins Leave Online Shoppers Vulnerable“.  The article stated that:

Researchers are calling into question the safety of some of the top WordPress e-commerce plugins used on over 100,000 commercial websites prepping for Black Friday and Cyber Monday online sales.

In reviewing the top 12 WordPress e-commerce plugins, application security testing firm Checkmarx found four with severe vulnerabilities tied to reflected XSS (cross-site scripting), SQL injection and file manipulation flaws.

So what these vulnerabilities? The author of the article didn’t have any idea:

The study did not call out specific e-commerce plugins used by WordPress sites, nor did it identify which sites used the plugins. Researchers at the firm did not reveal whether the vulnerabilities had been patched by the plugin vendors or websites using them, either.

If the vulnerabilities existed the details of them would matter quite a bit as to whether they were severe (the reflected cross-site (XSS) vulnerability being the exception, as we will get to a bit later).

Looking at the report from company behind the claim, Checkmarx, they had not even notified the developer’s of the plugins about the claimed issues:

While most of these plugins are updated regularly, we are unable to comment on if there are patched versions until we notify the organizations behind the plugins about the possibility of having an open attack vector.

At this point we where perplexed as to they put out report without having done that or providing the details of the vulnerable plugins. It turns out we were not alone, Steve Ragan of CSO who had been offered the report ahead of its release had the same view:

The response from Checkmarx is good example of general terribleness of security companies:

While this certainly gives the company PR, we don’t understand what awareness this could possibly provide. Its not like it is a secret that software can have security vulnerabilities.

The last time we ran into Checkmarx they had put out another report of vulnerabilities in WordPress plugins,  where one of their recommendation was “Ensure all your plugins are up to date”, while running an out of date version of WordPress on their own website.

So one journalist passed on this, the explanation why another didn’t could be the fact that Threat Post is product of another cyber security company Kaspersky Lab (which we also found running outdated software on their website several years ago).

These Might Not Be Severe Vulnerabilities

One of the unique features of our data on vulnerabilities in WordPress plugins is that we provide a severity rating for vulnerabilities, so that our customers can have a better understanding of the threat posed by it, because we were finding that severity of them are frequently overstated. As we mentioned before without the specifics you can’t say in a lot of cases how severe is a vulnerability, but we can look in general terms as whether the vulnerabilities Checkmarx claimed to have found in the four plugins, match up with the claim in the report that they are “high-risk vulnerabilities”. The claimed vulnerabilities are:

  • Reflected cross-site scripting (XSS) in three plugins
  • SQL injection in one plugin
  • Second order SQL injection in one plugin
  • File manipulation in one plugin

The vulnerability found in three plugins, reflected cross-site scripting (XSS), is decidedly not a high-risk. While this type of vulnerability could cause a lot of problems, it just isn’t likely to be exploited in the real world based on everything we have seen. There two likely reasons for that. First, all of the major web browsers other than Firefox have XSS filtering, so an attacker would need to figure out a way around that (or multiple ways for different web browsers). Second, this type of attack involves getting someone else to access a specified URL, which isn’t something we see being attempted all that often.

For the next two SQL injection and second order SQL injection the risk that comes from this varies as to what the attacker can do. SQL injection involves getting malicious code into a request being made to a database. This type of vulnerability would likely be exploited if it allowed creating a new WordPress Administrator users or allowed placing malware on the website’s page. But the most common action that can be taken is to slowly extract information stored in the database, while that could be a big concern with a website doing eCommerce, we don’t seem much of the way attempts to exploit this type of thing, so again not a high-risk.

The final type, file manipulation, is something we are not clear as to what they are referring to. Since it seems they are referring to something that actual encompasses a fair amount of different vulnerabilities that could impact files. Their description doesn’t clear up what they might be referring to:

File manipulation vulnerabilities occur when files, or directories are able to be manipulated in ways that the developer did not intend them to be, thus giving the user, or malicious party, access to modify either the file or directory which could lead to devastating consequences from either the plugin other users.

There description of the potential impact makes things even less clear:

Cyber criminals could exploit a file manipulation vulnerabilities contained within a shopping cart plugin and adjust the files to change the prices during the checkout stage of processing.

Pricing information is usually stored in the database, so we are not sure what files would have to do with it, unless it involved modifying hard coded values or changing pricing calculations.

Beyond the type of vulnerability, the severity of the SQL injection vulnerabilities and the file manipulation vulnerabilities could be greatly impacted by what level of access is need to exploit them.

Based on what was present in the report Threat Post’s claim that severe security vulnerabilities were found is not supported.