StudioPress Sites And Sucuri Didn’t Properly Deal With a Hacked Website

Recently we have gotten quite a few questions related to web hosts that include a security service with their hosting service. Considering that web hosts seem to have problems handling the basics of their own security this type of offering seems like it might not be a great idea. Furthermore, most of what needs to be done to keep websites secure isn’t best handled by a security service.

Another issue is that we haven’t seen evidence presented that those types of services are effective at protecting websites and plenty that they are not. One of the pieces of evidence that we have seen that they are not effective is that companies that provide those services often don’t do an important part of properly cleaning up hacked websites. One of the basic components of a proper cleanup is trying to determine how the website has been hacked. If you don’t do that, it leaves open the possibility that the vulnerability is still on the website and can be exploited again. If you are a service that is supposed to protect websites and you don’t even know how they are hacked, you unlikely to do a good job of protecting them.

Security companies can often get away with all of that because the public doesn’t have a good understanding of security and when it comes to the lack of protection, people will often say that such services have been successfully protecting them because they assume that if the website hasn’t been hacked that means the service worked. In reality most websites don’t get hacked, so a service can get credit for providing protection when it does little to nothing to protect websites.

One prominent web security company that all of that would apply to is Sucuri. From what we have seen over the years they don’t seem to have even a basic understanding of security (amazingly one time they warned people to beware of companies that don’t have that). They fail to even handle even more basics elements of cleaning up hacked websites than determining how the website was hacked.

Those kinds of things haven’t stopped the web hosting service StudioPress Sites (previously known as Synthesis) from partnering with them, which they promote in this way:

Finally, we partner with Sucuri for continuous malware monitoring, scanning and remediation. If malware is found we take the responsibility of removing it so you don’t have to worry about it. Additionally, we also scan for advanced threats, including conditional malware and the latest cyber intrusions.

Right before that in their marketing they make this claim:

Our “always on” proprietary intrusion prevention technology works continuously to keep your WordPress install safe from vulnerabilities, intrusions, and exploits. Our years of experience, plus audit input from multiple third parties, allows us to create configurations and settings that keep the bad guys away without handcuffing your working style.

If they were actually able to keep the bad guys out, why would what Sucuri is supposed to be providing be needed? The reality is that when it comes to WordPress, while you see everybody and their brother making claims about their great security, our Plugin Vulnerabilities service seems to be out there alone in catching the kind of serious vulnerabilities in WordPress plugins that would be exploited before there is evidence that they have been exploited (we disclosed two of those just in the last few days). Considering those are a major source of WordPress based websites being hacked, it seems to be a good indications that others are not really do much when it comes to protecting WordPress sites.

We became aware of the partnership between those two companies when someone recently contacted us about a hacked website and mentioned that the website been hacked again after having using Sucuri’s service to clean it up by way of StudioPress Sites. In a situation like that, the first thing we always ask is if the previous company that did the cleanup determined how the website was hacked, since if the source hasn’t been determined and fixed it could explain why the website got hacked again. They responded that they got some generic security advice, but no information about how the website had been hacked or any indication there was an attempt to do that. So it really isn’t all that surprising that it got hacked again.

Out of line with how that hosting is promoted, neither the web host nor Sucuri had been the ones that spotted the hack in the first place. That really isn’t all that surprising since it seems that Sucuri’s scanner is to put it politely, incredibly simplistic, which we base in part on the terrible false positives we have seen it produce.

A Better Cleanup

When we do a hack cleanup of a WordPress website not only do we do it properly, but we also include a free lifetime subscription to Plugin Vulnerabilities service, which will warn you if any of the plugins you use have disclosed vulnerabilities. We will also review all of your installed plugins for serious vulnerabilities using the same technique that we have used to catch numerous serious vulnerabilities in other plugins.

Hacker(s) Using File Manager Plugin to Assist in Taking Malicious Actions with Hacked WordPress Websites

Recently we have done cleanups of a number of hacked WordPress websites where part of what the hacker did after they have gained access to the website involved something we think would be useful to share with others in case they have even less information to go in trying to figure out how the website got hacked (attempting to determine how they were hacked is one of three basic steps in a proper hack cleanup).

In looking at the logging and other data, we have seen that the hackers were logging in to WordPress using existing WordPress accounts on the websites. From there they would install the plugin File Manager (WP File Manager). Here are the set of log entries where that occurred on one of the websites:

121.118.203.38 – – [15/Jan/2018:14:41:04 -0700] “GET /wp-login.php HTTP/1.1” 200 1693 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:07 -0700] “POST /wp-login.php HTTP/1.1” 302 1258 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:09 -0700] “GET /wp-admin/ HTTP/1.1” 200 22557 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:24 -0700] “POST /wp-admin/admin-ajax.php HTTP/1.1” 200 553 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:26 -0700] “GET /wp-admin/plugin-install.php?tab=plugin-information&plugin=wp-file-manager& HTTP/1.1” 200 9499 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:31 -0700] “GET /wp-admin/update.php?action=install-plugin&plugin=wp-file-manager&_wpnonce=c0ba6299b7 HTTP/1.1” 200 10849 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:37 -0700] “GET /wp-admin/plugins.php?action=activate&plugin=wp-file-manager%2Ffile_folder_manager.php&_wpnonce=67fdf3eee0 HTTP/1.1” 302 480 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”

As you can guess from the name that plugin is a file manager. The hackers then use the legitimate capabilities of that to modify existing files or add new files with malicious code. Here are the log entries from the same website where the same hacker looks to have logged in from another IP address and accessed the plugins functionality:

189.72.69.203 – – [15/Jan/2018:15:11:14 -0700] “GET /wp-login.php HTTP/1.0” 200 1731 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:18 -0700] “POST /wp-login.php HTTP/1.0” 302 1296 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:21 -0700] “GET /wp-admin/ HTTP/1.1” 200 22745 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:26 -0700] “GET /wp-admin/admin.php?page=wp_file_manager HTTP/1.1” 200 12922 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:31 -0700] “GET /wp-admin/admin-ajax.php?action=mk_file_folder_manager&_wpnonce=4028a67f1f&cmd=open&target=&init=1&tree=1 HTTP/1.1” 200 3150 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:35 -0700] “POST /wp-admin/admin-ajax.php HTTP/1.1” 200 2068 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”

The most important question in all this is how the hackers got access to the logins for the websites, since without access they couldn’t have installed the plugin or done anything else. Unfortunately the cause is something we haven’t been able to say for sure since the evidence we have is somewhat limited when it comes to determining that part of these hacks.

In at least some of the cases the website were using extremely weak passwords (on one website the password was “admin1234”), so it is possible that a previous dictionary attack had determined the password. A dictionary attack involves try to log in using common passwords. Those types of attacks are fairly common, unlike brute force attacks, which despite inaccurate claims frequently made by security companies, are, based on those companies own evidence, not happening. The logging available so far hasn’t shown that occurring though, but it could have occurred outside the time period that there was logging available (the longer websites store logging the easier it would be to trace the original source of hacks).

In some instances the password being used was also used as the password for other services as well, so it possible that it was compromised somewhere else and the hackers tried it on the websites.

That all leads to the first take away from this, which is to make sure to use strong passwords (something WordPress does a good of making sure you can do) and to use separate password for each login connected to a website.

The second is that if you are dealing with a hacked website where the plugin File Manager was recently installed and it wasn’t installed by someone involved with the website, a compromise of a WordPress account with the Administrator role should be considered a possible source of the hack and further investigated. In one of the websites the plugin was later removed by the hacker, so you if see logging showing it being used, but it isn’t currently installed, that could have occurred on the website you are dealing with as well.

The third is that is that trying limit hackers once they have high level access is not necessarily very useful. In the past we have seen it suggested disabling the plugin and theme editors, since hackers could use those to modify files with malicious code. But as what happened here shows, hackers can easily get around that possible limitation.

Unlike Wordfence, We Fully Guarantee Our Hack Cleanups of WordPress Websites

One of the things that we often get asked about when it comes to hack cleanups, is how long we guarantee them. The answer is quite simple, if the issue comes back that means that we didn’t do something right and we wouldn’t charge anything additional to get it properly resolved. We would think that would be true of any upstanding company, but clearly most of the web security industry doesn’t feel that way, as we recently noticed with Wordfence.

When we discuss cleaning up hacked websites on our blog we don’t say that you should hire us, but that should hire someone that does things properly. That isn’t the case with Wordfence, which probably tells you a lot about them, as we saw recently with a blog post they wrote:

The most reliable way to recover if your website is hacked is to use our site cleaning service. Our team of experts will clean your site and get it back online as quickly as possible, and the service includes a detailed report and a 90-day guarantee.

What also stood out was there was their 90-day guarantee.

Looking at the page for that service, the backing they offer for their service is even more limited, as they say:

Work guaranteed for 90 days from service only if post-service recommendations are followed.

Who knows what those recommendations are, but that sounds like a way for them to weasel out of making things right if things went wrong.

There is another problem with a guarantee like this, based on what we have seen in often being brought in re-clean up hacked websites after someone else didn’t do it properly. Often times people haven’t realized that the issue hasn’t been properly fixed until after 90 days. When we are contacted about re-cleaning a website we always suggest that people go back to the people that originally did the cleanup and get them to do it right (even though if the previous company does that, it means less money for us), since if it was us, we would want to make things right . But with Wordfence if you noticed the issue outside of 90 days, you would be stuck paying them again if you did that (or needing to hire someone else to do it again).

Something else about how they promote their service really needs to be noted:

As the creators of the most popular WordPress security plugin, we have the most expertise in the industry.

Having the most popular security plugin doesn’t mean that they have the most expertise, it just means they have the most popular plugin. As we have mentioned in the past, the reality is that Wordfence has a scary lack of security knowledge. So how do they have the most popular security plugin? Part of the answer is to just blatantly lie. For example, the second sentence of the description of the plugin on wordpress.org until two weeks ago (and is now in the answer to the FAQ question “How does Wordfence Security protect sites from attackers?”) was this unqualified claim that it will protect your website from being hacked:

Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.

The reality is that a WordPress plugin couldn’t possibly stop websites from being hacked in some ways (which Wordfence is well aware of) and Wordfence actually promotes their paid service as leaving people relying only on their plugin insecure. It seems like a bad idea to trust a company to clean up a hack when they have show that they have no qualms about lying to you and everyone else.

The second most popular plugin indicates that plugin popularity is not necessarily synonymous with a company that you want have anything to do with as that plugin uses a non-existent threat to collect users’ email addresses and had a “One-Click Secure” Button that did nothing except claim the website has been “Secured”.

Another element of Wordfence’s marketing stood out to us as well:

By work with them, they really mean they request a review through the same automated process as you or anyone else can use to do that.

A Better Cleanup

When we do a hack cleanup of a WordPress website not only do we do it properly, which based on some of stuff we have seen from Wordfence seems less likely. But we also include a free lifetime subscription to Plugin Vulnerabilities service, which will warn you if any of the plugins you use have disclosed vulnerabilities (with Wordfence you get widely inaccurate data on plugin vulnerabilities). We will also review all of your installed plugins for serious vulnerabilities using the same technique that we have used to catch numerous serious vulnerabilities in other plugins.

Wordfence Employee Admits the Company Knows Wordfence Security Won’t Stop All Hacks as They Continue To Claim Otherwise

What we have been noticing more and more is how much lying is done by the security industry. Considering that trust is an important part of security and you often have to rely on their claims about what protection their products and services might provide, that is a big issue.

One glaring example of this when it comes to WordPress related security, is a prominent claim made about the most popular security plugin, Wordfence Security. The second sentence of the description on its page on wordpress.org is:

Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.

Could a WordPress security plugin stop some hacks? Sure. Can it stop all them, as this unqualified statement by the makers of the plugin would lead to you believe? No.

People do believe that claim though, as we were recently reminded by a topic on the WordPress Support Forum that we ran across while doing monitoring for our Plugin Vulnerabilities service. The topic is titled “Hacked anyway!” and the message reads:

Well.
I installed Wordfence, and got hacked anyway.
Not sure whether or not to trust it anymore.
A defacement hack by the look of it.
Yet, when I run a full scan, it tells me all is OK.
WTF?
Any suggetions?

The reply from a Wordfence employee reads in part:

Often when we see sites get hacked despite having Wordfence, or we see them getting hacked repeatedly it’s because of a vulnerability on the server.

So they know how they promote the plugin isn’t accurate, but they continue to market it that way anyway. This is far from the only lie that we have seen from the company behind Wordfence Security. We wonder if and when the public will realize that the company behind it isn’t trustworthy?

The other thing worth noting about this situation is that it is also a reminder that Wordfence Security isn’t all that great at detecting that websites are hacked, which is also contrary to what people have been lead to believe. If it was better at that, someone could try to make an argument that while the plugin can’t stop a number of types of hack, it could provide effective mitigation against the damage caused by those hacks.

SiteLock Report Leads to False Claims About the Security of WordPress Websites

One of the problems when it comes to improving security is there is so little accurate information out there. Often times security companies are putting out misleading or outright false claims. When their information is repeated by security journalists the quality of it usually degrades from the already often low quality. As example of what happens when security journalists repeat security companies’ claims was something we recently ran across related to SiteLock.

In an article on CISO MAG the following claim was made that seem unlikely to be true:

SiteLock’s analysis also showed that a website’s content management system had an impact on overall security. Forty-four percent of websites using WordPress CMS had not been updated for over a year at the time of filing this report.

We went to look into that because that because it seemed like it would be a good example of SiteLock getting stuff wrong, but in looking at the report what SiteLock actually claim was very different. What they said hasn’t been updated in a year are plugins in the Plugin Directory:

44% of plugins in the WordPress repository have not been updated in over a year

It is important to note that doesn’t mean that those plugins are somehow insecure, though if plugins are not at least being updated to list them being compatible with newer versions of WordPress there is a greater chance that if there is a security vulnerability found that it will not be fixed promptly or at all (though in reporting many vulnerabilities to WordPress plugin developers through our Plugin Vulnerabilities service even very recently updated plugins are not always fixed in a timely manner or at all).

Making that incorrect claim seem odder is the beginning of the next paragraph of the CISO MAG article:

Nearly seven in 10 infected WordPress websites had the latest security patches installed, but were compromised because of vulnerable plugins.

If “nearly 7 in 10 had the latest security patches” then it wouldn’t make much sense that 44 percent of them hadn’t been updated in the last year.

The claim that the website “compromised because of vulnerable plugins” is also not what the report says. Instead it says:

69% of infected WordPress websites were running the latest security patches for WordPress core at the time of compromise.

This data illustrates that even when running a version of WordPress with all of the latest security patches, a vulnerable plugin or theme can just as easily lead to a compromise.

Looking at the rest of the report there were a couple of other WordPress related items that stood out. The first thing is a mention of “publications” that “inaccurately implied that WordPress websites which aren’t running the newest version of WordPress are insecure”:

NOTE: Many publications have inaccurately implied that WordPress websites which aren’t running the newest version of WordPress are insecure. As of the end of Q2 2017, the WordPress community actively provided security fixes for all versions of WordPress from v3.7 to the current v4.8. Our research takes into account each security patch release for every version of WordPress in Q2 2017. For example, WordPress v3.7.21 contains all of the same security fixes implemented in the current version, v4.8. In theory, this makes v3.7.21 as safe as v4.8.

We are not sure what publications they are referring to, but one security company comes to mind, SiteLock, which has been falsely claiming that websites are insecure when running the latest version of older versions of WordPress. We first noticed this back in September of last year and SiteLock was clearly aware of that post, but as of at least June they were still doing this.

Another element of the report repeats a WordPress related falsehood from SiteLock that we debunked in April:

Fake Plugins: Trend Maricopa

In what SiteLock Research would call an “oldie but a baddie,” we saw a trend in the first week of April that centered on the return of an old trick targeting WordPress websites where malware disguised itself as a legitimate forum plugin in the WordPress plugin directory. This ruse, while easily dispatched by specialized malware detection systems, would just as easily escape the concern of an untrained eye. Fake plugin malware iterations continue to be developed and deployed because, quite simply, most people don’t notice them. In a world where the majority of website owners don’t take a proactive approach to malware prevention or remediation, persistent infections continue to be common.

The reality is the supposed legitimate plugin, WordPress SEO Tools, has never existed, whether in the Plugin Directory or otherwise. We don’t understand why SiteLock is continuing to peddle that falsehood when it is so easy to confirm it to be false.

OneHourSiteFix’s Crazy Claims About WordPress Websites Being Hacked

Recently we got a spam comment on one of our posts that was meant to provide a link to onehoursitefix.com. The name given with the comment was “how to fix a hacked site” and the comment, which was irrelevant to the post, was:

You might be scratching your head at this point because you are
certainly not sure what tattoo. It is also a classical technique, which started out
for the dancers to seem weightless. s always preferable to let someone
know your location going and which route you.

It probably doesn’t say great things about that website, OneHourSiteFix, that they appear to need to promote themselves in that way, but that turns out to be much less concerning than the blog post we noticed linked to from their homepage.

The title of the post in the title HTML tag is “WordPress Website Defaced ? Due To A Well Known Security Company ?” and the on page title is “WORDPRESS PLUGIN VULNERABILITY MEANS MILLIONS FIND THEIR WORDPRESS WEBSITE DEFACED BY HACKERS”. The post is listed as being put out on June 26, 2017.

The first paragraph seems to be written by someone who has absolutely no idea what they are talking about:

Free open-source website and blog creation tool ‘WordPress’ has left millions of pages defaced, due to a remote code execution (RCE) feature being added to the package. This feature has allowed hackers to take control of pages using WordPress plugins allowing attackers control over editorial features in order to vandalize pages or even worse execute malicious payloads. Plugins are those great bits of extra software you can add to your WordPress site to do everything from show a map of visitors to show a fancy photo gallery. Plugins however, have always been a l known and documented ‘attack vector’ for hackers. An attack vector being ‘a way in’ or path into a website. The end result is millions of site owners have found their WordPress website defaced by hackers.

What it sounds like this person might referring to is a vulnerability that had existed in WordPress 4.7.0 and 4.7.1 that allowed attackers to change the content of posts and was fixed in January. It wasn’t a “remote code execution (RCE) feature” and there hasn’t been something like that added to WordPress. The vulnerability could have had more serious consequences if certain plugins that allow PHP code to be run in posts, which might be what the reference to plugins there is trying to refer to. There was nothing that could remotely be what is described there that happened in June, what did happen in January also doesn’t appear to have impacted millions of websites.

That explanation seems more likely based on the next paragraph (though it again doesn’t make much sense as written):

A well known security firm released a statement saying they had detected multiple hackers seizing control of sites. A backdoor in the protocol allows attackers to inject ads, spam and affiliate links. The security firm expects many more attacks to follow and even advised users to disable the plugins due to attackers using these them to insert malware into any affected website More often than not the old, ‘Hacked By GeNErAL’ ! types of defacement are being replaced by monetising hacks with compromised sites being used to make money for the hacker via the use of paid ads (selling everything from viagra, research chemicals to fake crypto currency exchanges) or redirect them to an ‘online pharmacy’
The fourth paragraph claims, which is below, would seem to confusedly reference what happened as well. As the exploitation only started after it was disclosed that WordPress 4.7.2 had included a fix for the vulnerability a week after that version was released.
What is also interesting is that before the security company released the details of the hack, very few WordPress websites had actually been compromised. The timeline in which the hack was detected, details released and then the fix released – does arouse suspicions amongst the conspiracy theorists amongst us.
The third paragraph makes a claim that seems crazy:
In March alone, over 45 million of WordPress websites were defaced and infectd. Many websites are still affected with many of their users not even realising that hidden within their blog there is a page that is selling some seedy pharmaceutical product . Often these hacked website pages are only found by using very specific search terms in google so blog owners are blissfully unaware that their sweet and innocent cupcake blog is actually harbouring a deep secret within the blog pages…
If it were true that 45 million WordPress website had been “defaced and infected” in just that month that would likely mean that a majority of WordPress had that happen to them. While the numbers seem to be a bit of an estimate, there are figures out there for the total number of WordPress websites at figures like 75 million according to a Forbes article from December. Clearly over half of WordPress websites were not hit during that month.

Another Very Odd Claim

In looking at their service there is another element that makes it sound like something is very amiss. One part of their service is cleaning up hacked websites and the other is a web application firewall (WAF) that is supposed to stop them from being hacked again. What is missing is the thing that should tie those together, determining how they website got hacked. If you don’t do that you can insure the vulnerability that was exploited has been fixed and the website won’t get hit again. That would also seem important to make a WAF effective.

Instead of doing what would actually prevent the website from being hacked again they make a claim that doesn’t sound believable:

 IN ADDITION – our security experts manually analyse EVERY element of your site – every row in your database and every line of your files is checked and cleaned. This layered approach ensures we don’t just throw the hackers off a site – we slam the door on them as well.

That would take a very long time to do on most websites, yet somehow they are also going to fix the website in an hour, and it would likely be very ineffective since the sheer amount of information being reviewed would make it less likely that someone would spot a real issue among everything else.

On the page about their cleanup service there was a linked review that while giving them five-stars and seemed positive, indicated that this person’s websites have been repeatedly hacked:

Always quick, always clean.

OneHourSiteFix staff goes above and beyond everytime we’ve had an issue. Quick service, speedy cleaning, and even making sure sites like Google rank you site as safe again. We can’t thank them enough for keeping our servers from getting shut down by our service provider due to infections/spam. Top notch, our go to company for website cleaning everytime! Need help, look no further!
Which isn’t surprising based on what else we saw.

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.