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, as we recently noticed with Wordfence.

When we discussing 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 linked page, 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 plugins has 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 has disclosed vulnerability (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.

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.