Security Plugins and Plugins by Automattic Haven’t Been Updated To List Them as Compatible With WordPress 4.8

Back on May 31 we received an email from WordPress.org asking us, as developers of several plugins, to make sure that the plugin were listed as being compatible with the then upcoming WordPress 4.8. The beginning of the message reads:

Hello, White Fir Design!

WordPress 4.8 is scheduled to be released on June 8. Are your plugins ready?

After testing your plugins and ensuring compatibility, it only takes a few moments to change the readme “Tested up to:” value to 4.8. This information provides peace of mind to users and helps encourage them to update to the latest version.

As scheduled, that version was released on June 8.

While looking at something the other day we noticed that a security plugin had not been updated to list as being compatible with the new version. Looking at the plugins tagged security it turns out that many haven’t been two weeks after the release of that new version of WordPress. That doesn’t seem to be a great indication as to the state of security plugins, but more striking was that several of the most popular plugins tagged security that have not been updated come from the company Automattic, which is closely associated with WordPress.

First up being Jetpack by WordPress.com, which is tied with 6 other plugins for having the most active installs, 3+ million:

One of those other plugins with the most active installs is another Automattic plugin, which despite shipping with WordPress also isn’t listed with WordPress 4.8:

Getting back to the security tagged plugins, another Automattic plugin not listed as being compatible is VaultPress:

Among the other security tagged plugin that haven’t been updated to be listed as being compatible, you have iThemes Security:

You also have Sucuri Security, which still hasn’t even been listed as being compatible with WordPress 4.7, despite that being released in December:

The parent company of that plugin GoDaddy also hasn’t updated their other plugins to list them as compatible:

Also worth noting, considering SiteLock’s questionable involvement with WordPress, is the SiteLock Security plugin:

Google Handling Advertising For Website Serving “Nulled” WordPress Themes and Plugins With Malicious Code

Recently Google has been deciding to show ads for one of our services on websites serving “nulled” web software, which is paid web software being distributed illegal, possibly with security measures removed from it. That isn’t something we are interested in having our ads run on and we have excluded those websites from showing our ads. Today while looking into a hacked WordPress website that we were contacted about, we noticed that Google is handling the advertising for another such website, dlwordpress.com, where “nulled” WordPress themes and plugins are being distributed with malicious code in them.

At the top of the homepage are two ad blocks being served by Google (bordered in red):

The website (and the others that had included our ads) seems to pretty clearly be in violation of Google’s AdSense programs policy related to copyright material:

AdSense publishers may not display Google ads on pages with content protected by copyright law unless they have the necessary legal rights to display that content. This includes pages that display copyrighted material, pages hosting copyrighted files, or pages that provide links driving traffic to pages that contain copyrighted material.

The malicious code being reported to be served with the software at that website would seem to cause the website to violate a couple of their content guidelines as well:

It doesn’t seem like it would be hard for Google to detect that these websites are engaged in the activity they are, so it seems if they didn’t want them to be in their advertising program they already could be excluded. We have been reporting the ones that have been showing our ads, though.

dlwordpress.com Warns About Similar Websites Distributing Files Containing Viruses

While the website prominently links to a page for filing DMCA takedowns for copyrighted content on the website, the website is promoting that it actually is involved in placing such content on their website, which would seem to remove the safe harbor protection that DMCA provides for websites:

For your money, we'll buy new wordpress themes.

While a WordPress theme’s (or a plugin’s) code would need to be licensed under the GPL and therefore can be legally distributed to others after being purchased, other assets included with them would not.

On the “Submit Your Theme or Plugin” page, they pretty clearly are requesting content that they know wouldn’t be legal for them to distribute. But more striking is that they ask people submitting themes and plugins to not submit them from other similar sites because they “can share files with viruses”:

Here you can send your nulled themes and plugins. Please do not send files from another sites! Another sites can share files with viruses. Share only from themeforest or codecanyon!

Cloudflare Too

Google isn’t the only legitimate company involved with this website, as when we went to check to see where the website’s server was located we found that it is being served through Cloudflare.

A couple of months ago we found them doing the same for a website being used as part of a hack to compromise credit card credentials.

A Single Tweet Nicely Sums Up the Problem With WordPress Allowing SiteLock to Be Involved With WordCamps

The web security company SiteLock has a well earned reputation that can be summed up with what Google suggests when you type in their name:

Google's second suggestion is "sitelock scams".

That obviously isn’t a reputation you would think that any company would want. It would probably be difficult for SiteLock to legitimately change it though since their business model seems to be based around the activity that gets them labeled as such.

It would also be difficult because if they, for example, stopped partnering with web host to try to get people to pay them to clean up hacked website that are not in fact hacked, then they would actually have to really clean up websites to get paid and from everything we have seen they are even worse than the average web security company, which is already quite bad, when doing that. For example, we are often brought in to re-clean hacked websites after some other company had previously had done that and then the website got hacked again. While that isn’t always their fault, in almost every instance we have been told that the determining how the website was hacked never even came up, despite trying to do that that being a basic part of the cleanup and important to make sure the vulnerability that allowed the website to be hacked has been fixed. That is certainly something we have seen with SiteLock. What we haven’t seen with other companies is that SiteLock has caused websites to be broken after doing their work.

Instead of trying to change, SiteLock looks to have focused on various efforts to present a public face very different than the one that their customers and not always willing potential customers can find themselves dealing with. What looks to be an important component of that effort is their involvement and sponsorship in the conferences for WordPress, WordCamps, which uses money they have gotten from their questionable business practices. We think a tweet put out by one of those WordCamps succinctly shows what the problem with WordPress allowing that to occur is:

The claim that SiteLock wants make your WordPress secure is belied by many things we have run across, including a few recent examples: thinking that leaving malicious code on a website for a while is not a threat, not taking the actions needed to prevent hacked websites from being reinfected, and not warning about vulnerable plugins or insuring they are being kept up to date on a website they are supposed to be keeping secure. But maybe the most troubling recent example is that SiteLock is still knowingly spreading false information about the security of the core WordPress software and using it to make a profit. We would love to hear from someone on the WordPress or WordCamp side of things how that makes anyone’s WordPress secure.

At some point, maybe we have already reached that point, you have to say that WordPress is complicit in what is going on here. Back in September of last year we contacted the central WordCamp organization to let them know that about the issues with SiteLock and ask for a comment about the situation or a more general comment on any restrictions on who can be a sponsor. We never got any response from them, though it was pretty clear they saw the message. So it seems that they can’t actually justify what is going on, but are still willing take money SiteLock has gotten through less than above board business activity. We later left a comment on a blog post about SiteLock on the WordCamp US’ website, shortly afterwards the comments left on that post were removed and commenting was disabled, so there does seem to an effort to hide what is going on.

What could explain some of why they continue to allow SiteLock’s participation is that SiteLock’s owners don’t just sponsor WordCamps under the SiteLock brand, but also through brands of the web hosting company Endurance International Group, which they run. For example, at WordCamp Europe they were a higher level sponsor through EIG brands Bluehost and MOJO Marketplace (MOJO Marketplace also doesn’t seem to be too concerned about security):

Checkmarx Running Outdated and Insecure Version of WordPress

Back in November over at the blog for our Plugin Vulnerabilities service we discussed the fact that the security company Checkmarx was making a claim that a number of WordPress eCommerce plugins had severe vulnerabilities without providing any evidence, even what the name of the plugins was, to support that. That didn’t stop security journalists from covering the claim at the time. The details were supposed to be released later, but when went looking for them several weeks ago we couldn’t find them and when we contact Checkmarx to inquire about them, we received no response. At this point we think it is reasonable to wonder if the vulnerabilities ever existed.

It turns out though that this company that doesn’t seem to have a problem with making what appear to be baseless claims about the security surrounding WordPress, uses WordPress on its own website at the same time.

What should be surprising, but is an all too common occurrence, it also turns out that they are running an out of date and insecure version of WordPress on their website as can be seen in the source code of the website’s pages:

The Checkmarx Website is Running WordPress Version 4.6.1

There have been four releases of 4.6.x with security fixed since then: 4.6.2, 4.6.3, 4.6.4, and 4.6.6 (they also have updated to the latest major release of WordPress, 4.7). The oldest of those was released over four months ago.

The plugin listing its version number below the line for WordPress is not surprisingly also out of date.

What makes their lack of updating stick out is that WordPress would have normally automatically updated without any action required by Checkmarx, due to the automatic background updates feature. So either Checkmarx’s server environment has some incompatibility with that (which they could help WordPress to get fixed) or they intentionally disabled them. In either case you should expect that a security company would be concerned enough about security enough to manually apply those updates.

With all of that, it doesn’t seem like it should be all that surprising that security is in such bad shape these days.

SiteLock Unintentionally Provides Reminder That They Don’t Keep WordPress Websites Secure

One of our long time concerns with the security industry is that that their efforts to sell more advanced security measures make it less likely that people will take more basic security measures. Right now even many security companies are not doing the basics when it comes to security and as a hacking of one of Trend Micro’s websites earlier this year showed, more advanced security measures are not necessarily even as effective as the basics.

Another example of this comes from a recent case study from the security company SiteLock where they highlight a website that is using a version of a WordPress plugin with known vulnerabilities while they falsely claim one of their services is insuring the website is “safe and secure at all times.”

The Unmentioned Business Relationship

Before we get the details of that it is worth noting that SiteLock isn’t being upfront about how they came to be involved with the website mentioned in the case study, which seems important when you consider they are leaving it insecure.

Here is their explanation:

One day Kasal unexpectedly received an email from his hosting provider alerting him that his blog had been infected with malware. Due to the stealthy nature of the attack, there were no obvious signs that his blog had been compromised. “I was unaware that my site had been hacked and at a total loss as to how to find or fix the problem,” he recounts.

Kasal’s hosting provider informed him that his blog would be taken offline unless he removed the malicious code that was inserted on his website. His host recommended he contact SiteLock® to remove the malware and help prevent future attacks.

What they don’t mention is who the web host is or why they recommended SiteLock. Looking at the DNS records the web host is IPOWER. That is one of the many brands names that the Endurance International Group (EIG) does business under. That is rather important in explaining the recommendation, as it turns out that SiteLock’s owners are the CEO and a board member of the company and the company has disclosed that they get 55 percent of revenue coming from the sales of SiteLock’s services through a partnership they have. If there were not those connections we doubt the web host would be recommending SiteLock, considering the many problems with SiteLock (one the reoccurring complaints is that they sell protection services that don’t actually protect websites).

SiteLock Doesn’t Detect Vulnerabilities

The case study doesn’t go in to details as to how the website was cleaned, but no mention was made of doing two important parts of cleanup, making the website secure as possible (which usually mainly involves getting the software up to date) and trying to determine how the website was hacked. Based on our own experience being brought in after them to re-clean websites and everything else we have seen, it is likely those things were not done.

Without knowing what caused the website to be hacked you can’t say what would have prevented it from happening, but we can be fairly sure that SiteLock’s idea of a “proactive approach” isn’t the best way to secure the website going forward:

Once his website was clean, Kasal decided to take a proactive approach to website security by implementing SiteLock® SMART, a daily scanner to help protect his blog from future attacks. SMART provides continuous file scanning to detect vulnerabilities and malware, including backdoor files and malicious code. If malware is identified, it is automatically removed and Kasal is immediately notified.

SMART also provides a full website analysis of each scan, ensuring Kasal’s site is safe and secure at all times.

It is strange that they are describing that as being proactive, since it is clearly reactive. If you are detecting malware on a website, it means it has been hacked and it wasn’t protected. There are further problems with that approach, like the inability to undo the compromise of a website’s data and that SiteLock has a limited ability to remove malicious code automatically (when they are even successful at detecting it).

A quick look at the website shows that is a couple of vulnerabilities that SiteLock must not have detected. Looking at the source code of the website’s pages you scan see that the version 2.9.45 of the plugin WordPress Download Manager is in use:

The plugin is several versions and a couple months out of date, with the next version, 2.9.46, having been released on April 17. That version fixed two vulnerabilities in the plugin, which is somewhat obliquely mentioned in the changelog with these two entries:

  • Added nonce check with settings form
  • Blocked unwanted file type upload

This is a perfect example of where doing the basics would be better, because if the website’s owner was keeping their plugins up to date they would actually be protected against those vulnerabilities. They wouldn’t even have to take manual action do that as there are a number of options available, including our Automatic Plugin Updates plugin, to have plugin updates happen automatically.

Keeping plugins up to date is free, unlike SiteLock’s service, but would another paid service actual have warned about those vulnerabilities? We know of one, our Plugin Vulnerabilities service, which warned about both vulnerabilities even before they were fixed (we also were the ones that discovered one of the vulnerabilities).

One last thing to note is that instead of SiteLock being able to tout that it actually detected those vulnerabilities or any other issue, they instead point to the number items checked:

SiteLock captured billkasal.com’s SMART scan results from a 30-day time frame. During the given 30 days, over 170,000 files, 120,000 links and 15,000 pages were thoroughly scanned for malware.

Sheer numbers clearly don’t equal quality.

Security Companies That Deal With WordPress Websites Should Understand That Usernames Are Not Considered a Secret

When it comes to improving the poor state of security one of the major impediments is security companies. Far too often they either don’t seem to understand the basics of security themselves or are intentionally telling people things that are false as means to push products that are not needed.

While looking into something related to another post we ran into the security company WeWatchYourWebsite again. The last time we did that, we found them providing what was claimed to be an example of hacker looking for infected websites, but was in fact something very different, a hacker trying to exploit a vulnerability in a plugin that was never on a website. Amazingly they claim to “specialize in root cause analysis” despite not having a basic understanding of the topic.

Since then they put out a post showing they didn’t understand the difference between brute force attacks, which are not happening, and dictionary attacks. And a post with this troubling line in reference to a WordPress website:

In this instance the hackers were able to find the admin username and guess the password. So, even though the owner took the step of changing the admin username, using an easily guessed password negates that.

We really can’t emphasize this enough, WordPress usernames are not considered a secret and therefore changing them is not a security step that could be negated.

What makes that mention seems so odd, is they seemed to understand how easy it can be to get the username on a WordPress website currently:

First, the hackers worked at finding out the name of the admin user. There were a number of these in the logs:

“GET /?author=1 HTTP/1.1”

“GET /?author=2 HTTP/1.1”

“GET /?author=3 HTTP/1.1”

“GET /?author=4 HTTP/1.1”

…and continued on by incrementing the integer after “author=”

Apparently it worked as the customer had changed their username for admin.

So either they had seen that WordPress has a major security issue (if the usernames were meant to be a secret) or they should have realized that it isn’t meant to be secret and not made a statement implying otherwise.

Journalists Spread SiteLock’s Fake Claim Involving Nonexistent Legitimate Plugin

When it comes to security journalism, there doesn’t seem to be much actual journalism going on. Instead much of what passes for news coverage these days simply involves repeating the claims of security companies, without doing any fact checking of those claims. This would be a problem just based on the low quality of information coming from security companies, but it looks to us that security companies have realized that in getting coverage what matters is not the truth but saying something that a journalist think they can get clicks by repeating.

A good case in point of journalist simply repeating a security company’s claims we ran across recently was a claimed trending WordPress security issue. Beyond the fact that no evidence was presented that actually backs up the claim that the issue was trending or that the issue was is some way actually significant (and deserved to be covered instead of another issue), something else stood out to us. In the security companies SiteLock’s post on this issue, they claim a “fake” plugin involved in the issue is a forgery of a legitimate plugin:

It is a forgery of a legitimate search engine optimization plugin, WordPress SEO Tools.

In coverage of the issue, that claim was repeated by journalists. Here is how it was reported in the Threatpost’s article:

The fake WP-Base-SEO plugin is a forgery of a legitimate search engine optimization plugin, WordPress SEO Tools.

Here is how it was reported in Infosecurity Magazine’s article:

Dubbed WP-Base-SEO, the plugin is a forgery of a legitimate search engine optimization plugin, called WordPress SEO Tools, according to SiteLock, the firm that originally uncovered the threat.

Finally here how it was reported in SC Magazine’s article, this time without naming the claimed legitimate plugin:

The fake plugin is called WP-Base-SEO and is based on a legitimate SEO module so it is easily overlooked during security scans and seems to be a viable tool by a web team intent on boosting its traffic, said a research team at SiteLock.

The problem with all this is that the supposed legitimate plugin WordPress SEO Tools doesn’t exist. If you do a Google search on the name or on WP SEO Tools it doesn’t bring up results for a plugin with that name. Looking at the Subversion repository that underlies the Plugin Directory, where most plugins are found, there are not entries for a plugin with the slug wordpress-seo-tools or wp-seo-tools.

This should have been something that journalists could have easily checked and if they had look into that they might have realized something was amiss here.

In a quick check over this, something else also stands out to us. While the reason for this issue getting covered is that the “fake” plugin is supposed to be trending, it looks as it might be rather old (or at least based on something that hasn’t been updated in a long time). That is particular noticeable in the screenshot provided by SiteLock of the plugin’s header comments:

The copyright there is 2013, though on its own wouldn’t mean much, what is more noticeable in dating this is this the Plugin URI, which is http://wordpress.org/extend/plugins/. If you visit that URL now you are redirected to https://wordpress.org/plugins/, which is the address of the Plugin Directory. So why would the URL include “extend” when it doesn’t exist the URL you are redirected to? The answer is that the “extend” used to be part of the URL, but that was removed on May 22, 2013 (the switch to HTTPs occurred in 2014). Based on that it is entirely possible this malicious plugin isn’t a new issue, just being promoted that way so that a security company could get coverage.

The Obviousness of Unnatural Reviews for a WordPress Security Plugin

An important element of security is trust, seeing as most people are not going to have ability to independently verify what a security product or service is doing what it is claimed to do and instead have rely on the those behind it to be truthful. What we have seen in our experience with the industry is that they don’t even really attempt to be honest with the public, instead correctly seeing that they can get away with misleading and outright lying because the checks that should exist against that are not working. The end result of this is current poor state of security.

Over at the blog for our Plugin Vulnerabilities service today we looked at a security plugin that fails to actually do its most important function. We also noted that most of the reviews for the plugin look like they came from people that were connected to the plugin, which provided a distorted view of the plugin.

That plugin certainly isn’t alone among WordPress security plugins having many reviews that don’t look to have come naturally. Another plugin we came across within the last few days pretty obviously has unnatural reviews. The plugin WP Security Optimizer has 4 reviews despite having less than 10 active installs:

That is well beyond even an extremely high number of reviews for the amount of active installs. By comparison our plugins have the following mix of reviews to installs:

  • Automatic Plugin Updates: 9 reviews / 10,0000+ active installs
  • Plugin Vulnerabilities: 14 reviews / 5,000+ active installs
  • No Longer in Directory 10 reviews / 1,000 active installs

Not only are the reviews out of line with the number active installs, but three of the four accounts used for the reviews were created on the same day as the review and have not been used for anything else (the fourth was created several days before the review).

Also like many other plugins it is promoted in a way that is likely far from reasonable, considering that the description of the plugin begins:

Prevent hackers to sabotage your rankings in search engines.

While we haven’t tested the plugin against real vulnerabilities yet, it looks like it is mainly focused on trying to hide the fact that a website contains vulnerable software instead of doing anything that could resolve the website being vulnerable. Considering many times hackers don’t do any checks before trying to exploit a vulnerabilities, it wouldn’t do much to prevent hackers from succeeding.

WordPress Plugin Directory’s New Search Algorithm Still Failing To Show Plugin When Searched For By Its Name

Earlier this week the refreshed version of the Plugin Directory section of wordpress.org went live. One of the touted features of it is an improved search algorithm, but the new algorithm clearly still needs some work as it still is having problems showing plugins when they are searched for by name.

While that used to be the case for one of our plugins, changes made during the open beta fixed that. Unfortunately it isn’t the case for another plugin we happened to be doing a search for the other day, BuddyPress Docs.

Here are the first page of results:

It doesn’t show up there and a lot of results don’t look like they could be considered more relevant for the query.

The plugin finally shows up more than half way through the second page of results (22 plugins in all are shown before it):

Unreliable Claim That 1.5 Million WordPress Pages Defaced Is Reminder of the Terribleness of Security Companies/Journalists

In the last day there have been quite a few security journalists writing articles claiming that 1.5 million pages on WordPress websites have been defaced due to a vulnerability that existed in WordPress 4.7.0 and 4.7.1. In looking over those articles we have found that in some cases the claim isn’t actually sourced at all and what appears be the original source for the figure in the others, which came from a security company, isn’t reliable at all and that the journalists ignored a huge red flag that should have warned them that the claimed figure and the source of should not have been relied on.

First let’s look at a couple of the articles with unsourced claims. The Inquirer’s article is titled “WordPress hacking spree sees 1.5 million web pages defaced“; nowhere in the article is a citation for that claim provided. The closest the article gets is this:

According to a report on the BBCthere are millions of pages that have already been defaced thanks to the vulnerability.

In that BBC article the claim is not sourced either:

One estimate suggests more than 1.5 million pages on blogs have been defaced.

In ITworld’s article “Recent WordPress vulnerability used to deface 1.5 million pages” you get a source, but no explanation as to how the number was calculated, which seems like important information to provide:

Since then the number of defaced pages has grown to over 1.5 million and there are 20 different attack signatures, according to statistics from Feedjit, the company behind the Wordfence security plug-in for WordPress. The number of unique affected websites is estimated at around 40,000, as a site can have multiple defaced pages.

Also worth noting here is that there is an estimate of the number of websites impacted, which seems to be the more relevant number to be the headline number, assuming either was accurate. We don’t think there is much question as to why they went with the pages number, with the current state of security journalism click-baitness is more important than providing high quality reporting.

The Bleeping Computer’s article, “Attacks on WordPress Sites Intensify as Hackers Deface Over 1.5 Million Pages” cites nearly identical numbers as to the number of pages and websites:

Attacks on WordPress sites using a vulnerability in the REST API, patched in WordPress version 4.7.2, have intensified over the past two days, as attackers have now defaced over 1.5 million pages, spread across 39,000 unique domains.

It also looks like they are citing Wordfence for their number of web pages defaced as well:

The number grew to over 100,000 pages the next day, but according to a report from fellow web security firm WordFence, these numbers have skyrocketed today to over 1.5 million pages, as there are now 20 hacking groups involved in a defacement turf war.

When you look at Wordfence’s post the claim of 1.5 million pages is based on Google’s estimate of how many pages contain certain “hacked by” phrases:

On the far right we also include the number of defaced pages for each campaign, according to this morning’s Google results.

Are those reliable? The answer seems to be no. Here is how a BBC article from 2012, “Are search engine result figures accurate?“, starts out:

Enter the name Tim Harford into Google and you get 835,000 results.

Or 325,000, or 285,000… I got these widely differing results on computers within metres of each other in the same office at the same time.

So using those as headline number and not disclosing that it is the source (along with a disclaimer as to the questionable accuracy) seems quite inappropriate. It gets worse though, because in Wordfence’s post they take this misleading number and stretch in even further. In their chart they labeled the 1.5 million page estimate as being the number of “Hacked Sites”, not web pages:

That seems like the sort of thing that should have warned journalists away from that, but security journalists don’t seem to care much for accuracy.

The 39,000 unique domains or around 40,000 websites figure also looks to come from the same chart. The problem that appears to be a measure of websites where Wordfence saw an attempt to exploit this on, not the number of websites hacked:

Considering that any WordPress websites running 4.7.1 when 4.7.2 was released would have been automatically updated to 4.7.2 and protected against the exploit long before the attacks started, unless the automatic updates feature wasn’t working on the website (which we don’t see being the case with many websites) or it was disabled (which people sometimes foolishly do), the number of attacks that could have been successful was probably a small portion of the 39,000 attacked.

Unfortunately what has happened here with these inaccurate claims of the size of exploitation are all too common these days due to the poor state of security companies and security journalists.