HostGator Is Actively Hiding the True Nature of Their Partnership With SiteLock

When it comes the really bad practices of the web security company SiteLock, they often involve their partnership with various web hosts. Considering that long ago we had seen that SiteLock didn’t seem to very good at handling security, whether it be not properly cleaning up hacked websites or not doing a basic security check before declaring a website secure, we had long assumed that these partnerships were not based on the web hosts believing that SiteLock was the best company to best help their customers, but instead based on the web hosts being paid to push their services. Those payments, it turns out, are happening, but they tell only part of the story of the partnerships with some of the web hosts.

Last month while looking for some other information about SiteLock we can across the fact that the companies majority owners also are the CEO and a board member of the web hosting company Endurance International Group. That companies does business under the brand names A Small Orange, Bluehost, FatCow, HostGator, HostMonster, iPage, IPOWER, and many more.

Through that we also found that in the case of Endurance International Group, not only were they getting paid for the sales of SiteLock services through the partnership, but they were receiving a majority of the fees as of fiscal year 2014.

In the case of both of those facts, they were disclosed to investors, the ownership is disclosed in financials statements and the fee breakdown was disclosed in a prepared remarks for an earning conference call. To the public those things have not been disclosed in the normal course of business. And a recent interaction we had with HostGator support on twitter show that isn’t just that they don’t go out of the way to disclose them, but are actively trying to hide those facts.

The interaction starts with this tweet from HostGator Support to a customer of theirs that doesn’t mention either of those items as reason why they are partnered or “suggest” SiteLock:

Its worth noting that when it comes to cleaning up a hacked websites, you would do things the same way no matter the web host, so working well with their service is explanation that doesn’t make much sense for hack cleanups. It also worth noting, as we did before, that HostGator doesn’t make it easy to properly clean up hacked website since log files are not stored for a sufficient amount of time be default. If this was a real partnership and SiteLock actually properly cleaned up hacked websites, we would expect that issue would have been resolved a long time ago.

We sent a reply to their customer mentioning the CEO connection:

In turn HostGator starts to obfuscate (due to the limits of tweet length our tweet had not had made the distinction that the CEO in question, was of Endurance International Group, but it is clear in the linked post)

We then sent a reply clarifying that and they replied:

At that point we said that we hope they would start to disclose the true nature of their partnership:

Which in turn lead stating they could not confirm that, despite those being facts that their parent company has already confirmed (otherwise we wouldn’t know them):

At this point, they claim they can’t confirm they are getting paid:

It is one thing for them to not mention what is going in the normal course of business, but to actual being unwillingly to tell the truth is pretty telling as to what is going on.

The conversation ended after we pointed out that we were not asking them to confirm anything, just disclose what we both already know to be true:

What To Do If You Get Contacted by HostGator or SiteLock About a Hacked Website

One of the bad practices we have seen from SiteLock is to claim that website are hacked when they are not, so if you get contacted by either of them with claim that the website is hacked you should get a second opinion. We are always happy to provide a free consultation on how to best deal with a hacked website, which includes double checking as to whether the reason the website is believed to be hacked does in fact make sense (often times other issues are confused with actually hacking issues and that can usually easily recognized by someone who deals with hacked website on a regular basis).

Considering how bad of a job SiteLock has been doing with cleaning hacked websites as of just the last month and their bad practices you would probably be best off avoiding them when you are dealing with a hacked website. You also might want to consider moving to a web host that doesn’t partner with SiteLock, as that partnership seems like it is pretty clear warning of how they treat their customers and a lack of concern for security.

Cyber Security Company’s Poor Website Security Reminder of Industry’s Lack of Focus On Actually Improving Security

When it comes to the poor state of website security one of the issues we see is that while too often people are not doing the basics of security, security companies are pushing all sorts of advanced security products that provide little to no value beyond what could be had by doing the basics. Sometimes those things are fairly connected, take for instance the cyber security company Lunarline that claims to have “clients in the intelligence community, DoD and nearly every cabinet agency”. In post on their blog back in July, No Website Is Immune From Cyber Attacks, they stated:

Reducing your risk of critical website attacks requires a multifaceted approach, but you can take the necessary steps regardless of your organization’s size. While you may be running vulnerability scans on your web servers, these scans can only find known issues, and weak points specific to your organization’s systems may go unnoticed. This is where skilled penetration testers come into the picture, using up-to-date real-world hacking methods to see where you could run into problems.

The reality that we see in dealing with hacked websites is the problems would have been prevented with pedestrian measures, say keeping the software up to date. That is something that Lunarline isn’t doing on that same blog:

The Lunaline Blog is Running WordPress Version 4.2.1

It isn’t just that they have kept WordPress up to date, but they are not running the latest version of the outdated version of WordPress, 4.2, they are using, which is 4.2.10 (4.2.2 was released in May of 2015). All the 4.2 releases since then have include security updates.

For those not familiar with WordPress, that indicates something is wrong. Normally WordPress would have automatically applied the 4.2 updates due to WordPress’ automatic background updates, which were introduced in WordPress 3.7. There are two likely possibilities why those updates haven’t happened, the first being that they disabled the automatic updates and then didn’t handle the updates manual or there there is a problem with those updates occurring in their hosting environment and they also never bothered to manual update either. If it was the latter then helping WordPress to resolve that issue would help them, since they can’t seem to manage to the update themselves, and it would help anyone else with the same issue.

This isn’t the first time we have run into a situation like this. We previously discussed the fact that the maker of a WordPress security plugin’s website had an out of date WordPress installation. In that case they later contacted us and let us know that they had disabled the updates since they had modified core WordPress files, which you shouldn’t do. The fact that someone making a WordPress plugin couldn’t properly handle using WordPress built-in capability to modify it instead of modifying core files, makes what we found the next time we ran into them none to surprising. We found that their plugin was using custom for a security check instead of using WordPress built-in function for doing the same and that the custom code had a security vulnerability in it.

The outdated WordPress install on Lunarline’s blog isn’t the only obvious security issue with their website. They are also running an outdated version of WordPress on their School of Cyber Security website as well: The School of Cyber Security Website is Running WordPress Version 4.2.2

Their main website is also running on an outdated version of Drupal:

The Lunaline Website is Running an Outdated Drupal Version (7.0-7.42)

A little further checking show that the Drupal version is 7.36, 7.37, or 7.38, which means they haven’t applied any updates since at least August of last year .

ZDNet’s Zero Day Blog Doesn’t Understand What A Zero-Day Vulnerability Is

Earlier this week we discussed a situation where a couple of articles on tech news websites labeled several vulnerabilities disclosed in a Dell EMC product as being zero-day vulnerabilites despite there being no indication that was the case. A zero-day vulnerability is a vulnerability that is exploited before the developer is aware of the vulnerability. That obviously is serious situation since you have a vulnerability that is being exploited and having kept your software up to date will not protect you against exploitation. As we discussed in more detail in that previous post, security companies and the press often label vulnerabilites that are not zero-day vulnerabilities as being them, which is not helpful in trying to understand the threat landscape. Our best guess was that the claim that these were zero-day vulnerabilites was included in those articles due to a press release from the discoverer of the vulnerabilites referring to them as being zero-day vulnerabilites (without any supporting evidence), as the discoverer’s post on the issue didn’t not make any reference to them being zero-days.

In the previous post we mentioned that one of the articles came from ZDNet, but more specifically it came from their blog Zero Day. It would be a pretty telling example of how bad security journalism is if they didn’t even understand what the namesake of their blog actually means. But making that assumption on one wrong article would be unfair, so we started taking a look to see if this had happened before and it clearly wasn’t a one time fluke.

We just had to go back to the 3rd to find another example, this time OpenJPEG zero-day flaw leads to remote code execution. The last two paragraphs make it clear this wasn’t a zero-day vulnerability:

The vulnerability was discovered by Aleksander Nikolic from the Cisco Talos security team in OpenJpeg openjp2 version 2.1.1.

Cisco Talos disclosed the vulnerability to affected vendors on 26 July, granting them time to prepare patches to fix the problem before public release.

So the vulnerability was discovered by a researcher, reported to the developers, and fixed before public release. There is no indication in the article or advisory that it has ever been exploited.

The discover also breaks down their vulnerability reports as Zeroday Reports and Disclosed Vulnerability Reports and you can see that this issue is listed as being the latter:

talos-vulnerability-reports-screenshot

Heading back a few weeks we found the article Zero-day vulnerability found within MySQL database application. In this case the vulnerability was reported to the developer before it was disclosed:

On Monday, independent security researcher Dawid Golunski released his findings through a public security disclosure, stating that over 40 days have passed since the zero-day vulnerability was reported to the vendor.

Nothing in the article or the linked public security disclosure provides any indication it was being exploited before the developer was notified, so it is not a zero-day.

Would You Be Surprised to Hear That SiteLock’s Idea of Independent Testing Doesn’t Involve Actual Independence?

Recently for several different reasons we have taken a look at claims made about quite a few web security services and products and noticed that there are often bold claims that seem highly unlikely to be true. There also is a decided lack of evidence put forward to back those claims, much less independent third-party evidence to back them. So we were surprised today to see a press release from the web security company SiteLock, Independent Testing Shows SiteLock Web-Based Malware Protection Outperforms Traditional Endpoint Solutions. Considering their track record, we wouldn’t have expected them to be the ones actually having independent testing done. After taking a quick look over the details of the testing, we found that, not surprisingly, the testing was actually the opposite of independent.

The test compared their ability to detect malicious code on websites against McAfee Complete Endpoint Protection ability to do that. It appears the testing was intended to show that products of the type that McAfee have are not well suited to doing this, but since there is not a comparison of multiple products in each category, the value that could be gleamed from the test is limited.

One finding of the test did stick out to us though:

SiteLock SMART provided 100 percent PHP and JavaScript coverage versus less than 6 percent coverage by McAfee

Considering the poor quality we have seen with SiteLock’s detection in the past, whether it be missing malicious code or falsely identifying non-malicious code as malicious, we had a hard time believing that that they would possibly detect 100 percent of the tested malicious code in a reasonable test.

A key question to determine the quality of the testing was how the malicious code being used in the test was picked. When the items tested are mentioned in the press release there source isn’t mentioned either time, here:

Testing a group of nearly 3,000 web-based malware examples to determine effectiveness

and here:

Tests showed that the SiteLock solution detected and cleaned 100 percent of the samples provided.

Looking at the complete report (PDF) by the Tolly Group, there is the answer:

The test corpus was provided by SiteLock and consisted of 2,972 samples that included PHP, JavaScript and other executables that contained a variety of attacks.

So SiteLock provided the items that would be tested against. The test clearly isn’t independent at that point and the real story would have been if SiteLock didn’t detect them all.

The complete report also makes no claim to the testing being independent.

While SiteLock knew ahead of time what would be tested, since they provided the items being tested, the company behind the other product was not allowed to see them:

In accordance with Tolly’s Fair Testing Charter, Tolly personnel invited representatives from McAfee/Intel to participate in the testing. Because of internal guidelines, McAfee/Intel was unable to review the test corpus in detail and had no further comment.

Based on that you wonder what else might be in their internal guidelines that could skew the test results.

Press Release Journalism Unsurprisingly Leads To Bad Security Journalism

When it comes to the poor of state of cyber security, we think one of the important elements that has gotten us to the current situation is the poor state of security journalism. Instead of shining a light on the many bad practices of the security industry, journalist are too often repeat the claims of security companies without doing any due diligence as to their accuracy. From what we have seen with web security companies that is a bad idea, since you not only have companies that will blatantly lie to the public, but you also have a lot of companies who don’t seem to understand the basics of security.

One company that doesn’t seem to understand the basics of security is Wordfence, which a couple weeks ago we found doesn’t understand what a zero-day vulnerability is, leading them to be claiming to have exclusive knowledge of ones, when the vulnerability they were aware of are not in fact zero-day vulnerabilities at all.

Based on how often we see security products and services promoted as protecting against zero-day vulnerabilites or attacks, at least the marketing departments of security companies think that their customers are fairly interested in protection against them.

A zero-day vulnerability refers to a vulnerability that is being exploited before the developer has become aware of the vulnerability. To be able to protect against those when they start getting exploited requires you to be able to protect against any kind of vulnerability, since any type of vulnerability could be a zero-day vulnerability. That would be difficult to pull off, to put it mildly.

As we have found detecting those vulnerabilites in WordPress plugins for our Plugin Vulnerabilities service, quickly detecting them once they are being exploited isn’t necessarily difficult, but it hasn’t been something other companies dealing with WordPress security have not been doing (as can be seen in the fact we have found numerous of those that look to have been in the wild for some time with out other security companies doing anything about them).

What is far easier then actually protecting against or quickly detecting zero-day vulnerabilites is to simply label any vulnerability you have found as a zero-day vulnerability. That is what Wordfence has done, in their cases it doesn’t seem intentional, just their lack of security knowledge once again at work.

The distinction between an actual zero-day vulnerability and any vulnerability that a security company happens to discover is quite important. First, many (maybe most) vulnerabilities are unlikely to be exploited, whereas by definition, a zero-day vulnerability is one that hackers are likely to be exploited, considering they already have been exploiting it. Protecting against a vulnerability that isn’t likely to be exploited is of a lot less value than one that is likely to be exploited. Second, if the security company doesn’t disclose the vulnerability as soon as they discover it and notifies the software’s developer, then they have a chance to fix it before it would be exploited, but again by definition, a zero-day vulnerability is being exploited before they have had a chance to do that. If a fix has been released before the security company discloses it, then those keeping the software up to date will protected if there are an exploit attempts after it is disclosed, while that won’t be the case when a zero-day vulnerability at least when it is first being exploited.

That all brings us to today, where there was an example of bad journalism leading to unfounded claims of zero-day vulnerabilities. Over at Ars Technia an article titled “Security company finds five “zero-day” flaws in EMC management console” was put out. If you read the article there isn’t anything that backs up that these are zero-day vulnerabilites, just that vulnerabilites that were discovered. In looking at the post on the discoverer’s website that is cited in the article, there is no mention of zero-days at all, instead what they state is this:

The Digital Defense, Inc. Vulnerability Research Team (VRT) has identified six previously undisclosed security vulnerabilities found in the Dell EMC VMAX Management Product family.

Ars Technica was not the only news outlet claiming they were zero-day vulnerabilites, ZDNet has an article titled “Multiple zero-day flaws found in EMC storage systems“, which again doesn’t include anything that backs up that these are zero-day vulnerabilites.

So where did the idea that these were zero-day vulnerabilites come from?

The answer seems to be the press release the discoverer put out, entitled “Digital Defense, Inc. Discovers Multiple Zero-Day Vulnerabilities within EMC Unisphere for VMAX“. While zero-day vulnerabilites are mentioned in that, there isn’t any indication in that the vulnerabilites are being exploited or were being exploited before the developer knew of them, which would be required to make them zero-day vulnerabilites and not just vulnerabilites that this security company had discovered.

It really should go without saying that doing journalism based on a company’s press release, which makes a claim that isn’t included in their related post about the issue, isn’t a great idea if you care about getting things right.

So SiteLock Is Now Apparently Blaming Their Web Hosting Partners For Their Bad Practices

One of things that we had wondered for some time about SiteLock, the web security company that seems like is scamming their customers, was what explained their partnerships with so many web hosts. Before we found about the more scam level stuff going on with them, what we had see was they seemed to be quite bad at hack cleanups and the basics of website security. So we figured that the partnerships were not based on the web host believing that SiteLock was the best choice to help their customers, but about money. When we found about how SiteLock was taking advantage of people on large scale we started to wonder how much money must the web hosts being getting to continue those partnerships, considering that their partnerships with SiteLock couldn’t be good for their reputation. To a lesser degree we sometimes have had wondered why SiteLock was partnering with some web hosting companies that had some bad security practices or were making it harder to properly clean up hacked websites. We figured that they would at least be pushing these companies to improve those situations, but we saw no evidence of that occurring.

Several weeks back we ran across a couple of things that went a long way to answering those questions.

First, it turns out the majority owners of SiteLock are also the CEO and board member of a major web hosting company Endurance International Group, which does business under the brand names A Small Orange, Bluehost, FatCow, HostGator, HostMonster, iPage, IPOWER, and many more. That would seem to make it easier to get them to partner with SiteLock. From this we also know that at least at those web hosts, the web hosts are not in the dark about what SiteLock is actually doing and if they had a problem with it they could make a change directly at SiteLock. It also goes a long way to explaining why SiteLock wasn’t insisting on better security practices at web hosts, since their owners are also running a web hosting company that doesn’t have the best handle on security.

It important to note that neither SiteLock or the Endurance International Group is upfront about this connection between the two. The only place you will find out about the connection is in Endurance International Group financial reports, where they are legally required to disclose it. Even in those it hidden away, as SiteLock is not mentioned in them, instead they are referred to by the entity that owns them, Innovative Business Services. At the point where you legal are required to disclose something, it seems to us that would be a good indication that you should be upfront with your customers about what is going on, but clearly they don’t fell the same way.

Second, it turns out that web hosting partners are getting a lot of money, if the deal that SiteLock has with Endurance International Group is any indication. As of fiscal year 2014 the Endurance got 55% of the revenue coming from sales through the partnership with SiteLock. We wonder how people that have been strongly pushed to SiteLock by their web hosts would feel when they found how much money the web host is getting by doing that, especially in situation where they are dealing with a hacked websites. It also appears to create an incentive for them to not make sure their clients are secure, since they can make a lot of money off of those websites being hacked.

That brings up to the latest piece of information we ran across about their partnerships, which is that SiteLock is apparently blaming their web hosting partners for how the services are sold. Here is a tweet from one of the writers at WP Tavern:

Assuming that is true and we don’t have a reason to believe that it isn’t (the same person did a podcast interview with a SiteLock representative in June, in which their response to a question of SiteLock’s unsavory practices was that you should trust that person that it isn’t happening (despite it actually happening)), it is a rather outlandish claim. Even if you didn’t know what we just discussed, what kind of partnership would it be where one party has no control of how their services are being sold.

In reality from everything we have read and heard, SiteLock employees are the ones doing much of what is being complained about. Even if they were not, considering how much the web host is getting paid, it doesn’t seem believable that Sitelock wouldn’t have the leverage to stop bad practices.

More importantly in the case of Bluehost, that was mentioned in the previous tweet there, seeing as SiteLock’s owner also control Bluehost, they wouldn’t’ have a problem controlling how the web host sells SiteLock’s services.

We get the feeling that the idea here is that SiteLock and the web hosts each point the figure at the other and hope that more people don’t become aware that they are dealing with two parties so closely connected.

Sucuri Doesn’t Have A Clue What Brute Forcing Actually Refers To

One of the problems we see when it comes to people making better choices on web security is that it easy for security companies that don’t have a clue what they are talking about to present themselves as having expertise they don’t have. For example, they can throw around technical terms that they clearly don’t understand, but that the public understandably doesn’t understand either, and it makes them sound like they actually know about security, when they don’t.

One example we keep seeing involves the term brute force attack, which refers to trying all possible password combination in attempt to login in to an account. It isn’t some obscure or exotic term, it has a Wikipedia page, but that doesn’t stop people from using it when actually referring to other types of password attacks.

Often times dictionary attacks, which involve trying to log in with a set of common passwords (things like “password”), are incorrectly identified as having been brute force attacks. The distinction isn’t just semantics, how you protect against those types of attacks is very different, so anybody dealing with web security that involves either of those, absolutely should know the difference. And again the term has a Wikipedia page, so it wouldn’t be hard to know what it is.

That brings us to the security company, Sucuri, which we have seen being quite a bad security company in many ways over the years. That clearly hasn’t changed. In a recent post describe how they did an experiment that was supposed to test how long it would take for successful brute force attacks of SSH logins:

A few weeks ago we ran an experiment to see how long it would take for some IPv4-only and IPv6-only servers to be compromised via SSH brute force attacks.

As they explain in the second paragraph of the post, their experiment involved them setting the password to “password”:

We configured five cloud servers on Linode and Digital Ocean with the root password set to “password.”  The idea was to see how long it would take before the servers were hacked.

To anyone who actually know what brute force attacks and dictionary attacks are, its obvious that they don’t actually know what they are talking about since that would be a password to test for dictionary attacks, not brute force attacks, but the public is unlikely to, especially as security companies keep referring to dictionary attacks as having been brute force attacks.

If you are interested in actual security, Sucuri’s lack of basic security knowledge, would be a good reason to look elsewhere.

Where Are The Vulnerabilities That SiteLock’s Vulnerability Scanning Should Have Found?

In looking over things for a possible future post about the web security company SiteLock we have noticed that one of the features prominently promoted by its hosting “partners” when selling SiteLock’s services is vulnerability scanning. For example, at HostGator, one of their hosting “partners” that is also run by the owners of SiteLock, vulnerabilities scans of varying frequency are included in each package:

hostgator-sitelock-packages

It also promoted on their page for the services as helping to prevent hacks:

Make WordPress More Secure Great news for WordPress users! SiteLock's firewall and vulnerability scans help prevent hacks and automated attacks on this ever-more popular publishing platform.

What is missing on the “partners'” websites or SiteLock’s as far as we can tell is any evidence on the claimed effectiveness of their vulnerability scanning. Vulnerability scanning of the type that it appears SiteLock does, doesn’t have a reputation for being of much value. In a study (PDF) from 2014 that looked at vulnerability scanners tied to security seals (SiteLock has one of those and its accuracy has been poor from what we have seen), it was found that two of the 8 vulnerability scanners tested detected none of the vulnerabilities that existed on a website set up with a number of vulnerabilities, which was due to those scanners using third party software that “are not meant to discover vulnerabilities in web applications”. Five of the six remaining scanners only discovered a third or less of the vulnerabilities that existed.

If their vulnerability scanner was in fact detecting vulnerabilities we would expect to have seen evidence of it elsewhere. SiteLock claims that as of 2015 they were “serving over 1 million WordPress customers”. If there vulnerability scanning was actual effective we would expect that would have found quite a few vulnerabilities in plugins based on the number of vulnerabilities we see being discovered in WordPress plugins while collecting data for our Plugin Vulnerabilities service. But we are only aware of two vulnerabilities that they have discovered in recent times and both of those don’t appear to have been discovered during the running of their vulnerabilities scanner. By comparison over at the blog for our Plugin Vulnerabilities service we have over 90 posts for vulnerabilities we have discovered this year (some of the post include multiple vulnerabilities, so the total number of vulnerabilities is even higher). If their vulnerabilities scanner was discovering other vulnerabilities in plugins on website, even if SiteLock were not aware of it, we would expect to see some mentions of that in changelogs of the impacted plugins or discussions of the vulnerabilities and yet what we haven’t seen any reference to their scanning having identified any vulnerabilities and the vast majority of vulnerability disclosures and fixes we have reviewed can be traced back to a source that wasn’t their scanner.

Whether you are looking at SiteLock or another provider of security services and products you should look for evidence from the provider that products can perform as claimed, as we often see claims made that seem rather unbelievable and from some of the claims we have taken a look into they often turn out to be at least widely inaccurate.

Joomla Firewalls Are Not a Replacement For Properly Cleaning Up a Hacked Website

When it comes to the security of websites what we often see is that a lot of focus is add-on security products instead of focusing on doing the basics. The reality is doing the basics is going to do a lot more to protect you than any security products. As an example, over at our Plugin Vulnerabilities service we recently tested 11 WordPress security plugin against a very exploitable vulnerability in a plugin and found that only 2 of the plugins provided any protection and for those two we easily found a way to bypass them. By comparison, simply updating the plugin after the vulnerability was fixed would protect you from the vulnerability.

This type of wisdom recently came up in the context of a hacked Joomla website we brought in to clean up. We were originally contacted by someone involved with the website about the following warning they were receiving on the website from Chrome warning that “The site ahead contains malware”:

This site ahead contains malware

The warning referred to another website, so they were not sure if it was due to their website being hacked or if maybe the other website was hosted on the same server and being on the same server was causing the warning. The reason the warning mentioned another website was that it was a cross-site warning, which is shown when content is loaded from another website that is being flagged by Google for malware. In this case it was caused by the following malicious JavaScript code that was being included on the website’s pages:

malicious-javascript-code

We explained them what was going on (if you have a question related to a possible hacked website we are always available for free consultation to discuss it) and then we were brought in to clean up the website.

The JavaScript code shown before was easy to find because it stored in the index.php of the various templates on the website, without any obfuscation.

One of the next steps in the cleanup was determining how the code got on the website. While determining how a website is hacked is one of three important pieces of a proper hack cleanup, many, maybe most, companies doing hack cleanups don’t do this. Not to surprisingly the website where that doesn’t happen often get hacked again, and we are often brought in at that point to re-clean it.

What looked to be the cause of the malicious JavaScript code being added to the template files was a POST request to the file /libraries/fof/integration/joomla/general24.php. While that directory is one for core Joomla files, that file isn’t. Instead it was file a hacker had placed on the website at some point before, based on the last modified date it would appear it was placed there three months before. The logging doesn’t go back that far so we were unable to see how that file had been added to the website.

That was not the only malicious file on the website. One of the easiest to spot was one in the root directory of the installation, due to the filename, ee79bb.php, not being something you would expect to see there. There were also several malicious files that had been renamed so that could be executed. At that point we found out that website had been hacked before, but it not been cleaned in a professional manner before.

Firewall Extensions Didn’t Stop The Hacking

While the website had not been fully cleaned before, two firewalls had been added, RSFirewall! and the firewall that is part of Admin Tools. Neither of those protected against the request sent to the general24.php file or based on their logging look to have had any impact as a number of other malicious look to have been added on the website over a period of months. That isn’t necessarily their fault, as once a hacker has some access it is much harder to detect that the requests are malicious in nature, but it is a reminder that security add-ons are not a replacement for proper security practices.

It is worth noting that with both RSFirewall! and the firewall that is part of Admin Tools, bold claims are made to their security capability with being backed up by and evidence. For RSFirewall! is describe thusly:

RSFirewall! is the most advanced Joomla! security service that you can use to protect your Joomla! website from intrusions and hacker attacks. RSFirewall! is backed up by a team of experts that are trained to be always up to date with the latest known vulnerabilities and security updates.

Nowhere is there anything that actually backs up those claims. Also troubling is the fact that it boasts protection against brute force attacks, despite those not actually happening.

Admin Tools firewall is describe in somewhat less bold way:

Our Web Application Firewall protects your site against the vast majority of common attacks. You won’t find any security tool more feature-complete than this.

But again, nowhere is there anything that actually backs up those claims.

SiteLock Promoted Services To WordPress.com Users That Are Not Relevant to Them

In a recent post about how WordPress is giving the web security SiteLock unwarranted legitimacy by allowing them to be involved in WordCamps, conferences dedicated to WordPress, we mentioned that one of the reasons it didn’t seem great to have them was that they are falsely labeling WordPress website as having vulnerabilities due to their lack of understanding of how WordPress handles security updates. It turns out their lack of knowledge of WordPress extends further, leading to trying to sell people services that are not relevant to them, as we found while looking for information for another post.

In a March post entitled This Week in Exploits: Increased WordPress.com Security on SiteLock’s WordPress focused The District blog, SiteLock mentioned that WordPress.com had enabled HTTPS for those using custom domain names. For those not familiar, WordPress.com is a blog hosting service powered by the WordPress software. It has some rather notable differences with self hosted WordPress installations, some of which we will note in a bit. It seems that SiteLock is not familiar with the differences the WordPress.com service and the WordPress software, but that didn’t get in the way of them trying to use the blog post to sell people on unneeded services.

After a paragraph mentioning the HTTPS change, they pivot to selling their service:

If you’re a WordPress.com user, one way to take advantage of WordPress.com’s exemplary efforts is to go further and enhance the security of your WP.com site with protection services.

First they promote a web application firewall:

The first and probably most fundamental upgrade to your site’s security is to implement a web application firewall, or WAF. With a simple DNS change and SSL cert approval, SiteLock TrueShield WAF protects sites, WordPress.com or otherwise, from malicious traffic, suspicious bots, scrapers and spam comments. The PCI-compliant TrueShield WAF supports SSL and Extended Validation SSL. Service packages depend upon protection capabilities desired.

Considering how the WordPress.com service works it isn’t clear what value that would provide. Much of that would likely already be being done WordPress.com and if there was some vulnerability discovered it should impact the whole service, so you would expect that it would be quickly fixed across the service. The marketing materials for that also don’t present any evidence as to the efficacy of its protection provided by that in general, much less when used with WordPress.com.

Next SiteLock is promoting malware scanning:

The next upgrade to WordPress.com security is a malware scan. The SiteLock Malware Scan crawls websites looking for malicious code and links and immediately alerts the site owner if any are found. The Malware Scan runs daily to find malware early and keeps sites off of blacklists, and results can be viewed in the SiteLock Dashboard or downloaded as CSV for analysis and remediation.

This doesn’t seem to be to useful for the WordPress.com service since you can not use JavaScript code on it:

Users are not allowed to post JavaScript on WordPress.com blogs. JavaScript can be used for malicious purposes. As an example, JavaScript has taken sites such as MySpace.com and LiveJournal offline in the past. The security of all WordPress.com blogs is a top priority for us, and until we can guarantee scripting languages will not be harmful, they will not be permitted.

JavaScript from trusted partners, such as YouTube and Google Video, is converted into a WordPress shortcode when a post is saved.

Since malware on a website is usually JavaScript based (or in some other format not permitted by WordPress.com) there couldn’t be malware on WordPress.com blog and you also couldn’t have your website flagged for malware since, again, there couldn’t malware on these websites in the normal course of things.

Next up they try create a connection between spam and the “dreaded ‘reported attack site’ screen”:

Speaking of blacklists, the final security upgrade is a spam scan. The SiteLock Spam Scan monitors all industry-leading search engine and spam blacklists for the customer’s domain and, again, immediately alerts the customer to any adverse reports. This allows the quickest way to remediation if the worst happens, reducing, if not eliminating, customer interaction with the dreaded ‘reported attack site’ screen.

The Reported Attack Site screen refers to something that has been shown on the Firefox web browser when Google has detected malware on a website, not spam, which is something SiteLock should know. From this description isn’t clear what spam they are scanning for, since it could refer to spam emails or spam content on a website. In looking around for more information on what the Spam Scan actually does, it looks like it actually checks lists of email address claimed to be sending spam, so it isn’t clear what the search engine reference in this refers to. Unless you use your own domain with WordPress.com and send email through it (which wouldn’t be through WordPress.com) this wouldn’t be relevant.

Finally SiteLock brings up their plugin for WordPress:

Security is vital. Easy security management is a must. SiteLock Security Plugin for WordPressprovides complete website security management and allows users to access their SiteLock Dashboard from within WordPress. Highlights include real-time updates ensuring minimal latency between identifying and correcting issues, identifying specific vulnerabilities in order to remediate them as quickly as possible and managing SiteLock Trust Seal settings.

That will not work on WordPress.com blogs, since you can’t install plugins on them.