Correlation is Not Causation When It Comes to the Source of Website Hackings

One of the reasons we are so critical of web security companies spreading falsehoods about security is that even without running into that people whose websites have been hacked often believe things that are wrong about the situation. This makes it harder to get the hacking properly resolved because either they are trying to deal with it in ways that don’t have any impact or they want someone else to do those things for them. Often times most of time spent communicating with clients with hacked websites is trying to clear up misconceptions, whether of the clients own creation or something coming from another security company. In some cases people are so convinced with these falsehoods that they are not interested in having the websites properly cleaned up, which leaves the website vulnerable going forward.

One common issue we run into is people believing whatever was the last action they took related to the website before they noticed it was hacked was the cause of the hack. As an example of this, we recently had someone contact us that in all likelihood had been hacked due to their running an outdated version of WordPress, 4.7.1, which has a vulnerability that allowed posts to be modified by anyone. Exploitation of that vulnerability is usually easily fixed by simply updating WordPress and reverting the posts back to an older revision. At the point they had contacted us they had already done those things, so there wasn’t really anything more that likely needed to be done. When we let them know that, they responded that:

Thanks, but the hack date is the same day we installed this plugin, which is kind of weird.   Anti-Malware Security and Brute-Force Firewall

What are the chances that installing a security plugin with 100,000+ active installs would cause such a hack? Probably close to none, but despite that, this person made that connection (that isn’t a knock on them as this type of thing comes up frequently).

The further problem we often find with this type of assumed correlation is that the correlation doesn’t actually exist, as the website was hacked not when the website’s owner became aware of it being hacked, but at some earlier time.

Finding the Real Source of the Hacking

The best bet for finding out how a website was hacked is probably to hire a company that does proper hack cleanups, which includes trying to determine how the website was hacked. Even when hiring someone that does that (like us) often times it cannot be determined with certainty how the website was hacked, as important evidence, usually log files, is gone by the time the website is being cleaned up. In that case someone that deals with lots of websites should still be able to make a fairly good educated guess as to how the website was hacked based on the remaining evidence, the particulars of the situation, and how that compares to other hacked websites they have dealt with where it was possible to make a more definitive determination as to the source.

Even if the source of the hack is not able to be determined we have found that doing the work needed to try to do that helps to make sure the website is fully cleaned. It can also help to make sure the source can be determined if the vulnerability stills exists and gets exploited again after the website has been cleaned up.

Another Reason Why SiteLock’s Lying About Incapsula Being The True Source of Their WAF and CDN is a Problem

When it comes to the numerous issues with the web security company SiteLock one of the ones we found to be the strangest is their continued lying about the true provider of their content delivery network (CDN) and web application firewall (WAF) services. While they make it sound like they are providing themselves when mentioning the services, using phrases like “our IP addresses“, “SiteLock servers“, and even “SiteLock patent-pending technology” what we found was that services are actually provided by another company, Incapsula.

We can’t think of a good reason of for lying about who provides these services, but when mentioning this previously we mentioned a couple of reason why being dishonest about that is a troubling thing. First, trust is an important part of security, if SiteLock is willing to lie about this then what else might they lie about. Second, since both of these services involve sending a website’s traffic through the provider of the service’s systems, having a website’s traffic go through a company that the website’s owner doesn’t have a relationship with raises some serious security and privacy issues.

While helping someone resolve an issue with a website recently we ran across another issue caused by this. They were having a problem caused in part by the Incapsula WAF. While they were getting an error page from Incapsula served as part of the problem, they didn’t know where that was coming from or how they could remove Incapsula’s WAF since they didn’t know that the SiteLock service being used was actually Incapsula or even that they were was a connection between the two. If SiteLock was upfront about who really provides that service then it shouldn’t have been a mystery as to the source of the error page and the issue could have been more easily resolved.

Don’t Assume Your Web Host’s Security Claims Are True

When people ask us about web hosting recommendations we tell them that we don’t provide any since we can’t independently verify a web host’s security practices. Unfortunately what web hosts say about their security isn’t necessarily true, even when it involves things that can easily be double-checked. Something we ran in to recently was a reminder of that.

After we had started making a copy of website’s files over FTP while beginning to work on a hack cleanup recently, the client told us they would need out IP address to whitelist it so that we could connect via FTP. Seeing as we were already connected via FTP, either they had just turned on the whitelisting or it wasn’t working. When we explained that we were already connected, they told us that they hadn’t just turned on whitelisting (in looking over the web host’s documentation, it isn’t even something you can turn on and off), so it wasn’t working.

Later on we asked the client to see if their web host could provide the log of FTP activity so we could see if that could have been the cause of the hack. Right at the beginning of the response from the web host, Nexcess, they claimed that IP addresses would need to be whitelisted to be able to connect, despite that not being true:

You have to whitelist your IP for FTP or you cannot login. This is done by logging into SiteWorx -> Hosting Features -> Firewall Rules.
You’ll need to add your IP and then choose the FTP service. Your IP may have changed or maybe you have never added it.
If your site was compromised, finding the IP’s that did it is likely a useless effort unless you suspect something like foul play from within your own organization or something. Otherwise, It’s likely caused by another compromised by another hacked machine or hacked hosting account as normally seems to be the case.
Compromises happen when security patches are neglected, or plugins are not kept routinely updated. Without these patches or plugin updates, any exploits located within them are not patched when the developers learn of them and release a new version to patch and close these vulnerabilities.

The rest of that response doesn’t really give us a sense they are very knowledgeable about security as they don’t seem to understand that knowing whether or not the hack came through FTP would be useful.

The takeaway from this seems to be that you shouldn’t assume that security claims made by your web hosts are true and if you want to be as secure as possible you should double check that security features are working when you can.

Manual Website Malware Removal Doesn’t Involve Manually Scanning Every File

In looking over a company’s marketing material about why they were a better alternative to SiteLock (which isn’t really difficult considering the many ways that SiteLock is a terrible company), there was a rather absurd claim made:

SiteLock likes to push their “manual” malware removal. However, with the average WordPress having about 1,900 files, can you imagine trying to manually scan that many files and have any kind of accuracy? I believe it’s a strategy for them to have such high prices.

In reality manual website malware removal doesn’t involve someone manually looking over every file on a website, which would be a waste of time. Instead it means that a human is involved in the process of reviewing the files and deciding what needs to be cleaned. One of the important reasons you don’t want a cleanup done with a fully automated process (as this company is promoting that they do and which SiteLock actually makes a big deal of doing as well), is that malicious code added to the website can provide important information on the source of the hack. Cleaning up the malicious code on a website, but not fixing the source of the hack, leaves the website open to being hacked again. We would guess that most people with hacked websites don’t want to have their website needing to be repeatedly cleaned, so they would want to have someone do a cleanup that actual does the work to determine how the website was hacked and then fixes it, instead of paying less upfront and then needing repeated cleanups.

To a large degree reviewing files on a WordPress website involves comparing the files to a clean copy of the files. In the download for the current version of WordPress, 4.7.3, there are 1473 files, so for a WordPress website with 1900 files, a large majority would be checked by simply doing a file comparison of those core WordPress files.

It also worth mentioning that the a major reason why SiteLock’s prices are so high has to do with them paying their web hosting “partners” large portion of the service’s fee, not how they do cleanups (which involves them cutting corners).

GoDaddy Still Using phpMyAdmin Version That Hasn’t Been Supported for Over Five and Half Years

Earlier this week we revisited a security issue with a web host that had yet to be resolved nearly two years after we first brought it up, but things can be worse than that.

Back in January of 2014 we pointed out that GoDaddy was still using a version of the database administration tool phpMyAdmin for which support ended in July of 2011. While dealing with an issue on a website hosted with them we noticed that they still are running that version, 2.11.11.3. It is incredible that such a big company would be running outdated and unsupported for over five and half years. You have to wonder what less visible security issues also exist in their systems.

While GoDaddy has a number of different types of accounts, according to their listing of what software is running on them all of the account types that include phpMyAdmin provide outdated versions of it. The newest version they are providing with an account type is 4.0.10.14, which is over a year out of date. They also are using 4.0.8, which is over three years out of date. Finally they are using 3.5.8.2, for which supports ended over three years ago.

When looking at this situation we can’t help but think of the GoDaddy’s partnership of with the security company SiteLock. If we were not already aware of what SiteLock actual does, it would seem very odd that they would not have required GoDaddy to deal with this issue long or ended their partnership, as it would highly irresponsible, at the very least, to be involved with a company that you know is leaving their customers insecure in this way.

CloudAccess.net Still Storing Non-Hashed FTP/SFTP/SSH Passwords

Back in May of 2015 we had put out a post discussing the fact that the web host CloudAccess.net was storing FTP/SFTP/SSH passwords in non-hashed form. Here is how we explained why storing them in hashed form was important, at that time:

One of the measures that needs to be taken is to store passwords as securely as possible, which means storing them in hashed form. You can think of a password hashing as one-way encryption. That is, the data is encrypted, but it cannot be decrypted, so the underlying password is not retrievable in normal circumstances. With this type of password storage when someone tries to log in the password they input is hashed and then compared with the stored password hash to see if they are the same. With hashed passwords even if someone gets access to the stored passwords it would be difficult for them to do anything with them, since they would first have to crack the hashes.

Then back in January we received a comment on the post apparently from the CEO of CloudAccess.net:

I represent CloudAccess.net, the company that you are writing about. To clarify, we do not store ANY passwords or sensitive information in clear text. Your assumptions are incorrect here. In the future if you have any questions or concerns you may ask us directly and we will explain further to alleviate your concerns. Thank you.

We didn’t really know what to make of that since it didn’t address the issue of the passwords not being stored in hashed form, instead only claiming that they were not stored in clear text, which isn’t the only way non-hashed passwords could be stored. So either the person didn’t really understand the issue at hand or they were trying to divert from the real issue.

Whatever was the case there, the issue hasn’t been resolved as we were just working on a website hosted with CloudAccess.net and found that they are still storing the FTP/SFTP/SSH passwords in non-hashed form. You can see below that on the relevant page in their control panel there is still the option to  view the password by clicking on “View hidden password”, which would not be possible if they were hashed:

 

Positive SiteLock Review Praises Them for Leaving Website Insecure

When it comes to finding a web security company to help deal with a hack or other security issue with a website you have a lot of bad options, as from what we have seen most security companies don’t know and or care about security. One of the results of that is that often these companies don’t even try to properly clean up hacked websites.

We are often brought in to re-clean hacked websites after another company did a cleanup and the website was then re-hacked. In that situation the first question we always ask is if the previous company determined how the website was hacked, since if the source isn’t found and fixed it could be exploited again. The answer is almost always that doing that never even came up. Considering that doing that is one of three basic components of a proper cleanup, either the company doesn’t understand what the service they are offering should even include or they are intentionally cutting corners.

One company that doesn’t do things properly is SiteLock and more troubling they use their corner cutting to try to get people locked in to long term contracts. You would think that a website getting repeatedly hacked due to that would only lead to only negative reviews, but one recent review for them on the BBB page for the company actually praised them for this:

Sitelock has been there for me in the middle of the night when my blog was compromised several times this year. I am a one woman team and it is great to know that I have Sitelock always there for me making sure I am all safe and secure. It is so wonderful to have a live person to talk to when you need it 24/7. Now on to my gluten-free baking and blogging!

We don’t understand how having a website compromised several times only two months in year could be paired with a claim that the company that dealt with the issue is keeping it “safe and secure”, but it happened here.

That is good reminder that you can’t rely on reviews of web security companies to point to a security company that can actual provide with a good result, because they are often praised despite providing a bad outcomes. We have even had clients that come to us to re-clean websites saying the previous company did a good job, despite needing us to re-do the work. In some cases like this one you might notice the inconsistency, but in others the details needed to spot that the praise is misplaced are missing.

Is SiteLock Providing Their Customers Access to All Accounts on GoDaddy Servers?

In looking over complaints about the web security company SiteLock a lot of things come up over and over, take for instance the end of a review of them from earlier this month at the website ConsumerAffairs:

Worst case scenario: a site will become infected with malware. Again, I get the auto-email with no clue to which site is infected. You have to upgrade your account to get it cleaned and then it never stays clean. It continues to get infected every few months and they do nothing to help you prevent or fix it. The one site that I’ve had this happen to, I ended up upgraded to the manual clean & monitoring service. Instead of them cleaning it when it happens, they send that email (you know the one, without any clue as to which domain it is referring) and then I have to call them to request it to be manually cleaned. AGAIN. They don’t just automatically do it, like the service implies. I cannot tell you what a frustrating phone call it is. They have no email or chat support and you are stuck to a phone call with someone who is trying to earn commission and has no interest in supporting you. DON’T USE THEM.

A lot of that isn’t surprising if you follow our blog, as we have discussed that usually when you get in contact with SiteLock you are dealing with a commissioned sales person (and how that looks to lead to untrue information being told to potential customers), the fact they cut corners when doing cleanups and leave websites insecure. It could actually have been worse as this review involved websites hosted at GoDaddy and we have previously discussed instances where websites cleaned through their partnership with SiteLock have left the websites broken.

What was new in this review was the claim of the prior paragraph of the review:

Once I find the account with the issue to reconnect, it is an absolute nightmare to do so. You have to enter the FTP info, then sift through EVERY SINGLE Godaddy site on the server to find yours (I’m not kidding, and I’m sure you can imagine there are a lot of sites on Godaddy’s server – why I have access to every single one of them via SiteLock seems like a security issue in itself). It’s an extremely tedious, SLOW and frustrating process.

It isn’t clear what level of access they are referring to there and what could be done with it, but there shouldn’t be any access to unrelated accounts at all (especially through a security service).

If you have more information on what access they are providing through that please leave a comment on this post or get in touch with us.

SiteLock and Bluehost Falsely Claimed a Website Contained Malware Due to SiteLock’s Poor Scanner

When it comes to the web security company SiteLock, one of the frequent complaints is that they and their web hosting partners falsely claim that websites have malware on them. After that happens the web hosting company frequently suspends access to the website and pushes the customer to hire SiteLock to clean up not existent malware. We thought it would be useful to look at an example of this we were recently consulted on, as those dealing with the possibility of a false claim should know a number of things when dealing with it.

This situation involved the web host Bluehost. Bluehost is one of many brands the company Endurance International Group (EIG) does business under. Some other major ones are A Small Orange, FatCow, HostGator, iPage,  IPOWER, and JustHost. The company’s web hosting brands are very open about having a partnership with SiteLock, what they have, at least in the past, refused to acknowledge publicly is that partnership involves EIG getting 55 percent of revenue for SiteLock services sold through that partnership (that information was disclosed to investors). That obviously raises some serious questions and it probably explains in large part a lot of the problems that arise from that partnership. What they also don’t disclose to their customers is that the majority owners of SiteLock are also a member of the board and the CEO of EIG, so they are well aware of SiteLock’s practices.

What we have repeatedly said is that if you get contacted by SiteLock or one of their web hosting partners claiming that the website is infected or otherwise is hacked, is that should not ignore it. While there are plenty of situations like the one discussed here where there is a false claim, the claim is also often true. For a hacked website, the longer you wait to do properly clean it up, the bigger the problem can be. Instead we recommend that you first get any information that SiteLock and or the web host will provide and then get a second opinion as to whether the website is hacked. We are always happy to provide that and we would hope that other security companies would as well (when someone contacts us about a hacked website we always make sure it is actually hacked before taking on a cleanup).

One of the reasons for getting a second opinion is that someone familiar with hacked websites should understand how to easily check the validity of the claims made. While someone not familiar with the situation might try doing checks that won’t necessarily be very useful. In this situation one the things the website’s owner did was to download a copy of the website’s files and run them through a malware scanner. That likely is going to fail to identify many files that contain malicious code because a malware scanner for a computer isn’t designed to detect those files (our experience is that scanners designed to scan website files don’t produce great results either).

When we were provided the information that the website’s owner had received, the first element that caught our eye was this result of SiteLock’s malware scanner:

What was shown was rather odd as the malware scanner claimed to have detected a defacement hack (labeled as “SiteLock-PHP-HACKEDBY-klw”), which isn’t malware. So at best the scanner was incorrectly labeling a hacked website as containing malware, when it had a different issue.

More problematic is that it looks like they might are flagging websites as being defaced just because they have text that says “hacked by” something. That could produce some rather bad false positives, since this post itself could be claimed to contain malware simply by using that phrase. They also mark that detection as having a severity of “Urgent”, despite that.

So was the website defaced as that scan seemed to indicate? The website was taken down by the point we were contacted, which wouldn’t need to be done just because there was a defacement and makes it harder for someone else to check over things (whether intentional or not, it seems like something that makes it easier to push someone to hire SiteLock to resolve the issue). Looking at the Google cache of the website’s homepage though, we were able to see what happened.

The website’s page contains a section that shows RSS feeds items from other websites. One of those websites had been impacted by a vulnerability in outdated versions of WordPress that allowed defacing posts and the results of that defacement was showing on this website:

That “hacked by” text on showing there didn’t mean this website was infected with malware or otherwise hacked and the website didn’t pose any threat. That is something that anyone from Bluehost or SiteLock familiar with hacked websites should have spotted by looking over the website for a few seconds, but clearly that didn’t happen, even when they suspended access to the website. Both of them have an incentive to not check to make sure the website is hacked, since they have monetary interest in selling security services in this situation even though they are not needed. As we mentioned recently it appears that when you are in contact with SiteLock you are dealing with a commissioned sales person, not a technical person, so they might not even understand what is actually going on either (one situation we looked at recently would strongly seem to indicate that as a possibility).

Looking at the files that Bluehost had listed as being infected, they were just cached copies of the content from the website that had the RSS feed section in them. So there wasn’t any malware in them.

It also seems that no one from Bluehost or SiteLock bothered to contact the other website to let them know that there website was actually hacked, seeing as it was quickly fixed after we notified them of the issue they had.

At this point the website’s owner is planning to move to a new web host, which doesn’t seem like a bad idea (we think that people should avoid web hosts that have partnered with SiteLock even if they have yet to run into this type of situation).

Trend Micro Thinks Their Continued Failure to Take a Basic Security Measure Shouldn’t Define Them

Back in May of last year we noted that cyber security company Trend Micro was failing to keep the installation of WordPress on their blog up to date. What stuck out about this was that this shouldn’t have happened, as WordPress has an automatic background update feature that would normally have done the updates without requiring any interaction by someone at Trend Micro. So either there was some incompatibility between their hosting environment and that feature or they unwisely disabled the feature without making sure to promptly do the updates manually instead. If it was the former, then they could have probably helped not only themselves, but others by working with WordPress to fix the cause of those updates not occurring.

Fast forward to last week where it was reported that another one of their blogs was attacked due to a vulnerability in WordPress that would have not been possible to exploit on the website if they either had gotten automatic background updates working or if they had started promptly updating manually.

The response from the company’s “Global head of security research” makes it sound like the company has no idea what they are doing:

“We got reports from many researchers, regarding attacks using this vector and we deployed a custom policy to block the attacks,” he explained.

“Unfortunately there are many different URLs attackers can use to carry out the same attack, so a couple of fake ‘articles’ ended up posted on CounterMeasures. We have responded and shut down the vulnerability completely to resolve the issue

“Just serves to demonstrate something that I have often repeated in presentations, we are all a potential victim of digital attacks and we can’t afford to take our eyes off the ball at any time. The best way to respond to any attack of this nature is with honesty and alacrity, and that’s what we have endeavoured to do.

“Of course technology and best practice can mitigate the vast majority of intrusion attempts, but when one is successful, even one as low-level as this, you are more defined by how you respond than you are by the fact that it happened.”

The really simple solution to prevent this vulnerability from being exploited is to make sure you updated from WordPress 4.7.0 or 4.7.1 to 4.7.2, but there is no mention of that. Instead they make some mention of a “custom policy to block the attacks”, which is not necessary if you just updated to 4.7.2.

Amazingly as of this morning the blog is still running WordPress 4.7.1, as can easily be seen by viewing the source code any page on it:

The main Trend Micro blog doesn’t contain a meta generator tag, which makes it easy to spot what version is in use, but if you look at the CSS and JavaScript files being loaded on it you can see repeated use of “4.7.1” in the URLs, which tells you it is also on WordPress 4.7.1:

Defining Trend Micro by their response to getting attacked rather than their failure to take best practices doesn’t seem to make things better here, since they still have failed to properly respond to the situation by updating WordPress. Since they can’t handle the basics, you really would have to wonder about their handling of more serious things. Or you would if the wasn’t already evidence they can’t.