Category: Bad Security

Is There Anything That Security Companies Won’t Try to Mislead People About?

From dealing in security for years we have become somewhat inured with a lot of the bad behavior going on, but one area where it is still surprising how bad things are is the level of dishonesty and often outright lies told by security companies. Considering that trust is an important part of security, it would seem like security companies would be careful when it comes to that type of thing, but from what we have seen that isn’t the case. That certainly isn’t helped by the public’s willingness to ignore and to some times defend companies that engage in that type of behavior.

While in some cases security companies lie about things that it would be hard for the public to check for themselves, in other instances the claims are easily checked, so it seems like at this point that companies may feel they can mislead and lie with impunity.

We recently came across an example of this from a company named Quttera. Back in March they had a blog post titled “Quttera WordPress Malware Scanner: 400K Installations and Counting” with this graphic at the top of the post:

Having 400,000 installations would make the plugin one the most popular WordPress plugins, so that would be impressive.

WordPress prominently displays how many active installations that plugins in its Plugin Directory have, so it wouldn’t be hard for anyone to check to see if that is true.

What anyone doing that would find though is that the plugin only currently has 10,000+ active installs:

So what is going on here? Well the first sentence of the Quttera’s post explains it somewhat:

A few days ago, the download counter of the WordPress Malware Scanner plugin passed 400K installations–and with good reason.

They are conflating downloads and installations. Considering that WordPress provides both installation and downloads stats that seems hard to provide an innocent explanation for doing, but it is more problematic when you know what is counted as a download. WordPress counts each time an installed plugin is updated to a new version as a download. That is important here because the number of active installations might not give a complete picture if a lot of people installed a plugin, used it successfully, and then removed because it wasn’t needed after that. If that were the case with this plugin the chart of downloads would look very different than it does.

As you can see the chart shows frequent spikes of downloads and then sharp drop offs:

Those spikes are when new versions are released. When you are releasing new versions every three or four days that can lead to a lot of downloads, as is the case with this plugin. Quttera would like you believe otherwise as the first paragraph of their post shows:

A few days ago, the download counter of the WordPress Malware Scanner plugin passed 400K installations–and with good reason. This incredible plugin has a number of key advantages that have helped many of our customers build their websites and create the amazing online communities they’ve hoped for.

While this in its self doesn’t really matter that much, it does give you an indication that this company might not be the most reputable company.

In a quick check we found that their plugin is itself insecure due to failure to do some basic security, which doesn’t seem like a good indication of their concern for security. We will be disclosing the details of that over through our Plugin Vulnerabilities service, once Quttera has had a chance to fix that.

What we noticed that seems more relevant when it comes to trust is something we noticed we went to look at the details of the service they offer. The service is prominently marketed as involving malware cleanup:

They also claim to offer a “30 days money back guaranteed.”:

Though like another security company we discussed recently they hide an important detail of that policy on another page. That being that there is no refund if you have had a cleanup done:

You will have thirty (30) days from the Service Commencement Date or any Renewal Commencement Date to cancel the Service (the Cancellation Period), in which case the Company will refund your Service Subscription Fee for the applicable Service Term provided that you have not utilized malware removal services during the Cancellation Period.

To us that seems like a detail that should prominently mentioned when promoting the guarantee since we would assume that many of their customers would be coming for a cleanup and so they should know that the cleanup isn’t backed up with any guarantee (especially since so often we see security companies failing to properly clean up hacked websites, so a refund would be warranted after a cleanup was done). It seems like they could have disclosed that in the same amount of words that it took to mention that the details of the policy are on another page.

Sucuri’s 30 Day Guarantee Guarantees That They Won’t Properly Clean Up Your Website

In our dealing with the continued poor state of web security, which seems to be a microcosm of the poor state of security in general, what we see is that there are many different pieces that all come together to get to the current situation. The really terrible shape of the security industry probably couldn’t exist without the public helping them out in numerous ways. One of those ways is that you have a lot of people that don’t really seem to be paying much attention before handing over money to unscrupulous security companies.

We recently had someone contact us looking for help with a hacked website. They hadn’t provided any details as to how they thought the website was hacked and considering that many people come to us that think a website has been hacked when it hasn’t, we first went to look at the website to see if we noticed any issues. We noticed one issue and we then responded asking if that was what was at issue or if there something more. They responded that they already were a paying customer and had sent several message to support that they hoped we would address. Neither of those things sounded like us, especially since we charge after we have completed a cleanup, not before. It turned out that they had confused us with another company named Sucuri.

What was odder about that was that the person said they had seen Sucuri mentioned on our website and decided to give them a try. Considering that we have repeatedly written about problems caused by Sucuri, particularly involving hack cleanups, it doesn’t seem they could have been paying almost any attention to what we had written about that company.

That ties in to understanding something else that they mentioned, which is that Sucuri told them they provide a 30 day money back guarantee. They didn’t look into the details on that, which they should have.

We were curious to see what Sucuri’s refund policy actually was and found that they are inconsistent in what they claiming to provide. More importantly there are some huge caveats, so the guarantee would be of no value in a lot of cases.

On the homepage they advertise it this way:

30-Day Guarantee

You have 30 days to request a refund according to our Terms of Service.

Looking at the terms of service they first state:

You will have thirty (30) days from the Service Commencement Date or any Renewal Commencement Date to cancel the Service (the “Cancellation Period”), in which case the Company will refund your Service Subscription Fee for the applicable Service Term provided that you have not submitted a Malware Removal Request during the Cancellation Period.

Based on that if you sign up for their service and request a cleanup you can’t get a refund, so if they don’t properly clean things up (as they won’t) you are left paying for something that wasn’t done right.

In listing their various levels of service they make a big point of response time, so it seems pretty likely that they expect that many of their customers are coming to them looking for a cleanup:

So it seems like their refund offer would probably be immediately null for many of their customers. It also seems like if they were interested in be honest with their potential customers they would be upfront about that limitation, instead of burying that important limitation in a long legal document.

Later in the terms of service page they say something different:

If at any time during the Service Term, you submit a Malware Removal Request for a Covered Website that Company determines is infected, Company will use reasonable commercial efforts to clean the infected Covered Website. In the event that Company is unable, for any reason, to clean the infected Covered Website, Company will, as its sole and exclusive remedy, refund to you the annual fee you paid to the Company for the clean up of that Covered Website.

That would sound significant if we haven’t see what can actually happen when Sucuri is supposed to be dealing with a hacked website.

In April of last year we discussed a situation that we were brought in where Sucuri’s service had been purchased and they had claimed to have cleaned a website. When the original issue, credit cards being used on the website were being compromised, continued, the person running the website contacted Sucuri about that and Sucuri told them that the website was clean, despite it being very likely it wasn’t. This person wasn’t looking for a refund, just for them to clean things up, which considering Sucuri’s service is marketed as providing “Unlimited Malware & Hack Cleanup”, shouldn’t have been an issue. They instead had to hire us to get things properly cleaned up.

On Sucuri’s page about cancelling an account they have the following Refund section:

Refunds

Refunds are only available within 30 days of purchase and will only be issued in case a manual malware removal was not completed. On all other cases, you can cancel the account, but a refund will not be provided.

That doesn’t match what is written in the terms of service, so who knows what is going on there. But if that is to be believed all they are actually offering is a refund if they don’t “complete” a manual malware removal. Considering that based on everything we have Sucuri doesn’t even really attempt to do complete cleanups, that doesn’t seem meaningful.

Right below that section is a Guarantee section:

Guarantee

We guarantee our work, so if your site gets reinfected we will clean it up again until it is 100% clean. But you also have to do your part and keep your sites updated, change passwords and follow our recommendations.

If you do not follow our recommendations, we will not clean it up again until they are done.

As situation we were brought in to clean up after Sucuri in March shows, even when Sucuri is willing to clean things up again it doesn’t mean the website is ever going to get fully cleaned as the website in that situation was repeatedly incompletely cleaned up by Sucuri. What was happening is that Sucuri repeatedly removed parts of the hack, but since they didn’t remove the others, what they were removing just came back over and over.

One of things that would have stopped that cycle would have been if Sucuri had done one of the three pieces of a proper clean up, which is trying to determine how the website was hacked, as reviewing the logging as part of that would have identified where the remaining malicious code was.

Sucuri not only fails to do that piece of a proper clean up, but they fail to do another one, which involves getting the website secure as possible. That usually mainly consists of getting any software on the website up to date. Based on that guarantee language they even try to push that off to the customer.

In fact while they sell their service as website security service, the guarantee seems to indicate they don’t do anything that will actually secure the website. What it looks like is that you are paying them an ongoing fee for them to be on call to improperly clean up your website.

If your website hasn’t been hacked you would be better off spending your time and money on doing the basics of security, as doing those things will greatly reduce the chances of the website being hacked. If your website has been hacked you would better off hiring someone like us that will actually clean the website up properly and fully stands behind their work instead of providing you with a misleading “guarantee”.

Sonatype Turns Their Distribution of Insecure Software Into Misleading Stories About Other Companies

When it comes to improving the security of websites, security journalists could play an important role, but they unfortunately do not seem to be interested in doing that. Instead they spend a lot of time spreading misleading and outright false information that comes from security companies. Often times, like a game of telephone, the information being provided gets more inaccurate as journalists repeat the claims of other journalist (in some instances without disclosing they are copying information from others).

A good example of that comes from something we had run across today. On ZDNet’s security blog the Zero Day (which at least previously was written by people that didn’t know what a zero day is) there is a post headlined “After Equifax breach, major firms still rely on same flawed software” with the sub-headline “At least seven tech giants still use the vulnerable software that hackers exploited to attack Equifax last year.” An obvious question would be what was the methodology used to determine that. If you read the post you will find out that it wasn’t actually determined at all nor was it claimed to have been. Instead what was measured was downloads of the software:

Thousands of companies have downloaded vulnerable versions of Apache Struts, a popular web server software used across the Fortune 100 to provide web applications in Java. It’s often used to power both front- and back-end applications — including Equifax’s public website.

Downloading a vulnerable version of software doesn’t mean you rely or use it. For example, when we are dealing with hacked websites we might need to download older versions of software to use to compare the copy of the software on the website to a clean copy.

Later in the post it was mentioned that Fortune had reported on this prior to ZDNet:

Fortune was first to report the data.

The Fortune story has a more accurate headline “Thousands of Companies Are Still Downloading the Vulnerability That Wrecked Equifax”. Here is how they source that:

As many as 10,801 organizations—including 57% of the Fortune Global 100—have downloaded known-to-be-vulnerable versions of Apache Struts, the popular, open source software package that attackers targeted to loot Equifax, from March 2017 through February 2018, according to data from Sonatype, a Goldman Sachs-backed cybersecurity startup that tracks code pulled by software developers.

And here is how Sonatype determined that:

Sonatype was able to collect the data it shared with Fortune, Jackson explains, because it maintains a code repository, Maven Central, relied upon by many software developers as they build applications. When requests for code components come in, Sonatype is able to conduct reverse lookups on the requesters’ IP addresses, and thereby determine from which organizations they originated.

So Sonatype is the one distributing the insecure software to these companies and also tracking what they are downloading, which seems like it might be what those journalists might want to cover.

Here Is How SiteLock Tries To Mislead People with Their Meaningless Attacks per Day Stat

We frequently have people contacting us looking for help after they have been contacted by the web security company SiteLock, through that we often hear bit and pieces of the misleading and outright false claims they frequently make. Recently we have been sent complete sets of communications between them and the people they were trying to take advantage of. There are a number of things we have noticed in those that seem worth touching on, but we will first start with something related to something we discussed in another blog post a month ago.

This comes from an email conversation with a SiteLock “website security consultant”, which is really just a commissioned sales person. You can probably guess from that how misleading the title is from what the person really does that what they are telling people also isn’t truthful.

Here is a claim that the sales person made:

You have been very blessed if you site has not been hacked for 6 months as a typical website faces 44 attacks a day. With out the proper security any and all of those attacks can effect your site.

When we discussed that stat last month we noted that what would relevant would be how many successful attacks there are, not how many attempts there were. As we also noted then, SiteLock’s president actually claimed they were able to determine what were successful attacks:

As our research shows, cybercriminals are now able to successfully breach a site with fewer, more targeted attacks.

If they truly know that (it seems like they probably didn’t, but were claiming otherwise to make a reduction in claimed average attacks sound scary) why wouldn’t they let people know how many successful attacks there are seeing as those are what what actually matter? An obvious answer would be that successful attacks are incredibly rare. It isn’t like the average website is being hacked once a year, much less multiple times a day as the sales person’s claim implies is possible.

In the rest of the email no evidence was provided that the $99 a month service they wanted this person to purchase would do anything to protect the website from being hacked and they even promoted that the service includes unlimited cleanups, which wouldn’t be needed if the service actually protected the website since it shouldn’t be needed to be repeatedly cleaned up if the services actually secured the website. Based on their marketing material it seems that SiteLock believes that a security service shouldn’t actually be able to secure website against being hacked, which in way makes sense since simply doing the basics is what will actually provide real security.

Just Because SiteLock Is Trying To Con You Doesn’t Mean Your Website Hasn’t Been Hacked

In interacting with people about hacked websites one of the things that comes up frequently is people conflating security companies trying to take advantage of them with a belief that their websites haven’t really been hacked. A lot of the blame for this resides with the security companies that are trying to take advantage of people (and look to be very successful at it) and others that help enable that, which includes their business partners and government entities that don’t take any action against them. But some of the blame has to be placed on customers of these services that seem to take a completely uncritical view of these services, as among other things, their funding of these companies allows the companies to expand and take advantage of more people.

As an example of that, we had someone contact us recently after they ran across a post we had written how the web host Bluehost was continuing to try to sell SiteLock services based on claims that were made in phishing emails meant to look like they came Bluehost support. The situation this person had was very different than that.

They had been contacted by a company informing them that their website was being used for phishing. Their web host, Bluehost, which is a SiteLock partner, had suspended their account for the same issue. They said they were “shocked” because they had SiteLock on the account and they thought that with that the website wouldn’t have been able to be hacked.

As company that deals in the field we obviously have a very different view of things, but it still is hard to understand a view like that when you consider that SiteLock and every other similar company we have run across don’t provide evidence that their services are effective at protecting websites. To us that seems like a baseline before purchasing any service like that, but clearly it isn’t.

The next part of the story is something that we have heard plenty of times before, but it still doesn’t make much sense to us. That being that they were then told they would need a higher level of SiteLock service to protect against the issue from happening again. To us that raises what seem to be some obvious questions, like why would SiteLock by their own admission be selling security services that don’t actually provide security. Another one would be why would at that point people still not expect some evidence to presented as to the effectiveness of the services considering SiteLock have just admitted that they are selling services that don’t actually work.

When we had responded explaining about that lack of evidence that SiteLock services are effective (along with plenty of evidence to the contrary that we have run across) and that SiteLock’s own marketing indicates that they are not even attempting to provide real security the response from the person was not concern with SiteLock’s practices, but that the whole situation seemed suspicious. We asked about the evidence presented that the website had been using for phishing, but the person seemed uninterested in actually checking over things. Based on past experience our guess is that the website was actually hacked in this case.

Dealing With a Possibly Hacked Website

While in this case we guess the website had actually been hacked, we have run into plenty of instances where SiteLock and their web hosting partners are falsely claiming that websites have been hacked. So what we recommend you do in that situation is get a second opinion on their claim. We are always happy to provide that for free and would hope that other reputable security companies (to the extent that there are any) would do the same.

If the website is hacked what you want done is to have it properly cleaned up, which involves cleaning up the hack, securing the website (which usually mainly involves getting the software up to date), and trying to determine how the website was hacked and fix that. If a service doesn’t do those things (as is true of SiteLock’s main services) then you stand a decent chance of having continuing issues. After things have been cleaned, instead of paying for a security service that won’t protect your website, you should make sure to do the basics to keep your website secure from most issues.

The Overstated Security Risks of Using an Outdated Version of WordPress

In dealing with hacked websites we often not only have to deal with cleaning up the hack but also trying to clear up misinformation that people hiring us have run across before coming to us. One area of that we used to deal with a lot, were people that were sure there websites were hacked due to usage of outdated software, often the software in question being WordPress, despite there not being any vulnerability in the version in use that would have been likely to be something that a hacker would actually try to exploit. That wasn’t all that surprising since you often have, among other things, security companies that don’t properly deal with hacked websites that will simply claim that outdated software was the cause of a hack instead of trying to determine how websites actually were hacked.

Misinformation continues to be put out along those lines, as a blog post on the The SSL Store that recently showed up in a Google Alert, which we have to keep track of vulnerabilities in WordPress plugins for our Plugin Vulnerabilities service, shows. In looking at that we saw two key things that we thought were worth pointing out about the security of WordPress and security in general.

Outdated Doesn’t Necessarily Mean Insecure When It Comes To WordPress

While there certainly problems with the handling of security of WordPress, other things are done better than other web software, which you might not know of due to the poor quality of coverage of its security.

One area that WordPress has been ahead of other software is in its update mechanism. WordPress has long allowed easy updating of itself. Things got better in WordPress 3.7, which introduced automatic background updates. While that features allows doing any type of update automatically, by default what it does is automatically apply minor WordPress updates without requiring any action the people managing the website. So for example WordPress would normally automatically update from 4.9.4 to 4.9.5, but wouldn’t go to 5.0 automatically.

Alongside that feature WordPress started releasing security updates for older versions of the software as minor updates. So even websites still running versions back to 3.7 are currently getting security updates. That post missed that entirely. Instead treating websites that were running the latest minor releases of version 4.7 and 4.8 as if they were insecure, despite having the same security update as the latest version of 4.9.

Most Vulnerabilities Are Not a Major Threat

One of the problems we see not just with WordPress, but in general is that people don’t have an understanding that not all vulnerabilities are of equal concern and risk of being exploited. What certainly doesn’t help that is that security companies often vastly overstate the threat from vulnerabilities they discover or are discussing.

The reality is that most vulnerabilities out there are not likely to be exploited. With WordPress there was about a decade where despite numerous vulnerabilities being found and fixed there wasn’t any successful hacking at any significant scale of those vulnerabilities. That streak was broken early last year with a vulnerability that had existed in WordPress 4.7.0 and 4.7.1. But even with that vulnerability the impact was fairly limited, as most websites had been automatically updated to 4.7.2 before exploitation started and for most websites still vulnerable, it only lead to the contents of post or pages being modified. That meant that cleanup was easy as all you had to was replace that content and normally WordPress have prior versions stored that could be reverted to. So the even for websites where the automatic background updates were not working for some reason and the website was not manually updated before exploitation started, the vulnerability was more of a nuisance.

You wouldn’t know that from that post since there was this inaccurate quote from a security professional:

When a vulnerability is found in a version of WordPress, hackers will create an exploit for that vulnerability and then cast a wide net, usually in an automated fashion, looking to see who is not up to date. Realize the importance of a “wide net”, they don’t care who you are or what you do, just that you have a site.  Once compromised, the hacker will then see what they can get from their site such as account information and then maybe try to use that information to attack other systems that you may have.  At the very least, the hacker will trash your site or use it to store data of importance to them (stolen data, illegal pictures, etc.).  The result, at the very least, is a bad public image when it is discovered that your site was compromised.

Again, a lot of vulnerabilities in WordPress simply would not lead to hackers doing anything that would impact the average website. Also, when it comes to the average website getting hacked, the hacker is usually using it as part of spam or malware campaign (with spam being more common these days with the hacked websites we are brought in to deal with) and the hacker doesn’t care about any data on the website.

Another inaccurate quote in that post from a web develope is as follows:

Once your website is hacked it’s very difficult to repair. Essentially, hackers who get in to your website will create new hidden entry points and unless you close them all, it’s easy for them find a way back in. The results are horrible for the business.

As the example of the vulnerability in WordPress 4.7.0 and 4.7.1 shows, the impact can be less than what they described there. It also important to note, because we sometimes have people that contact us that believe their only option is to start over with a new website, if you hire someone that properly cleans up websites (which unfortunately isn’t the case with many security companies), it shouldn’t be too difficult for them to get the website fully cleaned up in almost all cases. It would be much better to do the things that will actually keep a website secure than hiring someone to clean it after not doing those things or spending money on a security service that isn’t actually focused on keeping websites secure, though.

Somehow SiteLock Got a Five Star Review for Failing to Properly Clean Up a Website Multiple Times

When it comes trying to find a company to help you deal with a hacked website, one of the big problems is that many people providing reviews and recommendations don’t actually have a good idea of what a proper hack cleanup service would entail. We have had people that come to us re-clean websites, who after we ask if the previous company had determined how the website was hacked, tell us that trying to do that never came up, but the company did a good job. The fact that the website needs to be re-cleaned seems like it might be an indication that they didn’t actually do a good job, but what tells us for sure that they didn’t do a good job is that they didn’t try to determine how the website was hacked despite that being one of three basic components of a proper cleanup. In our experience a lot of companies fail to attempt to do two of the three components of a proper cleanup (the other being securing the website, largely by updating the software), which makes it not all that surprising that we have a lot of people coming to us to re-clean websites.

With one company trying to find an accurate assessment is hard as they have flooded review sites with positive reviews of little value. That company being SiteLock, which otherwise has a rather bad reputation. That bad reputation is due to their business practices, which are even worse than the usual bad practices of the industry. Instead of trying to improve them, which might not be possible since without misleading and greatly overcharging people they likely wouldn’t be able to sustain their business due to the poor quality of their offerings, they have focused on pushing people to leave reviews right after having an interaction with them.

One review from last week that we ran across really stands out for that. The review was one of two five starts reviews left by this person in the same day.

The first one is rather vague:

certainly professional and extremely responsive to my problems….highly recommend!

The second one is more specific:

I have had to request three successive cleanings (all in one day) to hopefully resolve a malware problem – this particular malware was very persistent and difficult to eradicate. Each time I requested a repeat service, they did not hesitate or put me off – they worked the problem with professionalism, and for that I am very appreciative. Thank-you.

That they failed to clean things up fully at least twice (it is entirely possible the issue still hadn’t actually been resolved and even the review just says that it was “hopefully” resolved) seems like it should be a negative, but somehow that is treated as positive.

Maybe it says something about SiteLock’s targeted customer base that they are “appreciative” of someone doing what they were already paid to be doing.

The reality here is that from what seen of SiteLock, they don’t properly clean up websites, including skipping those two components of a proper cleanup, so the situation where the issue wasn’t resolved multiple times isn’t surprising. Cutting those corners wouldn’t be what we would describe as professional behavior.

Down the road the results can be worse, below is a review left on another review website, consumeraffairs.com, from just a few days ago, which is in line with we have heard repeatedly about SiteLock:

My website was hacked about 3 months ago. I signed up for Sitelock services as they promised me that they would clean my website from all malware and make sure that it wouldn’t be back. They explained to me that the hackers had found a back door and they were going to repair all the files and make sure that they wouldn’t find their way back in. They did clean my website and it was up and running well after about 48 hours. Their customer service reps and technical reps are very nice and sound very knowledgeable. Their service is not cheap at all but I thought that for $50 a month, I was now covered… 3 months later, I suddenly couldn’t log in onto my admin panel. My access was “forbidden”. I contacted them many times (as well as my website host) with no answers at all from Sitelock. No one contacted me back…

Fortunately, after about a week, I was finally able to log in but with no explanation. Three weeks after this first incident, the same thing happened again. When I called this time Sitelock (instead of contacting them online with no response) the rep told me it was probably a problem with my host server. After spending 1 hour with my host server, I was told it was something else. I contacted Sitelock again, this time to be told that my site had been hacked again: the first hackers had “reopened” the back door (that Sitelock was supposed to have found and closed) and this time wanted total control of my site.

They could remedy this if I pay $45 additional a month. I am totally in disbelief and refuse to pay this additional fee as I really think that this is their fault if I was attacked again. They didn’t protect my website sufficiently as they promised they would. I am extremely unsatisfied at this point. I still cannot log into my website but I don’t want to pay another dollar for a service they didn’t render. In the meantime, I’m stuck and pissed off!

Considering that SiteLock’s idea of website security doesn’t involve actually securing websites, what happened there isn’t surprising.

Based on everything we have see the likely reason why this person was told they would need to pay more to remedy the situation is that when you get in touch with SiteLock you are usually dealing with a commissioned sales person, not a technical person, so they don’t have the capability to resolve an issue and their interest in getting you to spend money with them or in the case of existing customers, more money (we have seen that done up to level of trying to sell someone a cleanup for a website that wasn’t hacked).

What is also interesting about that situation is that there was a belief that the cost of the service was indication of the effectiveness as opposed to some actual evidence that the service was effective (which we haven’t seen SiteLock or providers of similar ever provide despite making incredible claims about the security their services are supposed to provide).

Does Sucuri Believe That There Are Unreal People Working At Other Website Security Companies?

Recently we have been taking a closer look at how website security services are marketed and how they provide what seem like they should be warning signs as to the reality that the services don’t actually provide real security. We ran into another example involving Sucuri, which also involves an odd tag line.

Here was an ad form that showed up in search results while we were looking into for some information for another recent post on this blog:

The tagline there is “Real People, Real Security”. The first part of that is odd, do they believe other website security companies employ unreal people? The second part of that though is more problematic, since Sucuri doesn’t provide real security. That is something that is hinted at by what else is mentioned in the ad. If they could provide real security then websites using their services wouldn’t be getting malware on them that needs to be cleaned, much less repeatedly, and yet one of the things they are touting in that ad is that they provide “Unlimited Malware Cleanup”.

As we noted recently, Sucuri doesn’t present evidence, much less from evidence from independent testing, that their service is actually effective at protecting websites. So it would seem either they don’t know if they provide real security or they know they don’t provide real security, as we assume if they were actually measuring or testing to see if they provide real security they would tout the results if they were good.

There is plenty of reason to believe they don’t provide real security since as we also noted recently, it can be incredibly easy to bypass a critical piece of Sucuri’s offering, their website application firewall (WAF).

As we also noted recently, getting unlimited cleanups from Sucuri isn’t necessarily all that useful since we were recently brought in to deal with a website where Sucuri was repeatedly doing incomplete cleanups that didn’t resolve a hack.

It also worth noting that while Sucuri has real people (again, who wouldn’t?), what is important is if they competent and what we have seen doesn’t point in that direction. For example, just about a year ago SiteLock was telling one of their customers that their website was clean when it seems to us that someone that hasn’t basic competency in the field would have realized that wasn’t true and the employee(s) failed to spot malicious code that we easily found on the website.

That SquareSpace Websites Can Be Hacked Seems Like It Should Have Been the Focus of This Story

We don’t think too highly of the current state of security journalism, so we were not surprised to see a journalist covering a situation where what seems to be the significant and newsworthy element was not the focus of their article.

Today, Ars Technica has a story headlined “Thousands of hacked websites are infecting visitors with malware“. That doesn’t seem all that newsworthy. The sub-headline hints at something possibly newsworthy, “Unusually advanced campaign infects people visiting a variety of poorly secured sites.” Nothing in the article though seems to back that up; here is part of what that seems to refer to:

To escape detection, the attackers fingerprint potential targets to ensure, among other things, that the fake update notifications are served to a single IP address no more than once. Another testament to the attackers’ resourcefulness: the update templates are hosted on hacked websites, while the carefully selected targets who fall for the scam download a malicious JavaScript file from DropBox. The JavaScript further checks potential marks for virtual machines and sandboxes before delivering its final payload. The resulting executable file is signed by an operating-system-trusted digital certificate that further gives the fake notifications the appearance of legitimacy.

To us that sounds like some rather common stuff.

One of These is Not Like the Others

Another part of the story did stand out to us though:

The campaign, which has been running for at least four months, is able to compromise websites running a variety of content management systems, including WordPress, Joomla, and SquareSpace.

Lumping SquareSpace in with WordPress and Joomla seems rather odd since SquareSpace is hosted solution and the other two are software that people can install on any hosting. There is certainly a belief that SquareSpace is secure in a way that those solutions are not. For example, when doing a search on Twitter for “squarespace hacked” here are some of the top results:

https://twitter.com/mechaghost/status/979373780458876930

https://twitter.com/DesertDwellerD/status/950095157411500032

https://twitter.com/HeshamMegid/status/941650745606230016

https://twitter.com/pepironalds/status/889314095152807936

How Would a SquareSpace Website Get Hacked?

Considering how often we have seen false information being reported by security journalists, the claim that SquareSpace websites were hacked wasn’t necessarily true, so we went to look closer into that. An explanation from a SquareSpace customer as how their website was hacked, apparently as part of the campaign discussed in the Ars Technica article, is as follows:

Customer notified us that our site may be hacked. Sure enough I went to it and noticed it basically redirected me to a full page “your version of chrome needs updating” which looked super fake, and then Norton caught a download saying Chrome_67.9.17.js will harm your computer, do you want it keep it anyways.

So i login to the admin panel and in the GIT HISTORY it shows that one of my users which has never even logged in before, has sent an upload: site-bundle.js last week, along with some other big list of files

How do I go about doing anything about this? I’m not used to squarespace. In the old days I’d just login to my FTP and start navigating to the files in question. But I have no clue with this stuff.

It sounds like someone’s login credentials were compromised. That is something that is platform independent, which seems like a good reminder that the focus on the software used on hacked websites can be misplaced since websites can be hacked for a variety of reason outside the control of the software. That makes journalists usual lack of concern on how websites were hacked so problematic, as a lot of people come away with a belief that certain software is insecure in a way it isn’t. That can lead to people being less secure as they can come away with a belief that software that is actually more secure than other software is less secure, due to poor security coverage.

As to whether SquareSpace is better able to handle this situation as hosted solution, one thing we ran across while looking into this seemed less than reassuring. In a help article titled, ‘Google says “This site may be hacked”‘ they write the following:

Google applies this message to sites when they notice something that seems suspicious, which can include normal content, especially if it has external text formatting.

This means that the message was most likely triggered by content you added to your site, not by hackers. You can use Google Search Console to figure out what’s causing the message and remove it.

Squarespace offers free SSL certificates to provide a secure connection for visitors. We use many other methods to protect our customers, including regular security scans  and industry-developed and proprietary tools to guard against potential intruders, DDoS attacks, and other vulnerabilities.

We really can’t figure what the relevance of them providing secured connections (which involved more than just SSL certificates) to visitors of websites would have to do with the issue they are discussing there.

StackPath’s CDN/WAF JavaScript Page Lead to Belief That Website Was Hacked and Serving Malware

When it comes to why website security is in such bad shape, one issue that we have a hard time understanding is why so many people would use security services that are not marketed with evidence, much less evidence from independent testing, that they are actually effective at providing security they claim to provide. It would seem that people would want some assurance that what they are paying for works, but that doesn’t appear to be the case as many people use them and we have yet to run across one company providing a service that makes a general claim that it will protect websites that is backed with evidence. At the same time we have seen plenty of evidence from various sources that indicates that these services at best provide limited protection.

One of the most serious implications of all that is that a lot of money is going to companies that are not doing much in terms of improving security and in all likelihood if that same money was going to companies that were actually improving security then security would be in much better shape than it is now even for those not using any service and it would be getting even better from there.

Another implication of that we have been running into quite a bit recently, is that those security services cause all sorts of complications for those using them without them getting the security benefit that should be the tradeoff for that. We recently had someone we were working with that had a security service on their website that made it harder to do something that would actually improve the security of the website and was blocking users from taking basic actions. At the same time, any protection the service could actually provide for their website could be easily bypassed.

Another recent incident involved someone thinking that their website contained malware due to a recently added content delivery network (CDN)/web application firewall (WAF) service provided by a company named StackPath, which lead to them contacting us to see about getting it cleaned up. If they had contacted a less scrupulous company that could have lead to them spending more money on a cleanup service they didn’t really need.

Before we get in to more detail on that part of this, we should point out that StackPath is yet another security company that doesn’t promote their service with any evidence that is effective, as can be seen by visiting the page for their WAF. What seems even more telling is one of the company’s most recent blog posts, in which the CEO (who is a lawyer, not a security specialist) touts how many customers they have added and how much revenue they are bringing in, but nothing about actually providing security or improving security. Another part of that post is rather odd:

  • Our VPN business is on fire! We have increased our consumer VPN business 100% year after year and signed exclusive enterprise VPN partnerships, such as the recent agreement with Eero.

A VPN services seems to be unrelated to how the company otherwise promotes what it does and that service seem to go otherwise unmentioned on their website, which makes us wonder if this company is just sort of thrown together and that seems like an indication that they might not be a company that has the capability to provide good security.

This Looks Like Malware

What lead the person to believe that they might have malware on their website and then contact us was that they started seeing requests for URLs like this:

/index.php?_route_=sbbi/&sbbpg=sbbShell&gprid=cj&sbbgs=h436dbc8688a162192e9854e39ab7c45df61&ddl=2

The website was OpenCart based, so some of that URL format looks to based on how URLs for that sofrware are formatted. On other websites using the same services they might look different, here is another example:

/sbbi/?sbbpg=sbbShell&gprid=IA&sbbgs=&ddl=17785633

In looking into this we originally found a reference to this be connected to a CDN. In later looking into things further it was a bit confusing as to who might behind this, which seems to be due to multiple corporate changes. The “sbb” part of that looks to refer to SiteBlackBox, which renamed itself to FireBlade and then was acquired by Stackpath.

What gets served in those URLs for a short time is something that looks like this:

<html lang=”en”> <head> <title>env</title> <meta http-equiv=”Content-Type” content=”text/html;charset=UTF-8″> <meta name=”robots” content=”noindex, nofollow”> </head> <body> <script type=”text/javascript”> window.parent.sbrmp=true;var _0x1d10=[“\x64\x6F\x63\x75\x6D\x65\x6E\x74”, “\x65”, “\x6D\x6F\x76”, “\x6F”, “\x70\x61\x72\x65\x6E\x74”, “\x39”, “\x6D\x6F\x75\x73”, “\x6E”, “\x61\x64\x64\x45\x76\x65\x6E\x74\x4C\x69\x73\x74\x65\x6E\x65\x72”, “\x67\x65\x74\x44\x61\x74\x65”, “\x73\x65\x74\x44\x61\x74\x65”, “”, “\x74\x6F\x47\x4D\x54\x53\x74\x72\x69\x6E\x67”, “\x63\x6F\x6F\x6B\x69\x65”, “\x3D”, “\x3B\x65\x78\x70\x69\x72\x65\x73\x3D”, “\x67\x65\x74”, “\x67\x65\x74\x45\x6C\x65\x6D\x65\x6E\x74\x42\x79\x49\x64”, “\x61\x74\x74\x61\x63\x68\x45\x76\x65\x6E\x74”, “\x69\x5F\x37\x32\x36\x32\x33\x65\x76”, “\x72\x65\x6D\x6F\x76\x65\x45\x76\x65\x6E\x74\x4C\x69\x73\x74\x65\x6E\x65\x72”, “\x64\x65\x74\x61\x63\x68\x45\x76\x65\x6E\x74”];function mark(){return ancestor[_0x1d10[0]];};var txte=_0x1d10[1];var cnt=0;function MouseMove(_0xa880x5){cnt++;if(isFieldIntact()){i_72623ev9=getFrosen();hideOWL(i_72623ev9);stop();};};var eve2=_0x1d10[2];var txto=_0x1d10[3];var ancestor=markPointer();function markPointer(){return window[_0x1d10[4]];};var lie=false;var selecedRound=_0x1d10[5];var eve1=_0x1d10[6];var nchar=_0x1d10[7];function iseventlistener(_0xa880xf){return _0xa880xf[_0x1d10[8]];};function isFieldIntact(){if(isattachevent(mark())){if(cnt > 1){return true;}else{return lie;};};return true;};function hideOWL(_0xa880x12){var _0xa880x13=new Date();_0xa880x13[_0x1d10[10]](_0xa880x13[_0x1d10[9]]()+1);var _0xa880x14=_0x1d10[11]+nullRound+selecedRound+iseequal+escape(i_72623ev9)+(nvrborn(1)? noone : killhim)+_0xa880x13[_0x1d10[12]]();mark()[_0x1d10[13]]=_0xa880x14;};function getFrosen(){return 75;};function start(){if(mark()){processstuff(mark(), eve1+txte+eve2+txte, MouseMove);};};var iseequal=_0x1d10[14];var killhim=_0x1d10[15];function testWhc(){return document[_0x1d10[17]](_0x1d10[16]);};function processstuff(_0xa880x1b, _0xa880x1c, _0xa880x1d){if(iseventlistener(_0xa880x1b)){_0xa880x1b[_0x1d10[8]](_0xa880x1c, _0xa880x1d, lie);}else{if(isattachevent(_0xa880x1b)){_0xa880x1b[_0x1d10[18]](txto+nchar+_0xa880x1c, _0xa880x1d);};};};var noone=_0x1d10[11];function nvrborn(_0xa880x20){return(_0xa880x20==null);};var i_72623ev9;var nullRound=_0x1d10[19];function stop(){if(mark()){unprocessstuff(mark(), eve1+txte+eve2+txte, MouseMove);};if(testWhc()){alert(mark()[_0x1d10[13]]);};};function isattachevent(_0xa880xf){return _0xa880xf[_0x1d10[18]];};function unprocessstuff(_0xa880x1b, _0xa880x1d, _0xa880x1c){if(iseventlistener(_0xa880x1b)){_0xa880x1b[_0x1d10[20]](_0xa880x1d, _0xa880x1c, lie);}else{if(isattachevent(_0xa880x1b)){_0xa880x1b[_0x1d10[21]](txto+nchar+_0xa880x1d, _0xa880x1c);};};};start();</script>;</body> </html>

It isn’t all that surprising that would be seen as being malicious since it has multiple layers of obfuscation and nothing that identifies what it is related to.

One of those layers of obfuscation is an array containing hex encoded values. Converting those to alphanumeric characters leads to it looking like this:

<html lang=”en”> <head> <title>env</title> <meta http-equiv=”Content-Type” content=”text/html;charset=UTF-8″> <meta name=”robots” content=”noindex, nofollow”> </head> <body> <script type=”text/javascript”> window.parent.sbrmp=true;var _0x1d10=[“document”, “e”, “mov”, “o”, “parent”, “9”, “mous”, “n”, “addEventListener”, “getDate”, “setDate”, “”, “toGMTString”, “cookie”, “=”, “;expires=”, “get”, “getElementById”, “attachEvent”, “i_72623ev”, “removeEventListener”, “detachEvent”];function mark(){return ancestor[_0x1d10[0]];};var txte=_0x1d10[1];var cnt=0;function MouseMove(_0xa880x5){cnt++;if(isFieldIntact()){i_72623ev9=getFrosen();hideOWL(i_72623ev9);stop();};};var eve2=_0x1d10[2];var txto=_0x1d10[3];var ancestor=markPointer();function markPointer(){return window[_0x1d10[4]];};var lie=false;var selecedRound=_0x1d10[5];var eve1=_0x1d10[6];var nchar=_0x1d10[7];function iseventlistener(_0xa880xf){return _0xa880xf[_0x1d10[8]];};function isFieldIntact(){if(isattachevent(mark())){if(cnt > 1){return true;}else{return lie;};};return true;};function hideOWL(_0xa880x12){var _0xa880x13=new Date();_0xa880x13[_0x1d10[10]](_0xa880x13[_0x1d10[9]]()+1);var _0xa880x14=_0x1d10[11]+nullRound+selecedRound+iseequal+escape(i_72623ev9)+(nvrborn(1)? noone : killhim)+_0xa880x13[_0x1d10[12]]();mark()[_0x1d10[13]]=_0xa880x14;};function getFrosen(){return 75;};function start(){if(mark()){processstuff(mark(), eve1+txte+eve2+txte, MouseMove);};};var iseequal=_0x1d10[14];var killhim=_0x1d10[15];function testWhc(){return document[_0x1d10[17]](_0x1d10[16]);};function processstuff(_0xa880x1b, _0xa880x1c, _0xa880x1d){if(iseventlistener(_0xa880x1b)){_0xa880x1b[_0x1d10[8]](_0xa880x1c, _0xa880x1d, lie);}else{if(isattachevent(_0xa880x1b)){_0xa880x1b[_0x1d10[18]](txto+nchar+_0xa880x1c, _0xa880x1d);};};};var noone=_0x1d10[11];function nvrborn(_0xa880x20){return(_0xa880x20==null);};var i_72623ev9;var nullRound=_0x1d10[19];function stop(){if(mark()){unprocessstuff(mark(), eve1+txte+eve2+txte, MouseMove);};if(testWhc()){alert(mark()[_0x1d10[13]]);};};function isattachevent(_0xa880xf){return _0xa880xf[_0x1d10[18]];};function unprocessstuff(_0xa880x1b, _0xa880x1d, _0xa880x1c){if(iseventlistener(_0xa880x1b)){_0xa880x1b[_0x1d10[20]](_0xa880x1d, _0xa880x1c, lie);}else{if(isattachevent(_0xa880x1b)){_0xa880x1b[_0x1d10[21]](txto+nchar+_0xa880x1d, _0xa880x1c);};};};start();</script>;</body> </html>

Placing those array values into the code below it gets you this:

<html lang=”en”> <head> <title>env</title> <meta http-equiv=”Content-Type” content=”text/html;charset=UTF-8″> <meta name=”robots” content=”noindex, nofollow”> </head> <body> <script type=”text/javascript”> window.parent.sbrmp=true;var _0x1d10=[“document”, “e”, “mov”, “o”, “parent”, “9”, “mous”, “n”, “addEventListener”, “getDate”, “setDate”, “”, “toGMTString”, “cookie”, “=”, “;expires=”, “get”, “getElementById”, “attachEvent”, “i_72623ev”, “removeEventListener”, “detachEvent”];function mark(){return ancestor[document];};var txte=e;var cnt=0;function MouseMove(_0xa880x5){cnt++;if(isFieldIntact()){i_72623ev9=getFrosen();hideOWL(i_72623ev9);stop();};};var eve2=mov;var txto=o;var ancestor=markPointer();function markPointer(){return window[parent];};var lie=false;var selecedRound=9;var eve1=mous;var nchar=n;function iseventlistener(_0xa880xf){return _0xa880xf[addEventListener];};function isFieldIntact(){if(isattachevent(mark())){if(cnt > 1){return true;}else{return lie;};};return true;};function hideOWL(_0xa880x12){var _0xa880x13=new Date();_0xa880x13[setDate](_0xa880x13[getDate]()+1);var _0xa880x14=+nullRound+selecedRound+iseequal+escape(i_72623ev9)+(nvrborn(1)? noone : killhim)+_0xa880x13[toGMTString]();mark()[cookie]=_0xa880x14;};function getFrosen(){return 75;};function start(){if(mark()){processstuff(mark(), eve1+txte+eve2+txte, MouseMove);};};var iseequal==;var killhim=;expires=;function testWhc(){return document[getElementById](get);};function processstuff(_0xa880x1b, _0xa880x1c, _0xa880x1d){if(iseventlistener(_0xa880x1b)){_0xa880x1b[addEventListener](_0xa880x1c, _0xa880x1d, lie);}else{if(isattachevent(_0xa880x1b)){_0xa880x1b[attachEvent](txto+nchar+_0xa880x1c, _0xa880x1d);};};};var noone=;function nvrborn(_0xa880x20){return(_0xa880x20==null);};var i_72623ev9;var nullRound=i_72623ev;function stop(){if(mark()){unprocessstuff(mark(), eve1+txte+eve2+txte, MouseMove);};if(testWhc()){alert(mark()[cookie]);};};function isattachevent(_0xa880xf){return _0xa880xf[attachEvent];};function unprocessstuff(_0xa880x1b, _0xa880x1d, _0xa880x1c){if(iseventlistener(_0xa880x1b)){_0xa880x1b[removeEventListener](_0xa880x1d, _0xa880x1c, lie);}else{if(isattachevent(_0xa880x1b)){detachEvent](txto+nchar+_0xa880x1d, _0xa880x1c);};};};start();</script>;</body> </html>

There would still be several steps to fully make that easily human readable, but based on that, it looks like code try to detecting if a human is making a requests and setting a cookie based on that. It isn’t clear what the purpose of obfuscating it is, since someone trying to evade the protection provided by that likely wouldn’t be hindered in a serious way, but at the same time it can cause problems like the one that lead to us coming in to contact with it.