Category: Bad Security

SiteLock Causes Easily Fixable Hacked Websites to be Abandoned Unnecessarily

In our interacting with lots of people looking for advice after being contacted by the web security company SiteLock, one of the problems we have now seen happen repeatedly is that in SiteLock’s quest to squeeze as much money out of people as possible, they are causing people to abandon hacked websites that could quickly and easily be fixed. This causes time and or money to be unnecessarily spent on a creating a new website, and for businesses that are generating business through their websites, unnecessary financial losses.

The business practice that leads up to this is summed up with part of a recent comment from someone that did abandon their website, as to what SiteLock told them about getting the existing website cleaned up:

if I gave them a hundred bucks a month there will clean it up and make sure it stays clean or a one time fee of 300 dollars but, not responsible if within 2 days it’s hacked again

The reality here is that if a proper one-time cleanup is done the website won’t be hacked again in 2 days. Of course, if SiteLock can get someone to believe otherwise they have a better chance of them purchasing an ongoing plan that would get them $1200 a year versus them only getting $300 from the person. The flipside of this is that it also causes people to abandon websites believing they are going to have to pay all that money to keep the existing website secure and that it makes more sense to just start over (which might not actually resolve the issue).

The other important thing to note about this is that while a website cleaned with proper one-time hack cleanup won’t get hacked again in 2 days, SiteLock doesn’t do proper cleanups for that $300. They skip two key components, which are getting the website secure as possible (mainly by getting the software up to date) and trying to determine how the website was hacked and resolving that. Their $100 a month plans don’t provide those things either as far as we are aware. By comparison for most cleanups we do we charge less than $300 for the cleanup (and we only do proper cleanups) and with other providers you can get a low quality cleanup like SiteLock provides for much less than $300.

As we noted before, SiteLock is actually aware that websites can get hacked again if those two parts of a proper cleanup are not done, but that hasn’t lead them to doing them.

What makes this even worse is that many web hosts and other entities like WordPress help to promote SiteLock, which leads to more websites being abandoned unnecessarily (as well as causing many other problems people face if they get involved with SiteLock).

The Reality Behind Praise for a Hack Cleanup Done by SiteLock

In dealing with hacked websites, we are often brought in to redo hack cleanups after another company has done a cleanup and the website gets hacked again. That isn’t necessarily the fault of the company doing the cleanup, but what we have found is that with those websites the company doing the previously cleanup almost always has unintentionally or intentionally cut corners.

The first thing we ask when it is brought up that there was a previous cleanup is if it was determined how the website was hacked. The answer is almost universally that determining how the website was hacked never even came up. Not only is doing that one of the three basic components of a proper cleanup, but if that isn’t done then you have no way of knowing if the vulnerability that allowed the website to be hacked still exists or not and therefore if the website is still vulnerable.

Even after finding out the company that did the previous cleanup didn’t do things right and having to hire us to re-clean the website we have had people say that the previous company did a good job. It is based on things like that, which leads us to believe that positive comments about companies providing security services are often not all that reliable.

A recent example of that type of issue involves frequent topic of this blog, SiteLock. Here was recent tweet from one of their customers:

It sounds like they did a good job, right?

SiteLock then thanked them:

When we first went to look at the website to see if it looked like it been properly cleaned and secured after seeing these tweets, the website was down due to the web host having restricted access to it (a web host that is run by the owners of SiteLock). As of now this is what you get when visiting it:

You don’t have to be a security expert to see that the hack hasn’t been resolved. Beyond what you can see there, which is “hacked by” message and an otherwise empty website, the website is still running an outdated version of WordPress, 4.5.9.

Based on our experience dealing with people who have been customers of SiteLock this poor result isn’t some outlier from an otherwise high quality provider of hack cleanups.

Sample Data Included with Joomla Templates from Template Monster Lead to Website Being Hacked

When it comes to cleaning up hacked websites one of the three basic pieces of doing a proper cleanup is trying to determine how the website was hacked. Without doing that you leave open the possibility that the vulnerability still exists and can be exploited again. Not surprisingly then when people come to us re-clean a hacked website after another company has done that and the website got hacked again there has almost never was an attempt to determine how the website was hacked during the previous cleanup.

Another reason for trying to determine how the website was hacked is so that you can possibly prevent other websites from being hacked through the same vulnerability. We say possibly, because as a hack we recently traced back to a template from Template Monster, trying to work with the party responsible for the vulnerability may not get you anywhere.

Before we get to the vulnerability let’s do a quick walk through how we came to find out it had been exploited.

We were recently brought in to clean up hacked Joomla website where the person already dealing with it was removing malicious code from .htaccess files and the index.php files of the installed template, but it kept returning. In situation like that our first step is to review any available log files to see what they show about how the hacker is making the changes. In this case we found suspect requests being sent to a file in the /modules/ directory.

That file was highly obfuscated and due to that, it was fairly obvious that it was malicious without needing to deobfuscate it. What was more important at the moment was figuring out how it got on the website. In looking over the other files in the directory it was pretty clear that the whole directory it was in was not legitimate and had been created by installing an intentionally malicious extension. One of the items that pointed to that was the manifest file for the extension:

<?xml version="1.0" encoding="utf-8"?><install version="1.5" type="module"><?xml version="1.0" encoding="utf-8"?><install version="1.5" type="module">
 <name>System</name>
 <author>Joomla</author>
 <creationDate>08 Jan 2010</creationDate>
 <copyright>Copyright (C)  Profexor Liberty</copyright>
 <license>http://www.gnu.org/copyleft/gpl.html GNU/GPL</license>
 <authorEmail>profexor@hell.com</authorEmail>
 <authorUrl>http://profexor.hell/</authorUrl>
 <version>1.0.0</version>
 <description>ͮ崫��殨��鲯ﲲ橼/description>
 <files>
 <filename module="mod-favicon-image">mod-favicon-image.php</filename>
        <filename module="mod-favicon-image">mod-favicon-image.xml</filename>
 </files>
    <params description="this module has no parameteres" >
    </params>
</install>

The installation of a malicious extension would most likely be done through a hacker’s access to a Joomla admin account. So we then reviewed the database table that stores user accounts and found there were numerous accounts that didn’t look legitimate. Only one of those was recorded as having been used to log in to the website recently.

For that account the email address was “demo@demoolink.org”. We then did a Google search on that address and found a thread on the Joomla Forum where someone had a template that was trying to create exactly the same user using a SQL statement. By exactly the same, the registration time specified for both was exactly the same, down to the second.

What didn’t make much sense to us is why a template would be trying to create a user. Considering that the template in use on the website we were cleaning was a commercial template from Template Monster, we first thought the explanation might be that it had been obtained from a warez website and the template was modified to allow website installing it to be exploited.

When we reviewed the installer file for the template though we found that there was no code to create the user. At that point we thought we had hit a dead end, but after doing some more investigating we found more evidence to connect the account to the template. After that we got access to another file that had come from Template Monster. This file was named fullpackage.zip and in addition to the template, it included a copy of Joomla and a sample data file created by Template Monster. When installing Joomla you have the option to install various sample data files, so when using this file to set up Joomla you could install the sample data provided by Template Monster

In that sample data file was the following SQL statement that created the user:

INSERT INTO `#__users` (`id`, `name`, `username`, `email`, `password`, `block`, `sendEmail`, `registerDate`, `lastvisitDate`, `activation`, `params`, `lastResetTime`, `resetCount`) VALUES
(846, 'Demo User', 'demo', 'demo@demoolink.org', 'ad358a48fb2891854aa8b547c7b151be:jGftU2FbdRXUNikAQrKKeAQl9Is104QE', 0, 0, '2012-10-17 10:56:12', '0000-00-00 00:00:00', '', '{"admin_style":"","admin_language":"","language":"","editor":"none","helpsite":"","timezone":""}', '0000-00-00 00:00:00', 0);

INSERT INTO `#__user_usergroup_map` (`user_id`, `group_id`) VALUES
(846, 8);

Any website that installed that sample data would have a Super User (the highest level user in Joomla) with the same username/password combo. Unless one of those was changed then someone that could figure out the password could log in to the websites where this sample data has been installed. At that point it looked to us that the user might have been installed across multiple Template Monster templates.

At that point we also contacted Template Monster informed them of the issue and suggested that they notify anyone that had purchased the impacted templates about the potential issue. We also suggested that they register the domain name demoolink.org seeing as that isn’t registered and someone could register and use it to gain access to the impacted website without even knowing the password (by resetting the password).

The first response we received was as follows:

Thank you for reaching the Technical Department of Template-Help.com!

Take our apologies for the delayed reply.

We are sorry for inconvenience caused by this. Usually clients change demo email address. We are happy that you managed to resolve it yourself.

Let us know if you are having any other issues with the template.

We responded trying to explain the issue wasn’t just related to the email address and we received the following response:

Take our apologies for the delayed reply.

demo@demoolink.org is added in admin panel as example of demo link, you can easily change it. Please specify with some screenshot what issue exactly you are having so we will be able to check it for you.

At this point we asked if there was a security department we would be transferred to we received the following response:

We appreciate the information you’ve provided. We will forward it to our development department. They will check it more carefully.

Thank you. Have a nice weekend.

While we waited for another response (none has come in two weeks) we wondered if the password might be something really easy to guess. It turned out that we didn’t need to guess it, as we entered the password hash, “ad358a48fb2891854aa8b547c7b151be:jGftU2FbdRXUNikAQrKKeAQl9Is104QE” in to Google and on got this page as one of the results. From that we then knew that the password was “demo123”. Not only is that not strong password, but with that in hand we found a page on the Template Monster website that told everyone what the username and password was for website using this sample data:

Right below that is a message that indicates that they were aware of there being a risk from providing this user account:

You can delete sample user though the Joomla administration panel in the “Users > Users Manager”. In case you are planning to use sample data we recommend you to change Sample Author user login and password.

We still don’t understand what the purpose of creating a sample Super User like this, since another one is created when installing Joomla.

Kaspersky Lab’s News Website Threatpost Spreads Unfounded Claims About Security Threats

The Russian security company Kaspersky Lab has been in the news a lot recently in regards to questions about its relationship with the Russian government, but what deserves to get some focus is how their news website, Threatpost, helps to spreads unfounded claims about security threats coming from others in the security industry.

Back in November over at the blog for our Plugin Vulnerabilities service we looked at a situation where the Threatpost had covered a claim by the security company Checkmarx that they had found “severe” vulnerabilities in several WordPress eCommerce plugins. At the time Checkmarx presented no evidence to back the claim up and stated that it would be “available in the future”. What they did present indicated that the vulnerabilities, if they existed, might be less than severe. In May we went to look to see if any additional information had ever been released, but we couldn’t find any update and we received no response from Checkmarx when we contacted them asking were we could find it.

Today we ran in to another example of the Threatpost spreading an unfounded claim about a security threat. This time it was with a threat resolving around placing the files for WordPress on a website and then not running the installer. The following line in the article stood out:

WordPress experts claim the attack method isn’t exactly new, but that it clearly hasn’t limited its effectiveness.

The article and the cited source for the article do not provide any measure of effectiveness of the attack. The only cited figure is rather underwhelming argument for even covering this, “biggest increase in scans – roughly 7,500 a day”. Considering that there are apparently at least 100s of millions of websites currently, that isn’t a significant number (it does look like attacks occur a lot more than though, but not more than many other threats that don’t receive any coverage).

We left the following comment on the post pointing to the lack of backing for the claim as to effectiveness of attack:

Your article implies the attack is effective, “WordPress experts claim the attack method isn’t exactly new, but that it clearly hasn’t limited its effectiveness.”, but you and Wordfence don’t present any evidence as to the effectiveness of these attacks. We have seen hackers do large scale attacks that had no chance of being successful because they didn’t understand what they trying to exploit, so 7,500 attempts in a day isn’t in any way an indication that this is effective.

Originally it was held for moderation:

But shortly after that it was removed. So they were clearly aware of the issue, but instead of addressing it they would rather not let people know that they are making unfounded claims.

It also worth noting that first part of the sentence “WordPress experts claim the attack method isn’t exactly new” isn’t all that accurate. It isn’t just a claim that the attack method isn’t new, it actually is factually true that it isn’t new. For example, the issue was brought up five and half years ago and we discussed it at the time.

DreamHost Also Distributing Outdated Web Software Through One-Click Installer

When it comes to improving the poor state of the security of websites, web hosts certainly could be doing things over and above what is their responsibility to help with that. But at this point we are finding that they are still failing to do some things that really are their responsibility. One of those being not offering to install software on websites that is outdated and insecure. In May we discussed an instance were a web host told the owner of a hacked website that the outdated version of Joomla they were using, 2.5.28, was a security weakness while still offering to install that through the MOJO Markeplace service. Support for that version of Joomla had ended almost two and half years before, so it should have long been removed from such a service. Earlier this week noted another similar service used by web hosts, Softaculous, was still also offering to install that version of Joomla as well.

While working on a website hosted with DreamHost we checked to see how they were doing in this regard. The good news they are not offering to install that version of Joomla. The bad news is that the version of Joomla they are installing is an outdated and insecure version, 3.6.4:

That version was superseded by 3.6.5 in the middle of December and that version was a security update. There have been three security updates released since then: 3.7, 3.7.1, and 3.7.3.

Of the other software that they offer that we deal with a regular basis most of it is also outdated and insecure.

They offer MediaWiki 1.26.3:

Version 1.26.4, which includes a security update, was released last August and version 1.26.x reach end of life in November.

They offer phpBB 3.0.13:

Version 3.0.14, which includes a security update, was released in May 2015 and version 3.0.x reached end of life in November of that year.

The offer Zen Cart 1.5.4:

That was superseded by version 1.5.5 in March of last year. If Dreamhost hadn’t added the security patches released for version 1.5.4, then that version would have been a security update over what they are offering as well.

You Don’t Need to Get In a Long Term Contract With SiteLock to Get a Hacked Website Cleaned Up

On about a daily basis we are dealing with people that come to us looking for advice and or help after having an interaction with web security company SiteLock. To make sure we are providing them the best information possible we keep track of what is being said by others about SiteLock as that helps us to be able to explain things that are brought up with us that otherwise wouldn’t make much, if any, sense.

A recent complaint about them that we ran across brings up something that we have been getting a lot questions about recently, so we thought posting on that would helpful.

Here is the complaint from the SiteLock’s BBB page:

We needed help to clean our website (they were referred to us from *********)- we are a children’s educational program and our site had been hacked by an Asian Pornography site. We were about to be featured on national TV so we needed a fix quickly. We were told that our only option was a one year…contract at $99/month- and that everything on our site would be fine. Within 30 days we still had issues and contacted them-ended up having to leave ********* and set up clean,virus-free hosting and change site- at considerable expense to us–were told we were responsible for entire contract. Cherise at first said if we waited until the first 4 months were up we could then cancel and that would count. When I called at the end of that 4 months I was told it was too late and we needed to pay-all anyone ever repeated was “you signed a year contract’. We DID try to cancel within 30 days- which under Florida law – businesses are required to follow. We were forced to pay.

There is no reason that you need to get in to a long term contract to get a hacked website cleaned up, especially a $1200 a year one. We and many others offer one-time clean up services, which are much cheaper than that, and in at least our case, won’t leave you with unresolved issues. Based on everything we have seen the reason why SiteLock pushing this type of plan is that they and their commissioned sales people are trying to get as much money as possible out of people (we recently interacted with a current SiteLock customer that they tried to sell an additional unneeded service on the basis harmless activity occurring on the website).

While there are web hosts that will strongly push their customers to hire SiteLock to clean up a hacked website, if you ask them directly they will tell you don’t have to use SiteLock. The reason they are pushing SiteLock, isn’t that SiteLock does a really great job at cleaning up hacked, as complaints like the one above show, but it is because they are getting paid by SiteLock and in the case of one of SiteLock’s biggest partners because they are run by SiteLock’s owners. Interestingly in the complaint the web host has been redacted at least once, leaving people unaware of the level of connection they had with SiteLock in this instance.

That the customers was still having issues isn’t all that surprising when you consider SiteLock doesn’t do the work needed to make sure the things they claim lead to website reinfections are done when doing cleanups and unlike any other company that we have been brought in after to re-clean a website, they do such a bad job in some instances that they leave websites broken.

Resolved?

One question we get asked about fairly often that we don’t really have a good answer to, is what to do if somebody has run into a situation like the one in the complaint (that is part of why we have a focus on making sure people don’t get involved with SiteLock in the first place). The responses to this complaint indicate it might to be to file a complaint with the BBB, though that isn’t clear.

Here is SiteLock’s response, which indicates that it was resolved:

In regards to complaint #********, we apologize for any confusion or frustration the customer may have experienced. At SiteLock, we always strive to deliver exceptional customer service. Although a contract with agreed upon terms had been signed, our number one priority is delivering the… highest levels of satisfaction. We have taken immediate actions to address the issue, and are happy to report the matter is resolved. 

But the customer’s response seems to indicate that SiteLock hadn’t actual resolved it yet:

Better Business Bureau: I have reviewed the response made by the business in reference to complaint ID ********, and find that this resolution would be satisfactory to me.  I will wait until for the business to perform this action and, if it does, will consider this complaint resolved. Regards, **** *******

If you have been able to get a refund or otherwise get yourself unwound from a SiteLock contract please leave a comment so that others can have a better idea of what might work for them.

Softaculous is Also Still Offering to Install Joomla 2.5 Despite Being EOL’d Two and Half Years Ago

Back in May we noted that service MOJO Marketplace, which is used by web hosts to provide their customers with quick installations of various web software, was still offering to install Joomla 2.5 despite support for that version having ended on December 31, 2014. We came across that while dealing with a hacked website where the web host that uses MOJO Marketplace’s service (and is also owned by the same company as them) and the web host’s security partner (whose owners also run the two other companies) both told a website’s owner that use of that version was a security weakness.

While working on a non-hack issue on another website we noticed that another service that does software installations, Softaculous, is still offering to install Joomla 2.5 as well. Not only are the offering to install it, but at this web host it is fairly prominently offered as this what you see in the last section when you log in to the web host’s cPanel control panel:
To confirm that wasn’t something where they still listed it as Joomla 2.5 despite really installing whatever is the current version you can see at the top of the page you get taken if you click the link that they are in fact still offering that version:

Seeing as they also keep track of the release date, you would think they might periodically review if they are offering software that hasn’t been updated in years to see if they should still be offering it, but they don’t seem to be considering Joomla 2.5 is still available.

SiteLock is For Some Reason Labeling Spam Links as Malware

We often have people coming to us looking for advice after an interaction with the web security company SiteLock. That frequently involves claims by SiteLock that a website contains malware. Not only is the claim not always true, but in some instances the files they have labeled as being malicious don’t really make sense as being malicious (compressed database backups for example). Back in February we ran across what looks to be part of the explanation for this, SiteLock’s malware scanner labels evidence of non-malware based hacks as malware.

In that instance it involved SiteLock’s detection of a website defacement (they were identifying the wrong website as being defaced though), which they were labeling as malware. Back in May we ran across a tweet from SiteLock that seemed to be saying that they would also label spam comments in a database as malware. It turns out that when it comes to spammy content this also applies to spammy links.

Here is screenshot we were forwarded while providing a consultation recently, showing a spam link being identified as malware and being labeled “SiteLock-HTML-SEOSPAM-iar”:

Seeing as website malware refers to either malicious code being served to visitors of a website or malicious code that is in the underlying files or database that that generate a website, labeling spammy links as malware isn’t accurate.

Why SiteLock is doing this isn’t clear. It could be as simple as lack of understanding of what they are doing. While they promote themselves as the “global leader in website security”, there is plenty of evidence out there that really don’t know much on the subject. It also could be intentional. Someone would probably be more likely to order a $100 a month protection plan (which their commissioned sales people are often trying to sell people on) if you told them they had malware on their website instead of a spam link. This also makes it harder for another security company to figure out what is going on, because if they look for malware on the website and don’t find anything they might reasonable assume they missed something that SiteLock had found.

This all is good reminder for anyone dealing with a claim from SiteLock that a website contains malware, to get evidence from them as to what they are claiming is the malware as that should go a long way to clearing up if it is fact malware, some other type of hack, or a false positive. If you have gotten that information from them about a claimed malware issue with your website and are still not sure what is going on, we are always happy to provide a second opinion on the issue.

The Online Trust Alliance Doesn’t Seem Too Trustworthy

When it comes to words that might be reasonably associated with the web security company SiteLock one of them isn’t “trust”. You don’t have to look farther that Google’s search suggestions to see that:

Google;s second search suggestion for "sitelock" is "sitelock scams".

But if you do want to look farther you could look at the situation where with a couple of their services, their content delivery network (CDN) and web application firewall (WAF) services, they promote the services as if they themselves provide them. For example, they use phrases including “SiteLock servers“, “SiteLock patent-pending technology“, and “our IP addresses“. But in reality the service are provided by another company, Incapsula. Beyond just having a security company lie about something that there doesn’t seem to be a need to, the lie is rather troubling because both of those service involve sending a website’s traffic through a third-party’s systems. While SiteLock’s customers are told those systems are theirs, it turns out they belong to a company that the customers neither are aware or have a business relationship with. That raises some pretty obvious privacy and security concerns.

Based on that we don’t understand how an organization named the Online Trust Alliance would think it is appropriate to name SiteLock to their “Online Trust Audit and Honor Roll”, as announced by a SiteLock press release.

The press release lists what is evaluated for that:

As the only comprehensive, independent online trust benchmark study, the ninth annual OTA Online Trust Audit evaluates websites in three categories: consumer protection, responsible privacy practices and security. Based on a composite weighted analysis, sites that scored 80 percent or better overall, without failing in any one category, received Honor Roll status.

If you look at the complaints from SiteLock customers it sounds like the public is need of protection from SiteLock (just last week looked at an example of SiteLock trying to sell a customer on getting unneeded work done). As for security, while SiteLock’s website may be secure, that isn’t even the case for customers included in SiteLock’s cases studies.

A Single Tweet Nicely Sums Up the Problem With WordPress Allowing SiteLock to Be Involved With WordCamps

The web security company SiteLock has a well earned reputation that can be summed up with what Google suggests when you type in their name:

Google's second suggestion is "sitelock scams".

That obviously isn’t a reputation you would think that any company would want. It would probably be difficult for SiteLock to legitimately change it though since their business model seems to be based around the activity that gets them labeled as such.

It would also be difficult because if they, for example, stopped partnering with web host to try to get people to pay them to clean up hacked website that are not in fact hacked, then they would actually have to really clean up websites to get paid and from everything we have seen they are even worse than the average web security company, which is already quite bad, when doing that. For example, we are often brought in to re-clean hacked websites after some other company had previously had done that and then the website got hacked again. While that isn’t always their fault, in almost every instance we have been told that the determining how the website was hacked never even came up, despite trying to do that that being a basic part of the cleanup and important to make sure the vulnerability that allowed the website to be hacked has been fixed. That is certainly something we have seen with SiteLock. What we haven’t seen with other companies is that SiteLock has caused websites to be broken after doing their work.

Instead of trying to change, SiteLock looks to have focused on various efforts to present a public face very different than the one that their customers and not always willing potential customers can find themselves dealing with. What looks to be an important component of that effort is their involvement and sponsorship in the conferences for WordPress, WordCamps, which uses money they have gotten from their questionable business practices. We think a tweet put out by one of those WordCamps succinctly shows what the problem with WordPress allowing that to occur is:

The claim that SiteLock wants make your WordPress secure is belied by many things we have run across, including a few recent examples: thinking that leaving malicious code on a website for a while is not a threat, not taking the actions needed to prevent hacked websites from being reinfected, and not warning about vulnerable plugins or insuring they are being kept up to date on a website they are supposed to be keeping secure. But maybe the most troubling recent example is that SiteLock is still knowingly spreading false information about the security of the core WordPress software and using it to make a profit. We would love to hear from someone on the WordPress or WordCamp side of things how that makes anyone’s WordPress secure.

At some point, maybe we have already reached that point, you have to say that WordPress is complicit in what is going on here. Back in September of last year we contacted the central WordCamp organization to let them know that about the issues with SiteLock and ask for a comment about the situation or a more general comment on any restrictions on who can be a sponsor. We never got any response from them, though it was pretty clear they saw the message. So it seems that they can’t actually justify what is going on, but are still willing take money SiteLock has gotten through less than above board business activity. We later left a comment on a blog post about SiteLock on the WordCamp US’ website, shortly afterwards the comments left on that post were removed and commenting was disabled, so there does seem to an effort to hide what is going on.

What could explain some of why they continue to allow SiteLock’s participation is that SiteLock’s owners don’t just sponsor WordCamps under the SiteLock brand, but also through brands of the web hosting company Endurance International Group, which they run. For example, at WordCamp Europe they were a higher level sponsor through EIG brands Bluehost and MOJO Marketplace (MOJO Marketplace also doesn’t seem to be too concerned about security):