09 Dec

Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Twitter Cards Meta

We recently found that the Twitter Cards Meta contains a cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability on the plugin’s setting pages,/wp-admin/admin.php?page=twitter-cards-meta.

The CSRF potion of the vulnerability was due to a lack of a nonce on the page and a lack of a check for a valid one when processing a request to change the plugin’s settings.

For the XSS issue, in the file /twcm-options.php starting at line 28 in version 2.4.5 settings are saved and there is no sanitization done:

			'use_authors_twitter_account'=>isset($_POST['use_authors_twitter_account']) ? intval($_POST['use_authors_twitter_account']) : '', 
			'default_image'=>(trim($_POST['default_image'])=='Link to Default Image')? '' : trim($_POST['default_image']),
			'home_page_description'=>(trim($_POST['home_page_description'])=='Enter a description for home page, keep it under 200 characters')? '' : wp_filter_nohtml_kses(trim($_POST['home_page_description'])),  #wp_filter_nohtml_kses is smililar with strip_tags() function
			'use_default_card_type_sitewide'=>isset($_POST['use_default_card_type_sitewide']) ? $_POST['use_default_card_type_sitewide'] : ''

When the values are outputted on the page through the same file they were not escaped. For example, the value for “site_twitter_username” was set on line 68:

<tr><td  align="left" width="200">Site's Main Twitter Account:</td><td>@<input type="text" name="site_twitter_username" value="<?php echo ($twcm_options['site_twitter_username'])? $twcm_options['site_twitter_username'] :'WPDevTeam';?>" size="20"  onblur="javascript: if(this.value=='') {this.value='WPDevTeam';}" onclick="javascript: if(this.value=='WPDevTeam') {this.value='';}"  /></td></tr>

Proof of Concept

The following proof of concept will cause an alert box with any accessible cookies to be shown on the page /wp-admin/admin.php?page=twitter-cards-meta, when submitted as an Administrator.

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

<form action="http://[path to WordPress]/wp-admin/admin.php?page=twitter-cards-meta" method="POST">
<input type="hidden" name="save_options" value="Save Options" />
<input type="hidden" name="site_twitter_username" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />


  • December 2, 2016 – Developer notified.
  • December 9, 2016 – WordPress.org Plugin Directory Notified.
  • December 9, 2016 – Plugin removed from WordPress.org Plugin Directory.
08 Dec

CWIS Antivirus Scanner Can Also Leave You Unaware That You Are Still Vulnerable To Plugin Vulnerabilities

Yesterday we discussed a couple of recent instances where WordPress plugins were reported to have vulnerabilities that were fixed by discovered and those vulnerabilities were added to WPScan Vulnerability Database with the vulnerabilities listed as be fixed. But in both cases when we actually tested out the vulnerabilities as part of our adding them to our own vulnerability data, we found that the vulnerabilities had not actually been fixed. Those instances were a reminder of the need to actual check if vulnerabilities have actually been fixed (those two instances are by no means the only times that has happened) and reminder that isn’t something that happens with data included in the WPScan Vulnerability Database, which is used in a number of services and plugins. It turns out they were not the only ones that incorrectly listed one of the vulnerabilities as being fixed.

Last month we looked at a new source of vulnerability data in WordPress plugins, the plugin CWIS Antivirus Scanner, and found that they were including false reports of vulnerabilities in plugins in their data. Just as we came across it the first time, through our monitoring for updates to plugins that might be related to a security fix, a more recent update for the plugin popped up with that and one of the new listings was:

2016-11-22 * Check Email [version = 0.3] XSS : http://www.exploitalert.com/view-details.html?id=25359

As we mentioned in the previous post while the vulnerability in the Check Email plugin was listed as being fixed in the version after 0.3, 0.5, it was until two more releases (and our helping the developer) that it was actually fixed in 0.5.2. If they had tested out the vulnerability the would have also noticed it hadn’t been fixed, but clearly they didn’t. So if you use the CWIS Antivirus Scanner to warn you about plugin vulnerabilities you will need to test out any vulnerabilities in the plugins you use to make sure they are actually fixed, otherwise might still be vulnerable (or you could use our service, since we actually do that testing in the first place).

That same release of CWIS Antivirus Scanner also continued with the adding of vulnerabilities that don’t actually exist. Two of the other entries were as follows:

2016-11-22 * MailChimp [version = 4.0.7] CSRF/XSS : http://www.exploitalert.com/view-details.html?id=25361

2016-11-22 * Easy Facebook Like Box [version = 4.3.0] CSRF/XSS : http://www.exploitalert.com/view-details.html?id=25351

In the case of both vulnerabilities just a quick glance by someone knowledgeable about vulnerabilities in WordPress plugins would likely been enough to think that they were false, since the proof of concept for exploiting them seemed to show that the protection against the vulnerability actually existed. When we tested out each of them we found the protection was properly functioning, so neither of the claimed vulnerabilities actually existed.

Including the false report of a vulnerability in the Easy Facebook Like plugin is more problematic, as CWIS Antivirus Scanner lists it as being the current version of the plugin. The plugin has 90,000+ active installs according to wordpress.org, so that is lot of webmasters that could be mislead to think their website is currently insecure. MailChimp for WordPress has 600,000+ active installs , so even though they are not listing the current as being vulnerable, a lot of people could think there website had a vulnerability in the past, which it didn’t.

07 Dec

WPScan Vulnerability Database’s Data Can Leave You Unaware That You Are Still Vulnerable

Recently we looked at two instances where the WPScan Vulnerability Database only included some of sets of vulnerable plugins that we had disclosed, leaving those relying on their data unaware that they were using plugins with known vulnerabilities in the current versions. One set of vulnerabilities were easily exploitable and the other set involved plugins that it looked like hackers were already targeting, so the omissions were pretty serious. We still don’t understand how that happened, seeing as it is much easier for the WPScan Vulnerability Database to add new vulnerabilities than it for us since they don’t review the vulnerabilities before adding them. Their lack of reviewing vulnerabilities causes its own issues, as we found in two cases where they were claiming that vulnerabilities were fixed when they were not. If it were not for us, those vulnerabilities would still be in the plugins at this point, which is a reminder of the critical role we play in the security of WordPress ecosystem.

Bad Report = Bad Fix

Recently a report of a vulnerability in the very popular NextGEN Gallery plugin, which has 1+ million active installs according to wordpress.org, was released. We continue to be unsure of what vulnerability the report was actually trying to refer to since in only a few sentences it seems to be referring to an authenticated local file inclusion (LFI), authenticated arbitrary file viewing, or authenticated remote code execution (RCE) vulnerability. The WPScan Vulnerability Database list the vulnerability as being an authenticated local file inclusion vulnerability:

But in our testing we couldn’t find where that or an authenticated arbitrary file viewing vulnerability would have existed in the relevant code. Whether either of those vulnerabilities existed it seems to us that the vulnerability definitely existed, the authenticated remote code execution vulnerability, was the most serious, since it would allow you to do the equivalent of both other vulnerabilities.

In the version that reporter of the vulnerability and the WPScan Vulnerability Database reported it to be fixed, it wasn’t. The developer had made a change in that version that would have been relevant for either a local file inclusion or arbitrary file viewing vulnerability (though the code that already existed had same impact on the possibility of an arbitrary file viewing vulnerability). After we notified the developer, a change was made to try fix the actual vulnerability, but the first attempt included a security check that was easily bypassed. After notifying them of that and suggesting a more secure way to accomplish that, the vulnerability was finally fixed in version 2.1.60.

Fixed and Fixed Again

The second vulnerability also involves a bit of confusion. While the report of a vulnerability in the Check Email plugin labels the vulnerability as a cross-site scripting (XSS) vulnerability, parts of the report claimed the issue was caused by a cross-site request forgery (CSRF) issue. In version 0.5 of the plugin, protection against CSRF was put in place for the sending of test emails, but this protection didn’t do anything for the XSS issue because that can occur without any attempt to send a test email. After noticing the issue we contacted the developer and after one additional release, 0.5.1, that didn’t fix the issue, we were able to work with them to get a proper fix to the issue put in place with version 0.5.2.

As of November 15 the WPScan Vulnerability Database listed the vulnerability as being fixed in version 0.5:

A week later it was supposed to have been fixed 0.5.1:

You Need To Double Check Their Data

If you are using data from the WPScan Vulnerability Database and you actually want to be sure that vulnerabilities in plugins you use have been fixed you will need to test out any relevant vulnerabilities yourself, or you could sign up for our service, where we actually do the testing when adding vulnerabilities to our data (there are a number of other advantages that come with our data).

01 Dec

Tip For Security Researchers: WordPress Uses a Nonce to Protect Against Cross-Site Request Forgery (CSRF)

For the last three false reports of vulnerabilities in WordPress plugins we have discussed, there has been a common denominator that we don’t quite understand. Each has involved a claim that a plugin has a cross-site request forgery (CSRF) vulnerability, but in the proof of concept for exploiting each of the vulnerabilities there has been nonce included. Seeing a nonce is what is used in WordPress to protect against that type of vulnerability, we have a hard time understanding what is going on here, other than people without the proper knowledge to make a claim that this type of vulnerability exist are in fact doing that.

When used in a form a simple version of the nonce looks like this:

<input type="hidden" id="_wpnonce" name="_wpnonce" value="aa27b52873" />

While it is not required to actually use the word “nonce”, in most cases it will be labeled as such.

While the existence of a valid looking nonce in a proof of concept of a vulnerability likely indicates that the report is false, the existence of a nonce in a plugin’s pages is not always an indication that there is not a CSRF vulnerability, as plugins do not always actually check if the nonce exists or that it is valid when processing the request tied to it. One way to test out if the CSRF protection is properly functioning is to use the developer tools in your web browser to modify the value of the nonce or remove it and see if the request is still successful.

01 Dec

What We Were Up To in November, 2016

Here is what we had been doing to keep our customer’s websites secure from WordPress plugin vulnerabilities during November (and what you have been missing out on if you haven’t signed up yet):

Plugin Vulnerabilities We Discovered and Publicly Disclosed This Month

We don’t just collect data on vulnerabilities others have discovered, we also discover vulnerabilities while monitoring hackers activity, reviewing other vulnerabilities, and by doing additional checking on the security of plugins.

Plugin Vulnerabilities We Helped Get Fixed This Month

Letting you know that you are using a vulnerable version of plugin is useful, but it is much more useful if you can fully protect yourself by simple updating to a new version. So we work with plugin developers and the Plugin Directory to make sure that vulnerabilities get fixed.

Plugin Vulnerabilities Added This Month That Are In The Current Version of the Plugins

Keeping your plugins up to date isn’t enough to keep you secure as these vulnerabilities in the current versions of plugins show.

Additional Vulnerabilities Added This Month

As usual, there were plenty of other vulnerabilities that were disclosed this month that we added to our data this month:

30 Nov

Vulnerability Details: Cross-Site Request Forgery (CSRF) in Wp-D3

From time to time vulnerabilities are fixed in plugin without someone putting out a report on the vulnerability and we will put out a post detailing the vulnerability. While putting out the details of the vulnerability increases the chances of it being exploited, it also can help to identify vulnerabilities that haven’t been fully fixed (in some cases not fixed at all) and help to identify additional vulnerabilities in the plugin.

A cross-site request forgery (CSRF) vulnerability in the plugin Wp-D3 was discovered by Klikki Oy, but they didn’t provide any details on what exactly the vulnerability was connected to. Looking at the changes made in the version that was supposed to have included the fix, 2.4.1, it is easy to spot what that was.

In the file /utils.php there are five functions made accessible through WordPress’s AJAX functionality and in version 2.4.1 code was added to each of those to check for a valid nonce before running the rest of the function’s code, which would prevent CSRF. One of those is shown below:

$nonceValid = check_ajax_referer('wpd3-nonce', 'security'); 
if (!$nonceValid) { 

Without that CSRF protection if an attacker could have  gotten a logged in user to visit a URL they specified the function previewContent() could be used to cause reflected cross-site (XSS), deleteCustomField() could be used to pass values specified by the attack to delete_post_meta(), and setCustomField() could be used to pass values specified by the attacker to function  add_post_meta().

Proof of Concept

The following proof of concept URL will cause any available cookies to shown in alert box when logged in to WordPress. 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-ajax.php?action=previewContent&postId=1&editor=%22%3E%3Cscript%3Ealert(document.cookie);%3C/script%3E
28 Nov

Authenticated Remote Code Execution (RCE) Vulnerability in NextGEN Gallery

In reviewing reports of vulnerabilities to add them to our data, two of the important things we do is determining what type of vulnerability there actually is, as sometimes vulnerabilities are mislabeled, and we also check to make sure that vulnerability has actually been fixed. Those two can together when looking at a recent report of a local file inclusion (LFI) vulnerability in NextGEN Gallery.

Worth noting before we get in to the details is that the changelog entry for the version that was supposed to fix this, 2.1.57, lacked any mention of a security update.

The report didn’t really make a lot of sense. While it refers to an authenticated local file inclusion issue multiple times it also states that the vulnerability “may allow an authenticated user to read arbitrary files from the server”, which would seem to indicate that this is another type of vulnerability, an authenticated arbitrary file viewing vulnerability.

The report lacked a proof of concept for us to see how the issue would be exploited, which  should have cleared up what the vulnerability actually was, but with the knowledge that issue involved a failure to”properly validate user input in the cssfile parameter of a HTTP POST request” and the changes made in the version that was supposed to have fixed this we had a better idea of what was being referred to.

On the page /wp-admin/admin.php?page=ngg_other_options there is a section labeled Styles, normally the content in the File Content section of that will be saved to the file /wp-content/ngg_styles/nggallery.css. The problem is that the value of the filename is user specified with the input “style_settings[CSSfile]”. The change made in 2.1.57 would strip out two periods in a row from that input:

$cssfile = str_replace('..', '', $this-&gt;object-&gt;param('cssfile')); 
$abspath = $styles-&gt;find_selected_stylesheet_abspath($cssfile);

That would prevent directory traversal, that is moving up a directory by using “../”. That change though did nothing to stop someone from naming the file something like “rce.php”. You could place PHP code in the File Content section and that would lead to remote code execution (RCE) when the new file with .php extension is requested. That would be more serious issue than a local file inclusion vulnerability. We haven’t been able to find a local file inclusion or arbitrary file viewing vulnerability caused by this, so maybe there was just confusion as how the vulnerability should be referred to.

Normally the ability to have done this would be restricted to Administrator level users (who would normally already have the ability to do the equivalent of this vulnerability), but the plugin allows for lower level users to gain be provided to the plugin’s capabilities. For lower level users to have access to this they would need to have been given the ability to “Change options” and “Change style”.

Within an hour of us contacting the developer about the issue they responded and starting working on better fix.

The next week version 2.1.59 was released, that attempted to fix this but ran into a common issue. Code was added to try to restrict the extension of the file to css:

if (strpos($settings['CSSfile'], '.css', -0) == FALSE) { 
    return FALSE; 

That checks to make sure the filenames contains “.css”, so the filename “rce.php” wouldn’t be acceptable. The problem is that “rce.css.php” would be acceptable and since it ends with “.php” it would treated by the server as a PHP file.

After we notified the developers of that issue version 2.1.60 was released, which uses PHP’s functionality for getting a file’s extension and avoids the previous solution’s bypass problem:

$file_info = pathinfo($settings['CSSfile']); 
if (strpos($file_info['extension'], 'css') === FALSE) { 
    $valid = FALSE; 

Proof Of Concept

One the page http://path to WordPress]/wp-admin/admin.php?page=ngg_other_options use your web browser’s developer tools to modify the value of the input “style_settings[CSSfile]” to rce.php, place PHP code in the File Content textarea in the Styles section, and save. Requesting the URL http://path to WordPress]/wp-content/ngg_styles/rce.php will cause the PHP code to execute.

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


  • November 16, 2016 – Original report released.
  • November 16, 2016 – Developer notified.
  • November 16, 2016 – Developer responds.
  • November 23, 2016 – Version 2.1.60 released, which fixes vulnerability.
28 Nov

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in WP Whois Domain

From time to time vulnerabilities are fixed in plugin without someone putting out a report on the vulnerability and we will put out a post detailing the vulnerability. While putting out the details of the vulnerability increases the chances of it being exploited, it also can help to identify vulnerabilities that haven’t been fully fixed (in some cases not fixed at all) and help to identify additional vulnerabilities in the plugin.

One of the way we keep track vulnerabilities in WordPress plugins is by monitoring the WordPress Support Forums for relevant threads. Through that we came across a thread stating that the PCI scanner for ControlScan had identified a “[c]ross-site scripting vulnerability in domain parameter” of the WP Whois Domain plugin.

A quick check of the plugin’s code showed that the domain parameter is used on two lines in the file /pages/func-whois.php:

$domain = $_REQUEST['domain'];

When the value of “$domain” is set to the parameter no sanitization is done.

Later in the file the value “$domain” is output without any escaping:

<input type="text" name="domain" id="domain" value="<?=$domain;?>">

That combination permits reflected cross-site scripting (XSS) to occur.

Proof of Concept

The following proof of concept URL will cause any available cookies to shown in alert box. Major web browsers other than Firefox provide XSS filtering so this proof of concept will not work in those web browsers.

On a page using the plugin’s short code [whois-domain] add the URL parameter “domain=”><script>alert(document.cookie);</script>” to the URL.

28 Nov

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.