WordPress

WordPress Doesn’t Want You To Know That WordCamp Sponsor SiteLock Takes Advantage of People

When it comes to the web security company SiteLock taking advantage of people, their web hosting partners have long been critical component of that. More recently there has been a new partner helping them to present a public face very different than the company that people end up dealing with if they have the misfortune of signing up for their services. That would be WordPress, which has allowed SiteLock to participate and sponsor WordPress’ WordCamp conferences.

It isn’t a situation where the people involved in running the WordCamps are not aware of the what SiteLock does. We contacted them back in September asking for a comment for a post we were preparing raising our concerns about the situation. We didn’t receive a response, but we received quite a bit of traffic to a post included in the message to them, shortly after we sent the message, so they seem to have reviewed it. SiteLock’s involvement has continued since then, which indicates to us that the WordPress folks can’t justify what they are doing, but will continue doing it anyway.

Fast forward to last week when in our monitoring of what SiteLock is up to we can across a post on the website for this weeks WordCamp US praising SiteLock. Wanting to let people know the reality of SiteLock we posted the following comment on the post:

It is rather unfortunate that you are promoting SiteLock in this way, as this company is quite bad at what they do and take advantage of so many people.

For example, a couple of months ago we were brought to fix a WordPress website after their cleanup left it broken, http://www.whitefirdesign.com/blog/2016/09/14/godaddy-and-sitelock-make-a-mess-of-a-hack-cleanup-and-drop-the-ball-on-security-as-well/. While fixing it we found that there were a couple of much larger issues, they had left the hacker with access to the website and didn’t detect that one of their web hosting partners, who had gotten the website’s owner to hire SiteLock in the first place, had a serious security issue that was leading to website being hacked.

Around the same time we found that they were spreading false information about vulnerabilities in WordPress to their customer, http://www.whitefirdesign.com/blog/2016/09/06/sitelock-spreading-false-information-about-wordpress-security-to-their-customers-through-their-platform-scan-for-wordpress/.

If you do a search for “sitelock scam” you will see a more of what SiteLock is really doing.

One thing we mentioned we think is important emphasis, is that SiteLock was (and maybe still is) claiming that customer’s website running older version of WordPress have vulnerabilities that they don’t. This was due to SiteLock not having a basic understanding of how WordPress handles security, which they should considering that is very important when properly cleaning up hacked websites and protecting them against future hacks, both of which are services they offer (some explanation to this might be that for one of their main protection services they don’t actually provide the service themselves, while claiming to). It is against that backdrop that one part of the WordCamp post sticks out:

With 2017 just around the corner, SiteLock hopes to continue their strong support for WordPress and WordCamps and make 2017 the best year yet!

Maybe it is just us, but it doesn’t seem that spreading false claims of vulnerabilities in WordPress based website shows support for WordPress, strong or otherwise.

We left that comment on Tuesday afternoon, by the next morning the existing comments (not just ours) on the post were gone and the ability to comment was removed. By comparison the previous post and next one still are open for comments and include comments. Again the WordPress folks would rather sweep under the rug the reality of what SiteLock is up to while being involved with WordCamps than deal with the situation.

What makes this all the more troubling is at the same time WordPress is helping to promote a very bad security company, they are intentionally not warning people when they are using insecure plugins, which could lead websites to be hacked and then those websites might wind up being taken advantage of by a bad security company like SiteLock.

Anti-Malware Security and Brute-Force Firewall Plugin Uses Non-Existent Brute Force Attacks To Get Registrations and Donations

When it comes to WordPress security, one thing we can’t emphasis enough is that people putting out security products and services for it don’t seem to have a good grasp of security. One of the most glaring examples of this is how often the falsehood that there are lots of brute force attacks against WordPress admin passwords happening, despite the evidence presented that they are happening actually showing the exact opposite.

Recently, while doing testing on how WordPress security plugins did in protecting against real world plugin vulnerabilities (short version, they haven’t done well in the testing so far) for our Plugin Vulnerabilities service we ran across the plugin Anti-Malware Security and Brute-Force Firewall. The plugin is one of the most popular security plugins, with 100,000+ active installs according to wordpress.org.

On the Firewalls Options page you will find that they have an option for Brute-force Protection:

anti-malware-security-and-brute-force-firewall-brute-force-protection

So they are using a non-existent threat to try to get people to register and donate. On top of that, the protection seems to involving modify a core file, which isn’t a very good idea.

WordPress Giving Legitimacy to SiteLock By Allowing Them to Sponsor and Attend WordCamps

As we have continued to hear more troubling stories from the public about the web security SiteLock’s business practices and seen the damage they can cause, we have been very troubled that other organizations would provide them with legitimacy by getting involved with them.

One set of organizations is the various web hosts that had partnered with them. We recently found that the CEO of the parent company of many of those web hosting partners is also the owner of SiteLock, so it isn’t surprising that those web hosts wouldn’t have a problem with what is going on since their CEO is in on it. It would seem the others are getting paid handsomely to help them out.

Due to SiteLock discovering a couple of vulnerabilities in WordPress plugins some time ago, we had started following their blog for Plugin Vulnerabilities service. While no more vulnerabilities were disclosed on the blog, we did start noticing that they were sponsoring and attending quite a few of the official conferences for WordPress, WordCamps (and oddly giving presentations unrelated to security, including Creating a Digital Download Business – What to Sell, How to Sell It and Shortcuts to Success. and Contact Forms are Boring – 5 Creative Ways to Use Forms in WordPress.). That seems like a really bad idea, considering that imprimatur of WordPress is then connected with this company, provided them legitimacy they shouldn’t have.

There is also the issue that money that SiteLock makes taking advantage of people funding these WordCamps, which seems to be reasonable to consider as a moral and ethical issue.

It also doesn’t seem to be great idea to have a company that has shown that they lack a basic understanding of how WordPress responds to security isues, leading them falsely claim that WordPress website contain critical vulnerabilities, involved with WordPress events.

Just in the next couples of weeks SiteLock is sponsoring WordCamps in Pittsburgh, Raleigh (with a presentation also not security related, Using Curated Content in WordPress—Why and How), and Dallas. They are also a sponsor of the WordCamp for the whole US in December.

We would like be able to give you WordPress and WordCamp’s side of the story as to why they have are involved with SiteLock, but it has been a week since we contacted them with the following email asking for comment and we haven’t received any response:

We are writing a post about the fact that the security company SiteLock is being allowed to sponsor and attend numerous WordCamps despite be well known for taking advantage of its customers.

We first became aware of their practices after we had written a number of posts about other issues we had noticed involving them and then we started getting contacted by people who had been take advantage of by them, http://www.whitefirdesign.com/blog/2016/05/03/it-looks-like-sitelock-is-scamming-people/. There are a litany of complaints that can be see if you do a search on Google for something like “SiteLock scam”, including this page with numerous complaints https://sitelock.pissedconsumer.com/. While some of the complaints seem to be unfair to them, there is a pretty clear pattern of actions that seem quite problematic, to say the least.

We would like to include in our post any comment you might have as to why they are allowed to sponsor and attend WordCamps in light of that, so that the public has a better understanding of why WordCamps would get involved with such a company and take money that has been made by taking advantage of people. We would also like to include in our post any comment you might have as to any restrictions you place on what kinds of companies can sponsor and attend WordCamps.

If they were not aware of SiteLock’s reputation before, it seems that could have at least indicated that and that they reviewing things, but the lack of response points to them being aware of what SiteLock does and being okay with being involved with them.

If would like to let them know how you feel about that you can contact the central organization for WordCamp’s here. You also might want to contact ones happening locally that SiteLock is involved in, to see if they are aware of what one their sponsors is up to.

Hosting Recommendation Too

This isn’t the only Sitelock connection with WordPress. As we discussed in a recent post, one of the owners of Sitelock is also the CEO of a major web hosting provide, Endurance International Group. Endurance has many brand names they provide web hosting under, one of those being Bluehost. Bluehost has come up repeatedly in complaints about Sitelock. Bluehost is also one of the web hosts listed on the Hosting page on wordpress.org:

That page has a top level menu link of the website, so we would assume that brings in a lot of business to them.

GoDaddy and SiteLock Make a Mess of a Hack Cleanup (And Drop The Ball on Security As Well)

In the complaints about the web security company SiteLock we have seen, one of the things that comes up frequently is the widely variable and often times excessive prices for their services. In some cases the pricing would be within reason if you were getting a high quality service, but as we found while helping to fix a website after SiteLock did a malware removal on it few days ago, you get the opposite of that from them.

This incident involved one of SiteLock’s partner web host, though not one the ones run by the owners of SiteLock. Instead it is GoDaddy, for which we found a couple of security issues on their end while looking into this as well.

What happened in this cases is that SiteLock through GoDaddy was hired to clean up malware on the website. Afterwards though the website was screwed up, with the styling gone and shortcodes showing up on the pages (instead of being processed). GoDaddy told the website’s owner that they would need to have someone update WordPress and re-install the theme they used.

None of this made a whole lot of sense. After removing malware or doing some other cleanup the website should appear as it did before. The theme shouldn’t be missing, unless it had been completely replaced with malicious code (which we have never seen happen). Also a part of a proper cleanup is making the website secure as possible, which would, in part ,involve updating the software on the website.

When we got in to the WordPress admin area to look over things we found that theme actually was still there, but wasn’t activated. The only reason we could think for changing to another theme would be to check if the theme being used was causing the malware to be served up, but after that checking was finished it should be reactivated.

We also found that all of the plugins were deactivated, the same explanation as the theme might explain them being deactivated. But again they should have been reactivated if that was the case. This was more problematic to deal with since we didn’t know which, if any, of the plugins were not active before the cleanup and did not need to be re-activated.

Not only did WordPress still need to be updated, but so did the plugins and themes.

Once we got a handle of those things we were able to bring the website back to working order, but further looking showed that items added by the hacker still existed (and would have allowed them continued wide access to the website) and the vulnerability that could have allowed the hacker access to begin with still existed on the website, so the hacker could have easily gotten back in.

Malicious Administrators and a Vulnerable Plugin

When cleaning up a hacked WordPress website one of thing you want to check for is the existence of users that should not exists, with an emphasis on users with Administrator role, since they have wide ranging access. Sometimes those added accounts are rather obvious, in the case of this website a couple had the email adress “backup@wordpress.org”. While seemly intended to look innocuous, there shouldn’t be any account with email addresses from wordpress.org on a website. Either SiteLock did not spot those or didn’t even do any check for that.

Looking at the details of the users in the database would tell you something more about this. In the following screenshot you can see that for the two account with the “backup@wordpress.org” and one other have the user_registered field not filled in (the others listed there have dates from before the website existed and before the original account on the website was created):

That indicates that the accounts were not created through the normal process in WordPress. One other way to do that is with direct access to the database.

That brings us to another thing that SiteLock missed, one the installed plugins, Revolution Slider, had an arbitrary file viewing vulnerability in the version of the plugin installed (you can check if a website is using a vulnerable version of that and if other plugins have vulnerabilities hackers are targeting using our Plugin Vulnerabilities plugin). Hackers frequently target that type of vulnerability to try to view the contents of WordPress configuration file, wp-config.php. That file contains database credentials for the website, so accessing that could allow a hacker access to the database, which they could then use to add new users.

GoDaddy’s Security Failings

We then went to check to see if the vulnerability was in fact exploitable on the website and we found that connection was dropping when we made the request to exploit it, which looked to be GoDaddy blocking the request. Unfortunately their protection is incredibly easy to evade.

The original request we made was the following, which was stopped:

/wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php

This request was not stopped:

/wp-admin/admin-ajax.php?action=revslider_show_image&img=..%2Fwp-config.php

The only change was that the “/” right before “wp-config.php” has been encoded, changing it to “%2”.

The fragility of such protection seems to pretty common, as earlier this week we found that two WordPress security plugins protection against another vulnerability could bypassed by simply adding and “\” in the right location (the 9 other WordPress security plugins we tested provided no protection).

Remote Database Access

Even if a hacker gets the database credentials by exploiting an arbitrary file viewing vulnerability they still need some method to access the database. In the case of the database for the website remote access is permitted, which allows someone to connect to the database from outside of GoDaddy’s systems. That type of access makes it really easy for a hacker, so it should be disabled by default.

In looking how we could disable remote access to the database, we found that based on their documentation it shouldn’t have even been enabled. The documentation says that you need to enable direct access when creating a database for to connect remotely:

Connecting remotely to a database lets you manage it using tools like MySQL Query Browser,MySQL Workbench, or Microsoft SQL Server Management Studio Express.

If you want to connect remotely to a database, you must enable Direct Database Access when setting it up¹ — you cannot enable it later.

But the database in question is listed as not allowing direct access:

So something isn’t right.

If we didn’t know what SiteLock was up to at this point we would be asking why they had not noticed those problems with the partner GoDaddy’s security and gotten them to fix them, but knowing what they are doing it isn’t surprising they wouldn’t have done that. If anything getting their partners to improve their security would mean less money for them and less money for the partners as well.

If you want a hacked WordPress website cleaned up properly, we are always available to help.

SiteLock Spreading False Information About WordPress’ Security To Their Customers Through Their Platform Scan for WordPress

A couple weeks ago we had a post about the WordPress security company Wordfence’s scary lack of security knowledge, which something they certainly are not alone in among security companies with a focus on WordPress. Another such company is SiteLock, that in a recent post announcing a new feature that is supposed to warn of known vulnerabilities in WordPress, showed they lack a basic of understanding of how WordPress handles security issues, leading to SiteLock warning their customers of WordPress vulnerabilities that don’t actually exist on their websites.

In the fourth paragraph of the post they say something that would red raise a big red flag from anyone who actually some knowledge of WordPress security:

Vulnerabilities can range from cross-site scripting (XSS) and SQL injection (SQLi), to authorization bypass. Issues are presented with their name, category, severity, a summary of the issue, and a more detailed description. For example, when scanning a WordPress website running v3.9.13, many serious vulnerabilities are found detailed in the scan report.

The reason for the red flag is that WordPress 3.9.13 is the latest version of WordPress 3.9, so that version should have little to no known security vulnerabilities. To understand why that it helps to understand how WordPress handles security updates. Back in WordPress 3.7 a new feature, automatic background updates, was introduced. This allows WordPress to automatically update between minor versions, so a website would automatically updated from 3.9.12 to 3.9.13, but would not automatically update to 4.0. Alongside of that WordPress started releasing security updates for older versions of WordPress that contain that feature, even as they moved on to newer versions of WordPress. So for example when the security release 4.5.3 was put out, so was 3.9.13, with the same fixes.

So while you should be keeping up to date with WordPress, if you are running WordPress 3.7 or above you should still be relatively secure against WordPress vulnerabilities since you would normally be getting those security updates. If you deal with the security of WordPress websites and in particular if you deal with cleaning up hacked websites, this is something you absolutely should know since it plays an important role in the determining the possible sources of the hack. SiteLock does those things, but clearly isn’t aware of this. Which you can tell by screenshot of their scan report warning about a couple of “Critical” severity vulnerabilities in WordPress 3.9.13 that don’t actually exist in that version:

[The following image is missing because SiteLock doesn’t want to you to be able see text they copied from other people’s websites.]

For the first, it was fixed in 3.9.8, which includes the same fixes as 4.2.4:

From the announcement post, WordPress 3.9.8 fixes three cross-site scripting vulnerabilities and a potential SQL injection that could be used to compromise a site (CVE-2015-2213).

It also includes a fix for a potential timing side-channel attack and prevents an attacker from locking a post from being edited.

For the second, it was fixed in 3.9.4, which includes the same fixes as 4.1.2:

From the announcement post:

A serious critical cross-site scripting vulnerability, which could enable anonymous users to compromise a site.

Files with invalid or unsafe names could be upload.

Some plugins are vulnerable to an SQL injection attack.

A very limited cross-site scripting vulnerability could be used as part of a social engineering attack.

Four hardening changes, including better validation of post titles within the Dashboard.

The final paragraph of their post doesn’t show good grasp of the reality of securing WordPress websites:

In WordPress security, knowing you have a vulnerability is half the battle. Taking action to remediate vulnerabilities is the other half. Fortunately, as many WordPressers know, the majority of issues found will likely be resolved by simply updating the WordPress core, plugins and themes. However, most WordPress users don’t regularly check the WordPress.org forums or subscribe to notifications about plugins, so they may not be notified of major security issues that haven’t yet been patched. With the new Platform Scan for WordPress, we are increasing the visibility of security concerns to help you be the most informed WordPress user you can be.

Your focus should be first and foremost on keeping the software on your website up to date, since the reality is that you will not always know if a new version includes a security fix. So knowing about vulnerabilities is much less than “half the battle”. Another problem, we know from running our Plugin Vulnerabilities service, is that even if “regularly check the WordPress.org forums or subscribe to notifications about plugins” you won’t know about many unpatched vulnerabilities out there, as lots of vulnerabilities appear to be known and being exploited by hackers, but no one has been noticing them, until we started actually doing the work needed to find them. So could SiteLock play a similar role? It is possible, but based on their track record and the fact that they look to be just reusing existing vulnerability data (which doesn’t even include many vulnerabilities that we have disclosed that exist in the current versions of plugins) it seems unlikely. If you want to be most informed WordPress user when it comes plugin vulnerabilities then signing up for our service would do that over SiteLock’s.

SiteLock’s post doesn’t say where their data comes from (which raises another red flag), but what is shown in the scan results screenshot in their post it looks they are using data from the WPScan Vulnerability Database and adding in some additional information from the US-CERT/NIST. Considering that we have found that the WPScan Vulnerability Database has some serious quality issues when it comes to their listing of plugin vulnerabilities, SiteLock’s data is likely to also likely to have those issues as well.

We would have placed a comment on their post letting them of the problem with their data, but they don’t allow comments (maybe because they would be inundated with complaints about how they treat their customers).

Use of Very Outdated Versions of WordPress Security Plugin Is a Reminder of the Challenges to Improving Security

In cleaning up lots of hacked WordPress websites over the years one thing that we have noticed fairly often is that there are security plugins installed (that clearly didn’t actually protect the website from being hacked, since it got hacked) and on those websites the security plugin(s) and other installed plugins haven’t been kept up to date. Keeping the plugins up to date is going provide you a lot more protection than a security plugin is going to provide (if the security plugins provide any protection at all), so that combination surprised us at first. Even with that knowledge, something we ran across recently stuck out to us.

While doing some checks over security plugins for security issues in them for our Plugin Vulnerabilities service, we recently spotted a couple in the plugin Centrora Security. We have notified them of the issue and hopefully the vulnerabilities will be fixed soon. While looking over the plugin we noticed on the plugin’s Stats page that most of the active installs seem to be running quite out of date versions.

The current release, 6.5, is only used on 26.8 percentage of the websites using it according to wordpress.org’s data:

centrora-security-versions-in-use

The breakdown for the other versions shown there are:

1.0: 12.5%
1.6: 29.2%
2.2.: 11.9%
other: 19.6%

One possible explanation for that could have been that the plugin had jumped a lot of versions recently, but looking back at when the older versions were released shows that isn’t the case here. Version 1.0 was superseded with version 1.5 on February 13, 2013. Version 1.6 was superseded with version 2.0 on September 10, 2013. Version 2.2 was superseded with version 3.0 on April 4, 2014.

Another possibility would be that websites using the plugin are still on an older version of WordPress that isn’t’ compatible with newer versions of the plugin. The current version is listed as requiring WordPress version 3.7 or higher, which would make it compatible with the vast majority of WordPress websites based on WordPress’ chart of versions of WordPress currently being used:

wordpress-version-in-use-chart

Looking at what versions of WordPress were required for the old releases doesn’t seem to explain this as, as version 1.0.0 of the plugin required WordPress 3.3, version 1.6.0 also required 3.3, and version 2.2.0 required at least 3.5. So it is not as though the websites could be using a much older version of WordPress than 3.7.

When you have people concerned enough about security to install a security plugin, but not update it in years, despite keeping plugins up to date being an import and rather basic security measure, it points to the difficulty that there is in trying to improve the current poor state of security.

Since we are discussing keeping plugins up to date, don’t forget that we offer a plugin that will turn on WordPress’ ability to automatically update plugins, so you can easily keep your plugins up to date.

Questionable Support Advice on Dealing With Hacked Websites From WordPress and Norton Safe Web’s Mystery Blacklisting

One of the things we do to keep track of vulnerabilities in WordPress plugins for our Plugin Vulnerabilities service is to monitor the WordPress support forum for threads related to them. In addition to threads that actual relate to that issue, we frequently run into to other security related threads. In doing that we noticed that in many threads a reply containing the same advice is given, which consisted mainly of a series of links. Some of the pages linked don’t seem to provide the best information, so we wondered if the various members providing that reply were actually aware of what they were linking to or if they were just repeating something they had seen others saying. While looking into another issue involving the forum we found that the source of the message was from a series of pre-defined replies for moderators.

While looking into another thread that came up during that monitoring of the forum we came across evidence that one of the links they include, a link to something called Sucuri SiteCheck, may not be the most appropriate to include. In that thread the original poster had written:

Sucuri is showing my site as harmful and is asking for $16/month to fix it, yet my site seems fine, traffic is normal and I have no log in / access problems on any browser or device.

When we went to look to see why Sucuri was claiming the website was harmful, the SiteCheck page was light on details and high on pushing you to use their service:

Looking at the other two tabs of information, the only issue that they were identifying was that website was blacklisted by “Norton Safe Web”:

It seems to us that a service would be careful in situation where they are not themselves detecting anything malicious, but Sucuri seems to be labeling the website as “Site Potentially Harmful” and “Site Likely Compromised” based only on the fact that Norton Safe Web was blacklisting it. Based on our limited experience with Norton Safe Web, that would seem to not be appropriate because the results we have seen from it in the past have been rather poor.

Looking at what they are claiming to have detected with this website makes us more confident of the position.

Here is what they are reporting as of now:

You can see they are not claiming that there are any “computer threats” or “identity threats”, just an “annoyance factor”. What the “annoyance factor” isn’t really further explained, with the only information being that a page is listed as having a “SWBPL” threat. There is no explanation what a “SWBPL” threat is either on the page or through a link. In searching around to try to find out what that is, we found that we were not alone in trying to figure that and that even some people at Norton did not know what it is. The most detailed information we could find was in a thread on the Norton website, where it was stated that:

SWBPL is one of the threat type in safeweb which is based on telemetry which we collect from 3rd party vendor feeds. Since these sites are classified based on the static data it is pron to few FPs

So Norton is apparently warning about the website based on unidentified third-party’s data, which is also apparently prone to a “few” false positives. That doesn’t really seem like something that should be the source for Norton warning about a website and certainly shouldn’t be used by someone else to make claims as to the security of the website.

Looking at the URL they identified as being a “SWBPL” threat, visiting it normally just returns a “Page not Found” message and when visiting it in some other ways didn’t produce any different result. Without having access to the backend of the website we can’t rule out there is some issue with it, but from the outside there is nothing we could find harmful about it.

We hope that WordPress will review the boiler plate message they provide to those with questions about hacked websites and consider if they are providing the best information in it.

Automattic Helping Security Companies Peddle False Narrative of Brute Force Attacks Against WordPress Admin Passwords

Last week we looked at one example of the poor state of security information surrounding WordPress, security companies falsely claiming that brute force attacks against WordPress admin passwords are happening (and also offering products and services that are supposed to protect against that non-existent threat). That has negative impact on security since you end with a lot focus and concern on something that isn’t actually threat while other issues, like the poor state of WordPress plugin security, which actually leads to websites being hacked, don’t get the focus and concern they should and needs to get.

While security companies being part of the problem isn’t something that really surprises anymore, considering that most of them seem to either know and or care little about security, when other companies that you would expect to be better, are part of the problem, it is surprising to us. That brings us to the company closely connected to WordPress, Automattic, which has among their offerings the plugin Jetpack.

Despite the fact that brute force attacks simply are not happening, protection against them is prominently advertised feature of the Jetpack plugin. As can be seen on the plugin’s page on wordpress.org:

and on the features page on the plugin’s website:

It easy to think the public would be more likely believe that they were happening when they see that.

At the same time the Jetpack website provides further confirmation that brute force attacks are in fact not happening. Going back to our previous post, with a password made up of numbers and letters (upper case and lower case) that is six characters long, there are over 56 billion possible combinations. By comparison according to the website, Jetpack has only blocked over 1 billion attempts:

Jetpack has blocked over one billion malicious log-in attempts aimed at our users’ WordPress websites.

While that might be enough attempts for a brute force attack to succeed if they all occurred on one website, that is a cumulative total across possibly millions of websites and maybe for a period of over a year, so it shows that there are not even close to enough attempts for brute force attacks to be happening.

We hope that Automattic will become more consciousness of the impact they have on the security of WordPress going forward, because it would be a help to us and others that are trying to improve the situation.

WordPress Also Disappeared a Support Forum Post That Just Thanked Us

Recently we have discussed about how someone (or someones) at WordPress is disappearing some of our posts from the their support forum, including an instance where the original poster was left with only bad information from a forum moderator, while our post with the solution to their issue was deleted. Why they are doing that is a mystery, but the end result is that public is left without important information like in that case. While looking over the most recent round of this we noticed that whomever is doing this feels the need to hide what is going on from the public by deleting not just our posts, but in one case deleting a benign response from someone else thanking us, which would have made it obvious that our post was removed if that response remained.

Before we get into the details of the disappeared posts, it worth noting what is supposed to a reason to have a post deleted or edited from the forum:

Generally speaking, posts are only edited or removed where to do otherwise might lead to serious consequences. Previous examples have included posts that accidentally incorporated proprietary code or where the poster asking has reason to fear for their online safety. Having a posted site url come up in Google in NOT a serious consequence. In each case, use your best judgement or ask for a second opinion. If the final decision to to leave the post “as is”, use something like:

When a post is made and people contribute answers to an issue, that then becomes part of the community resource for others to benefit from. Deleting posts removes this added value. Forum topics will only be edited or deleted if they represent a valid legal, security, or safety concern.

Back in April someone posted on the support forum for the JQuery Html5 File Upload plugin, indicating they were seeing bots checking for the existence of the plugin and wondering if their were exploits to be expected in the plugin. Shortly after they we responded, explaining that the likely cause of this was a false report of a vulnerability in the plugin that was released a week before. The original poster then responded thanking us for the information, “@White Fir Design, thank you for your post!”. Earlier this week as part of the latest purge our post was deleted, though as this screenshot of the changes made shows it wasn’t the only thing deleted (the posts with a red background were removed):

You can see that they not only removed our post, but the response to it. The response couldn’t possibly have lead to “serious consequences” if it remained and there is no “valid legal, security, or safety concern” that could have required it to be deleted. So the only explanation left is that whomever deleted our post wanted to cover up the fact that they were doing that from the public, since if the reply remained it would be obvious that another post by has had been removed.

Among the other posts deleted was another reply about a false report of a vulnerability:

What would be a “valid legal, security, or safety concern” that would require that to be deleted?

In another thread a post was removed were we provided a timeline of a hacking campaign and suggested someone to review the log files for their website to determine the source of the hacking:

Again, what would be a “valid legal, security, or safety concern” that would require that to be deleted?

The final situation we will highlight is a little different, in this case they didn’t delete a whole post, instead they just deleted a sentence mentioning that the people running the Plugin Directory have failed to notice that vulnerabilities still existed in plugins and linked to a page that discussed the problem:

It is quite troubling that someone is trying to sweep under the rug a serious and ongoing problem with WordPress’ handling of security issues in plugins, instead of working on making sure that the problem doesn’t happen anymore.

WordPress Disappears Our Response To Post Indicating that Wordfence Premium Failed To Protect Websites From Being Hacked

When it comes to improving the security of WordPress ecosystem one of the things that is desperately needed is better security information. For example, if you were to look at discussions of WordPress security you would likely to believe that there were a lot of attempts to brute force WordPress admin passwords, despite the evidence from the WordPress security companies claiming they are happening showing that those supposed brute force attacks are not happening at all. Unfortunately, one of the parties we have recently found being an impediment to improving security information that is available to the public is WordPress, or more specially, one or more of the people involved in moderating their forums.

Several weeks ago we discussed how someone at WordPress was disappearing some of our posts on the wordpress.org support forum and it has happened again just in the last day. Since one of the threads that had a reply of ours removed, touches on some important security issues that are in need better information, we thought it would be a good idea to discuss it here, especially since someone at WordPress doesn’t want accurate security information related to that to be accessible to people reading their forum for some reason.

One of the things we do to keep track of what plugin vulnerabilities are out there to make sure we provide the best data for our Plugin Vulnerabilities service is to monitor the wordpress.org support forums for threads discusses such issues. In doing that we run into threads discussing an assortment of other security issues, which we sometimes add a response when we can provide some insights based on knowledge of plugin security and hack cleanups of WordPresw website. Yesterday we ran into a thread involving a claim that several websites were hacked due to a third-party library included with WordPress, SWFUpload.

There we several things that stuck out to with this post. One, was that person, who discussing a hack of several of their clients websites, did not appear to have tried to properly determine how the website were hacked, instead they just seem to be guessing that it was caused by SWFUpload:

Now I think I found the hackers method, I believe they used “swfupload”.

Any security scan will not show “swfupload” as a danger because WordPress (foolishly) includes these script files for legacy reasons. Apart from that, the files in folder “swfupload” are not needed for current WordPress installs. These are old files and since they are old they are NO longer updated to stop hackers.

Now that I had 2 client websites hacked and malicious files uploaded, I believe that is the weak spot in WordPress allowing the hacker to gain access.

If that were the source of the hackings there should be evidence of the log files, which their post made no mention of reviewing (despite being a basic part of a hack cleanup). It seems highly unlikely that was the source, since if a hacker were to have discovered a vulnerability that allows hacking websites throughWordPress it is likely they would try to hack as many websites as possible quickly before it was discovered that their was issue since once it was, WordPress could quickly release an automatic update that would protect the vast majority of WordPress websites within a day. Seeing as we haven’t seen any evidence to point to a hack of WordPress itself occurring recently, it seem unlikely that was the source. The first two paragraphs (of total a three) of our response discussed those things:

If there was a known vulnerability that could be exploited like this in the version of SWFUpload included with WordPress it is likely that there would be a lot of websites being hacked through it right now, but we are not seeing any evidence of something like that going on at this point, so it isn’t likely to be the source of your hackings.

What you will want to do is to review the log files for the websites to see what evidence they provide as to the source of the hackings. If SWFUpload was in fact the source then there should be evidence of that in the HTTP log and that evidence would also provide information needed for the WordPress developers to work on fixing it.

The other major thing that stuck out what this person surprise that the website had been hacked while using the Wordfence Premium service:

I had 2 of my client WordPress sites hacked in this past month and they uploaded malicious PHP and JS files to infect the site with a backdoor PHP script. When I found the hacked upload 2 weeks ago in one client’s site, I wondered how did they got into the site while using WordFence Premium?

Should that be surprising? Not to anyone who is actually knowledgable about security, since in reality the various website security products and services out there provide at best limited protection against real threats against websites (and sometimes they actually are the security threat). For example, a WordPress security plugin would have no ability to stop an attacker who gains access to the FTP credentials from accessing the website’s files and in fact if the attacker wanted to they could modify the security plugin to ignore any changes they made to the website.

For Wordfence in particular it wasn’t surprising to us that their service wouldn’t protect a website considering among other thing they are one of the security companies pushing false claims of brute force attacks (while advertising that their service will protect you from them) and that we recently found their claim that their plugin would protect against stored XSS vulnerabilities was not supported when testing real world vulnerabilities against it. When it comes to their paid service, Wordfence Premium, back in June we noted that it was failing to detect vulnerabilities that were being exploited in the current versions of plugins. We concluded our response by mentioning that, since it is relevant for someone thinking that the service would protect them, that said service is oblivious to vulnerabilities that are being exploited and could actual be a cause of the hackings:

Since you brought up Wordfence Premium, it is worth noting that the service looks to have missed detecting exploitation of numerous vulnerabilities that were in the current version of WordPress plugins, so its ability to protect websites against real world threats is at least somewhat limited.

Was someone at WordPress trying to cover up the fact that Wordfence Premium has serious problem in its protection by removing our response, we don’t know, but removing our post had the same effect.