White Fir Design Blog

A Nexus of Insecurity Between EIG, SiteLock, and MOJO Marketplace

Last year as we started hearing and seeing more and more complaints about the web security SiteLock one thing we wondered was why would web hosting companies continue to partner with a company that was harming their reputation. The answer is in part that they get a lot of money from SiteLock, the Endurance International Group (EIG) has disclosed to investors that they get 55 of the revenue from SiteLock services through their partnership. When you are talking about $300 for a hack cleanup or $100 a month for a protection service, their cut of that could easily be more than they are getting paid by the customer for the service they are actually providing (without the costs that come with actually providing something).

That wasn’t the only explanation for that particular partnership, as turns out that the majority owners of SiteLock are also the CEO and a board member of EIG. While EIG isn’t all the well known by that name, they provide web hosting under a number of well known brands including A Small Orange, Bluehost, FatCow, HostGator, iPage, IPOWER, JustHost and quite a few others.

Web hosts can play an important role in keeping websites secure. They have a responsibility to keep the things in their power secure and they can also do things that help their customers do their part. The type of partnership that SiteLock has with EIG could influence EIG to not take the steps they could to keep websites secure since they can potentially make so much money off websites they host getting hacked. While we would think that might impact them doing extra things to help their customers, it turns out that EIG is not doing something that is their responsibility.

We are currently working on a cleanup of a hacked website hosted with JustHost, where JustHost and SiteLock have pointed to an outdated Joomla installation as being a weakness. While looking around at things we found that JustHost is currently offering to install that version of Joomla, despite it having not been supported for over two years.

From the JustHost cPanel control panel clicking the One-Click Installs button took us to https://www.mojomarketplace.com/scripts. The company behind that website, MOJO Marketplace, is another EIG company, which among other things provides the ability to install various software on websites. Looking over that page we found that not only were they offering to install the version of Joomla, 2.5.28, that JustHost and SiteLock were pointing to as being a weakness, but they are offering plenty of other outdated and insecure software. Below we have highlighted some of those.

If we were not already well aware of what SiteLock is really about, we would asking why SiteLock would be partnered with a web hosting company putting their customer at risk like this. It is worth noting that as far as we are aware none of SiteLock’s protection services include updating software, despite that being an important measure (and them seeming to be aware of the risk of outdated software).

Joomla

First up MOJO Marketplace is still offering Joomla 2.5.x despite that reaching end of life (EOL) on December 31st, 2014.

The next release of 3.x, 3.6.5, was released on December 13 of last year and included security fixes.

Drupal

Not only has Drupal 6 been EOL over year ago, but there were five security updates after 6.33: 6.34, 6.35, 6.36, 6.37 and 6.38.

The next release of Drupal 7, 7.44, was released 11 months ago. Not only did that include security fixes, but so did the subsequent 7.52.

The next release of Drupal 8, 8.1.1 was released a year ago. Subsequent to that there have three releases with security fixes: 8.1.3 8.1.7, and 8.3.1.

Magento

That version is two years out of date, with 1.9.1.1 being released in May, 2015. That version included security fixes, as did 7 subsequent versions: 1.9.2.0, 1.9.2.1, 1.9.2.2, 1.9.2.3, 1.9.3.0, 1.9.3.1, and 1.9.3.2.

PrestaShop

The PrestaShop version is more than a year out of date, 1.6.1.5 was released last April, and a security fix was released in the subsequent 1.6.1.12.

Moodle

Moodle 3.0.x was replaced as the most recent major version of Moodle just about a year ago. Support for 3.0.x ended a week ago. Not surprisingly the version of 3.0.x being offered isn’t recent, with the next version 3.0.5, being released 11 months ago. That version included security fixes as well five subsequent releases: 3.0.6, 3.0.7, 3.0.8, 3.0.9, and 3.0.10.

MediaWiki

MOJO Marketplace isn’t offering the latest major version of MediaWiki, but at least you could explain providing 1.23.x as it long term support release in they were keeping it up to date. But as with the other software they are not doing that. The next release of 1.23.x, 1.23.7, was released in November of 2014. That was a security release, as were 8 subsequent releases: 1.23.8, 1.23.9, 1.23.10, 1.23.11, 1.23.12, 1.23.14, 1.23.15, and 1.23.16. Version 1.23.x reaches EOL this month.

SiteLock Unintentionally Provides Reminder That They Don’t Keep WordPress Websites Secure

One of our long time concerns with the security industry is that that their efforts to sell more advanced security measures make it less likely that people will take more basic security measures. Right now even many security companies are not doing the basics when it comes to security and as a hacking of one of Trend Micro’s websites earlier this year showed, more advanced security measures are not necessarily even as effective as the basics.

Another example of this comes from a recent case study from the security company SiteLock where they highlight a website that is using a version of a WordPress plugin with known vulnerabilities while they falsely claim one of their services is insuring the website is “safe and secure at all times.”

The Unmentioned Business Relationship

Before we get the details of that it is worth noting that SiteLock isn’t being upfront about how they came to be involved with the website mentioned in the case study, which seems important when you consider they are leaving it insecure.

Here is their explanation:

One day Kasal unexpectedly received an email from his hosting provider alerting him that his blog had been infected with malware. Due to the stealthy nature of the attack, there were no obvious signs that his blog had been compromised. “I was unaware that my site had been hacked and at a total loss as to how to find or fix the problem,” he recounts.

Kasal’s hosting provider informed him that his blog would be taken offline unless he removed the malicious code that was inserted on his website. His host recommended he contact SiteLock_® to remove the malware and help prevent future attacks.

What they don’t mention is who the web host is or why they recommended SiteLock. Looking at the DNS records the web host is IPOWER. That is one of the many brands names that the Endurance International Group (EIG) does business under. That is rather important in explaining the recommendation, as it turns out that SiteLock’s owners are the CEO and a board member of the company and the company has disclosed that they get 55 percent of revenue coming from the sales of SiteLock’s services through a partnership they have. If there were not those connections we doubt the web host would be recommending SiteLock, considering the many problems with SiteLock (one the reoccurring complaints is that they sell protection services that don’t actually protect websites).

SiteLock Doesn’t Detect Vulnerabilities

The case study doesn’t go in to details as to how the website was cleaned, but no mention was made of doing two important parts of cleanup, making the website secure as possible (which usually mainly involves getting the software up to date) and trying to determine how the website was hacked. Based on our own experience being brought in after them to re-clean websites and everything else we have seen, it is likely those things were not done.

Without knowing what caused the website to be hacked you can’t say what would have prevented it from happening, but we can be fairly sure that SiteLock’s idea of a “proactive approach” isn’t the best way to secure the website going forward:

Once his website was clean, Kasal decided to take a proactive approach to website security by implementing SiteLock_® SMART^™, a daily scanner to help protect his blog from future attacks. SMART provides continuous file scanning to detect vulnerabilities and malware, including backdoor files and malicious code. If malware is identified, it is automatically removed and Kasal is immediately notified.

SMART also provides a full website analysis of each scan, ensuring Kasal’s site is safe and secure at all times.

It is strange that they are describing that as being proactive, since it is clearly reactive. If you are detecting malware on a website, it means it has been hacked and it wasn’t protected. There are further problems with that approach, like the inability to undo the compromise of a website’s data and that SiteLock has a limited ability to remove malicious code automatically (when they are even successful at detecting it).

A quick look at the website shows that is a couple of vulnerabilities that SiteLock must not have detected. Looking at the source code of the website’s pages you scan see that the version 2.9.45 of the plugin WordPress Download Manager is in use:

The plugin is several versions and a couple months out of date, with the next version, 2.9.46, having been released on April 17. That version fixed two vulnerabilities in the plugin, which is somewhat obliquely mentioned in the changelog with these two entries:

Added nonce check with settings form
Blocked unwanted file type upload

This is a perfect example of where doing the basics would be better, because if the website’s owner was keeping their plugins up to date they would actually be protected against those vulnerabilities. They wouldn’t even have to take manual action do that as there are a number of options available, including our Automatic Plugin Updates plugin, to have plugin updates happen automatically.

Keeping plugins up to date is free, unlike SiteLock’s service, but would another paid service actual have warned about those vulnerabilities? We know of one, our Plugin Vulnerabilities service, which warned about both vulnerabilities even before they were fixed (we also were the ones that discovered one of the vulnerabilities).

One last thing to note is that instead of SiteLock being able to tout that it actually detected those vulnerabilities or any other issue, they instead point to the number items checked:

SiteLock captured billkasal.com’s SMART scan results from a 30-day time frame. During the given 30 days, over 170,000 files, 120,000 links and 15,000 pages were thoroughly scanned for malware.

Sheer numbers clearly don’t equal quality.

Site5 Referring to SiteLock as a Third Party Seems Disingenuous At Best

As we have looked closer at the web security company SiteLock over the last year one of the things that has stuck out is how their web hosting partners are not being upfront about the nature of their partnership with SiteLock.

As we have mentioned before when it comes to one of their biggest web hosting partners, Endurance International Group (EIG), the company has disclosed to investors that SiteLock not only pays them more than half fees for services sold through their partnership, but the CEO and a board of EIG also are the major owners of SiteLock. Those seem like things that should be disclosed to their customers as well since there is an obvious potential for conflict of interest with that relationship, for which their customers should be aware of when considering their recommendations regarding SiteLock. Instead we have found previously that one EIG brand, HostGator, wouldn’t even publicly acknowledge those connections. In that instance they referred to SiteLock simply as a “trusted partner”.

We are frequently contacted by people that have had their web host shut down access to the website based on a claim that the website is hacked and recommend that they hire SiteLock to handle resolve the situation. While in many instances the websites are in fact hacked, there are some serious issues with false claims that websites are hacked. So when we are contacted in those situations we want to find out what evidence there is that the website is hacked first, so that we can double check if the website is in fact hacked before starting on a cleanup. Through that we were recently forwarded a report from the web host Site5 (about a website that was actually hacked), which referred to SiteLock is this way:

If you don’t feel comfortable removing the infected files yourself, we recommend contacting a third party professional who can assist with removing malware, such as SiteLock.

Considering that Site5 has been part of EIG for nearly a year and the connection between EIG and SiteLock, calling them a third party, while maybe technically accurate, clearly doesn’t provide their customers a honest understanding of the connection between the companies. (Not surprisingly from everything else we have seen related to EIG, the quality of Site5 service and support looks to have gone downhill since becoming part of EIG, just look at the number of negative reviews they have received on their BBB page since the purchase).

There Should Need to Be Evidence That Security Measures Are Effective, Not Ineffective

When it comes to security advice for websites, there is a nearly endless supply. What there decidedly isn’t is an abundance of is testing or other evidence presented that the measures mentioned in that advice are effective.

That seems particular acute when it comes to advice to use paid security products and services, for which we have frequently see bold claims about their effectiveness in their marketing materials, but we have seen almost no evidence presented as to their effectiveness (when it has, it hasn’t been very reliable, for example, one company claimed to have had independent testing done, when the testing decidedly was not independent).

That brings us to a couple of recent comments on one of the posts on the blog for our Plugin Vulnerabilities service.

We had noted that a lot what is supposed to provide protection doesn’t actual do that and cited our testing to see if WordPress security plugins could protect against real vulnerabilities in other plugins:

A lot of what is portrayed as protecting, including a lot of security hardening, doesn’t actually provide any protection. There is even a term for that type of thing, security theater. That is part of the reason we started doing testing of security plugins against real vulnerabilities, to show what, if any, protection they provide. So far BulletProof Security hasn’t provided any, which is what brought this up in the first place.

The response we got to that was this:

This is a big claim and it is one you would need to back up with some proof, especially given that so many people rely on them to protect their websites. Please point me to articles which back these statements. As a typical web dev customer who spends time hardening sites, and promoting a secure WP service, I’m unconvinced about your claims.

This seems to us to be backwards, the onus should be on proving something actual provides protection. Just because a lot of people are doing something that doesn’t mean that is effective, especially since a lot of people are following advice from others that don’t actual have the experience needed to be a reliable source.

Now in reality we have also written plenty about this sort of thing from years ago when we wrote about how hiding the WordPress version isn’t an effective security measure (this seems to have dropped off as claimed important security step) to the currently very popular, but false, claims that there are a lot of attempts to brute force WordPress admin passwords (which are pushed by security companies that then tell you their product or service is the solution). That second item is also a good example of why evidence is important, because we were actually able to disprove the claim based on the evidence that security companies were presenting as supporting it.

SC Magazine Is Arming Their Readers With False Information

When it comes to the poor state of security these days, two of the important players to get us where we are, are security companies and the security journalists that are covering them. Security companies have shown for years that don’t know and or care much about security. You would think that with the high profile nature of security today and how bad things are, that journalist would be covering that aspect. It wouldn’t take digging very deep to find lots of material. Instead when it comes to journalists covering security they seem to be more interested parroting the claims of security companies instead of doing any actual journalism.

Take the company SiteLock, which you only have to look what Google suggests when you do a search on them to know about their well earned reputation:

Despite that, instead of any coverage of how they and their web hosting partners take advantage of people, journalists would rather parrot false claims they make. Last week looked at a recent example where journalists hadn’t bothered to do any fact checking before running with a SiteLock claim of a trending threat, which if they had likely would have warned them about the veracity of their claims.

Earlier this week we looked at another one of SiteLock’s claims of trending threat, which once again was based on falsehoods. Most notable claiming that a backdoor script with incredibly well known malicious code was not widely recognized:

The code within the shell used to gain the initial foothold is currently listed in the SiteLock malware database, but does not appear to be widely recognized as a threat by many website security vendors at this time. You may use the code snippet below to manually add the shell to your security mechanisms.

In the case of both of SiteLock’s claimed trending threats SC Magazine provided parroted coverage. With the more recent article we left a comment that pointed to a number of the problems in their reporting, but so far it hasn’t been approved, so anyone reading the article is left without a possible counterpoint to the inaccurate information in it.

Providing their readers with false information isn’t in line with how SC Magazine describes themselves in the footer of their website:

SC Media arms cybersecurity professionals with the in-depth, unbiased business and technical information they need to tackle the countless security challenges they face and establish risk management and compliance postures that underpin overall business strategies.

To give some idea of the problems with just that one article, let’s take a look at a few issues with the article.

Here is paragraph that has the false claim that code stays hidden from security programs:

The code manages to stay hidden from many security programs, Kipp noted, suggesting cybersecurity teams manually add this piece of code to their security programs so it can identify an attack.

SiteLock didn’t provide any evidence to back this up and from our years of experience we can say that it either isn’t true or the web security industry is in much, much worse shape than even we think it is in. What is also worth noting there is the link in that sentence, which goes to https://wpdistrict.sitelock.com/products/?prod=malwareScanning. Looking at that you can probably tell that that page doesn’t actual contain any code, instead it is a sales page. It isn’t clear what they could have been intending to link to because there is no link to any code in SiteLock’s post.

The following paragraph refers to taking control of a computer, but the claimed threat involves taking over websites not computers:

The malware not only enables an attacker to obtain administrative control of a computer, but it also makes the computer’s information publicly available on the web. The reason for this is oddly practical, from the cybercriminals point of view.

SiteLock Services Don’t Update Web Software

We also found the final paragraphs of the article interesting:

Because the malware only goes after known issues with these CMS programs Kipp said it is imperative that those using this software are up to date with their security patches.

“This should really drive home the importance of patching your CMS platform to website owners. Automated campaigns like these are run on an ongoing basis, which attack websites on an almost indiscriminate basis. The majority of web attacks aren’t targeting websites based on their content or popularity, but based on their use of vulnerable outdated software. These are the low-hanging fruit of the web, he said.

First off SiteLock’s report makes no mention of the need to update software, but more importantly as far as we aware SiteLock’s security services don’t involve keeping software on a website up to date, as can be seen in a previous post we did specifically mentioning they don’t do that and one about websites they included in case studies that were running outdated software. That discrepancy between what they say is important here and what they are selling to their customers seems like something a journalist might want to ask them about.

It is also worth noting that SiteLock doesn’t cite any specific vulnerabilities being exploited, which would lead us, based on plenty of experience with that type of claim, to believe that they likely don’t know how the websites were being exploited. We have often seen outdated software blamed as the source of hacks in cases where the person making the claim hadn’t reviewed any evidence that would actually support the claim and in some cases where the software was actually being kept up to date.

A Security Service That Doesn’t Determine How a Hack Happened Isn’t Actually That Helpful

We are frequently brought in to re-clean hacked websites after another company had cleaned it and then it got hacked again. While the re-hacking is not always the fault of whoever did the first cleanup, we have found that companies doing those cleanups are cutting corners. The first thing that we ask after it is brought up that someone previously cleaned up the website, is if they determined how the website was hacked and gotten that fixed. If that hasn’t happened it obviously leaves open the possibility of the website being hacked again. The answer is almost universally that doing that never even came up. It shouldn’t be that way since trying to determine that is one of the three basic parts of a proper cleanup. So either these companies (we have heard it about a lot of different companies over the years) don’t know what they are doing or are intentionally cutting corners.

We recently ran across a reminder that the web security company SiteLock either doesn’t understand the importance of doing that or doesn’t want to have to do the work required to things properly, as they didn’t tell truth about needing to do this. In a thread on the WordPress support forum, which came up in our monitoring for discussions of vulnerabilities in WordPress plugins that we do for our Plugin Vulnerabilities service, a SiteLock customer had been notified their website had been hacked:

We signed up for SiteLock which was helpful and told us this morning that we had a malware warning for “defaced pages” – sure enough, the list they provided was full of similar material to the last one. This time it said “just for fun” and “hacked by GeNeRaL.” Since we’re on the latest version of WP, and we had updated our password to one of the long, random, extra-complex ones that WP suggests, I don’t know what to do to prevent this. I deleted all of the blog posts, but is there anything better we should be doing?

There are a lot of things that could be focused on there. The fact that they received a malware warning for “defaced pages”, despite that not being a malware issue (that lack of clarity is even more problematic when they are falsely claiming that a website has an issue identified by their scanner). The fact their customer either is not be able to or not feeling they can get in touch with the people they are paying to protect their website about a concern they have. But will focus on the claim that SiteLock was helpful despite clearly leaving this person unaware of what caused the issue, which is in fact the most important part here.

Before we get to that though, we have to mention an example of the poor quality responses from moderators when you post about security issues on the WordPress Support Forum in this thread. As is often the case this person did not get relevant advice from a moderator:

Take a deep breath and carefully follow this guide. When you’re done, you may want to implement some (if not all) of the recommended security measures.

If you’re unable to clean your site(s) successfully, there are reputable organizations that can clean your sites for you. Sucuri and Wordfence are a couple.

Not only did they not address the specifics of the poster question, they promoted two security companies. Neither of those companies are ones that we would refer to as reputable. We just had a post on Sucuri claiming one of their customers website that had malicious code to compromise credit card info entered on it was clean and recently had one on their scanner producing a rather bad false positive that lead to them claiming our website was defaced (we also frequently see moderator pointing to people to their poor quality scanner). With Wordfence, they don’t seem to understand the basics of security and spreads falsehoods about the security of WordPress. Why someone connected with WordPress would be promoting a company spreading falsehoods about the security of WordPress is as baffling as it is troubling.

The response from someone at SiteLock in the thread didn’t raise the need to determine how the website was hacked, instead they stated:

The bottom line is that you’re most likely in the clear regarding that particular incursion, but continuing to run malware scans on an ongoing basis is your best way to be certain.

Even if a malware scanner is good at what it does (and SiteLock’s doesn’t seem to be) from a technical perspective it simply cannot detect everything. Of course doing things right would increase SiteLock’s costs, whereas telling someone to continuing to use their service to have scans continue would make them more money.

The thread went on for a bit and ended with the person not being able to get in touch with someone at SiteLock that would actually determine how the website was hacked:

I tried to ask for you when I called, but it sounds like they couldn’t find you at the time. The rep I spoke with checked the site in question and said there are only 95 pages. Do you think it’s an issue with SiteLock not noticing it, or is it more likely that this more recent hack cropped up as a result of some other vulnerability (a plugin, theme, something else)?

Despite the service not doing what should be done they thought they had been helpful and were open to possibly giving more money to SiteLock:

We’ll most likely want to add on several other domains to this account and possibly upgrade. Thanks for your help!

Every time someone does something like that it hurts everybody because it helps bad security companies like SiteLock spread, which means that he needed improvements to security are less likely to happen because those companies keep pushing people away from focusing on the things that would actually improve security.

Web Security Company Cloudbric Running Outdated and Insecure Version of WordPress on Their Website

When it comes to improving the security websites one of the major roadblocks we see is that often the security industry is pushing people in the wrong direction, a direction they themselves are heading. Instead of focusing on security basics they are pushing people to more advanced solutions, which are not necessarily better than doing the basics. As an example of that take Trend Micro that decided instead of keeping WordPress up to date with security updates (which normally are applied automatically) they would try to use some solution to block attacks, which didn’t stop one of their websites being successfully attacked. Even after that, they didn’t update WordPress, which would have prevented any chances of the attack being successful in the first place.

The other day we came across Cloudbric, which “is a cloud-based web security service” when they helped to spread false web security information put out by SiteLock and the repeated by SC Magazine. We were curious as to what kind of web security company would be unaware that they were spreading information that was rather obviously false and went to take a look into them we found that they were also running an outdated version of WordPress on their website, while misleading people about what protects websites.

The company claims that 99 percent of websites are left unprotected, based on incorrect notion that active protection is the only protection:

As was the case with Trend Micro, active protection can actually fail to provide protection over passive protection. So the claim that “Hosting services and CMS do not actually protect individual websites.” isn’t true, as they do to varying levels.

Cloudbric seems to really believe the misleading information they are giving others as they are still running WordPress 4.2.2:

That version was superseded with the security update 4.2.3 back in July 2015. Normally that and the subsequent 4.2.x updates would have been applied automatically due to WordPress’ automatic background updates feature, so either Cloudbric disabled those or their server environment has an incompatibility with that (which they could help WordPress to resolve). After 4.2.3, they have missed the next 10 security updates: 4.2.4, 4.2.5, 4.2.6, 4.2.7, 4.2.8, 4.2.9, 4.2.10, 4.2.11, 4.2.12, 4.2.13.

You have to wonder if when Cloudbric says that “Most unprotected website operators feel that proper web protection is expensive or unnecessary.” that is based on their own feelings.

More Tolly Group Testing

One of the things we take a look at with companies providing security services that claim to provide protection is if they are providing real evidence to back up their claims (so far we haven’t seen one that provides that). With Cloudbric they claim their WAF provides “the most effective security”:

Penta Security’s web application firewall provides the most effective security. It was rated considerably higher than the widely known vendor Imperva’s technology. Cloudbric is known for higher performance and greater functionality than Incapsula. Sitelock and Sucuri are built on an open-source engine called Mod Security.

(They also claim to that SiteLock’s WAF is based on Mod Security, when in fact they actually reselling Incapsula’s service, so that make us suspicious as their claim about their service.)

That claim seems to rest on a report by the Tolly Group. If you follow our blog you might recall the test that they did for SiteLock, which would it would probably be accurate to describe as rigged, as SiteLock provided the samples that their product were supposed to be detecting in the test.

Looking in to the report for this company the same thing was true:

A collection of 1,000 attacks were used to test the effectiveness of each solution, in both default and maximum security settings. This was run multiple times to ensure accuracy. The attack set was a random subset of attacks collected by Penta from Exploit-DB, 1337 Inj3ct0r, SQL Injection Wiki, fuzzdb and other online security communities.

Unlike SiteLock, which correctly identified all the samples they provided as having been malicious in the test, this service missed 101 of the 1,000 of their chosen samples when using the services “maximum security settings”.

Sucuri Claimed Customer’s Website Was Clean Despite It Comprising Credit Card Info Entered on It

Back in June of 2012 we wrote a post mentioning that looking at false positives produced by a malware scanner would give an idea of the quality of the scanner. In that post we looked at a rather bad false positive from web security company Sucuri’s scanner. Moving forward nearly five years it is clear that Sucuri hasn’t improved the quality of their scanner as a month ago we looked at them falsely claiming our website was defaced because we have a page named “Hacked Website Cleanup”. When your scanner is that bad, it doesn’t seem all together surprising that it would manage to miss things that it should catch as well and a recent situation we were brought in to deal with confirmed that. But much worse, it also reconfirmed everything we have seen in the past that Sucuri is company that either really doesn’t have much clue about what they are doing or doesn’t care to do things right, and in this situation that lead to people’s credit card information being compromised.

A week after we wrote the post about Sucuri falsely labeling our website as being defaced we were contacted by someone with Magento website that was having credit card information entered on it compromised. Sucuri, who they had brought on while before to deal with the situation, was telling them that website was clean, despite the compromises continuing to happen. Since that claim that the website was clean was pretty clearly not true, the person behind the website was then looking for someone competent to properly resolve the situation.

If credit card information is being compromised when entered on a website, the default assumption should be that the website is hacked. About the only other possibility we can think of is if the payment processor is compromised (which is lot less likely). So upon believing it was clean, Sucuri should have realized they were missing something and figured out what they were doing wrong, but they didn’t.

One of the questions we asked about the situation right after being contacted was who is the payment processor, if it was a major one then the payment processor could be ruled out as the source. It was a major one.

At that point we assumed that code causing the credit card info must be well hidden seeing as Sucuri couldn’t find anything. But after getting the response about the payment processor, we did quick check of the website from the outside and we immediately ran across part of the problem. It wasn’t even detected using any highly advanced proprietary technology, but off the shelf tools.

What we noticed was that there was JavaScript being loaded from the domain adyenweb.com through this script tag:

That was clearly meant to look like it was loading some type of tracking code.

The code in the file being loaded from that was highly obfuscated (when we ran through a tool to deobfuscate it, all it could pull out is that the code was requesting another file that was an encryption library for JavaScript):

At that point, considering the code didn’t look legitimate, instead of spending a lot of time trying to get a more complete deobfuscation before moving forward, we did a few other quick checks to try to assess the legitimacy of the domain the code was being loaded from.

First, we tried to trace where the server the domain was hosted on was, but found that it traced back to Cloudflare, which could have pointed to this being legitimate or it could have been someone with malicious intentions protecting themselves through Cloudflare (which is apparently a fairly common thing).

Second, we looked at the domain name registration, which didn’t look all that suspicious, but the domain was only registered on March 17.

Finally we tried to take a look at the website, but we found that there was nothing served at http://adyenweb.com or http://www.adyenweb.com. There also was nothing that came up for it in a Google search.

At that point we could safely say that this was at least part of problem. At the same time we noticed that despite something fairly obviously malicious being on the website Sucuri was telling the public the opposite about the website, as the website had this badge claiming it was “Secured by Sucuri” at the bottom:

Clicking that brought up this:

Not only did they claim the website was clean, but that their service “provides peace of mind that the website is not infected”, despite that not being true.

After we got access to the logins, we found that script tag shown earlier was stored in Magento’s settings in the database (as shown from phpMyAdmin):

This turned out to not be the only fairly hard to miss portion of the hack that Sucuri missed. In the root directory of the website was the backdoor script that the hacker was using to take actions on the website. That was something that Sucuri should have noticed at multiple points. Those points being during a visual inspection of the filesystem (since you need to get an understanding of what all is part of the website when first assessing the situation), during the reviewing the website files for malicious code (it wasn’t something that was obfuscated in a way that would make detection difficult), and when reviewing the log files to try to determine the source of the hack. In looking at the logs we found that the backdoor script had most recently been accessed two days after adyenweb.com was registered.

The backdoor script looks like it might have been on the website for nearly a couple of years, so we were not able to say what was the source of that was, but continued reviewing of the logs files showed that after it was removed and the various logins changed the hacker no longer had access to the website. So getting this resolved was rather simple for a competent company, which this incident shows Sucuri is far from.

SiteLock Threat Intercept Falsely Claims That Widely Known Backdoor Code isn’t Recognized as a Threat

Last week we looked at the fact that web security company SiteLock’s recent claim of a trending threat had an obvious falsehood in it, which was that a malicious WordPress plugin was a forgery of legitimate plugin despite the supposed legitimate plugin not existing. The rest of their post on the issue lacked evidence to back up their claims and it seemed that the malicious plugin might be rather old and not a new trend. Unfortunately a number of security news source repeated their claims verbatim instead of doing any fact checking (with two of them we left comments on their posts mentioning that the legitimate plugin didn’t exist, but neither of them have approved our comment to show on the posts yet)

Based on that and everything else we have seen from SiteLock isn’t really surprising to see that they made an obviously false claim with their next claimed trend as well.

Before you even get to the contents of the post there already is something that looks us to be a good red-flag that the post isn’t something that should be taken seriously, it’s this graphic:

It reminds of the overused breaking news graphics on cable news, which seem to be used for things that don’t seem to qualify far too often.

The main portion of the post is a good example of the poor quality content put out by security companies. Frequently they will dress things up to make something trivial or in some cases made up, seem more serious. In this case with this infographic:

They even give the claimed trend a name (because trying to brand vulnerabilities was not enough).

At the heart of the claimed trending threat is that websites running outdated software can be hacked:

The vectors used to infect websites appear to be well-documented vulnerabilities in older versions of website platforms.

Which isn’t anything new. It is worth noting that SiteLock doesn’t cite any specific vulnerabilities, which would leave us to believe they don’t actual know the source of hacks. We have often found security companies and web hosts will claim that website have been hacked through outdated software based on zero evidence (in some cases we have seen this claimed when the software of the website was actually being kept up to date). From everything we have seen SiteLock usually doesn’t determine how websites are hacked when cleaning them up, despite that being one three main pieces of doing that correctly, which increases the chances that they don’t actually know in this instance either.

If there was something worth noting here it relates to the possible compromise of cPanel login credentials, not CMS credentials, through the hack. SiteLock make no direct mention of that, only mentioning to change the cPanel password if using that, which is another indication that SiteLock doesn’t have much security expertise and experience.

SiteLock Doesn’t Suggest Taking the Action to Prevent the Real Threat

The last section the post is what seems to be the real point of their post, to promote one of their products, which doesn’t actually fix the claimed root of this, which is outdated and vulnerable software. It starts this way:

Here’s what you need to do

As this trend both provides administrator-level control over the target website environment as well as publicly discloses credentials, action must be taken to counter both threats.

Since again, the important threat is the vulnerability being exploited to allow the hacker access to the website in the first place, not what could be done if it is exploited since that can be stopped from happening, you would expect the first action they suggest be to make sure the software on a website up to date, instead it is:

Run a malware scan to locate the presence of any shell files. (see: SiteLock Malware Scanners)

In fact updating the software on the website isn’t listed at all. Do they want websites to remain vulnerable to being hacked? It is worth noting that we are not aware of any SiteLock ongoing security services that include them keeping a website’s software up to date (not surprisingly we have seen numerous instances of their customers using those services getting hacked.)

False Claim

Finally let’s look at the false claim, which is this:

The code within the shell used to gain the initial foothold is currently listed in the SiteLock malware database, but does not appear to be widely recognized as a threat by many website security vendors at this time. You may use the code snippet below to manually add the shell to your security mechanisms.

Looking at the screenshot they provided of the backdoor script, there is a line code that would immediately stick out to anyone that regularly deals with hacked websites:

That would be this part “$default_action = ‘filesman'”. Looking back it looks like backdoor scripts with that line of code have been in existence at least since 2010.

The idea that the code wouldn’t be “widely recognized as a threat by many website security vendors at this time” indicates SiteLock is clueless, is lying, or thinks the rest of web security industry is even worse than them (which might explain their laughable claim to be the global leaders in website security). None of those possibilities is something that should be able to be said about a security company.

SiteLock Will Try To Sell You Services You Don’t Need and Can’t Use

Over the last year or so, as we have seen and heard more about the web security company SiteLock’s practices, it has become more clear that a lot of what they are doing can reasonably described as scamming. Take for example a recent issue brought up on the customer complaints section of their BBB page, which starts with the complainant being contacted by one of SiteLock’s sales people (who are commissioned, which will be relevant in a moment):

The… details are as follows: I spoke to someone back in October after Sitelock called me warning that I needed more security on my websites. Sitelock was very persistent, with an employee calling me and leaving messages daily until I finally agreed to speak with him. After being convinced that there was a danger to my domain during a very long conversation with one of the employees, I agreed to move forward although the price seemed outrageous, and was then passed on to the billing department.

All of this sounds like numerous other stories we have heard when people contact us after interacting with SiteLock (most of them have luckily avoided signing up for something from SiteLock before contacting us to get a second opinion) and we have read online. A legitimate security company wouldn’t keep calling someone like this, but a commissioned sales person is likely mainly interested in getting a commission, not in what a legitimate security company would do.

Based on that what comes next isn’t surprising, but it is interesting that others at SiteLock are clearly aware that something wrong is going on:

The woman at the billing department actually pointed out to me that my sites were hosted on Shopify, and therefor would not be eligable for Sitelock security as they were being hosted by Shopify’s own very protected servers and were actually not at risk in any way, nor could Sitelock be of use to me. She told me I did not need the service I was sold.

There is something quite wrong when the billing department seems to be more aware of whether some can use services than the sales people that are selling them, which gets back to the issue of scamming going on (the sales person gets a commission whether the service is used or not).

Unfortunately, that didn’t end their interaction with SiteLock:

I chose to believe that the original employee who called me telling me my sites were in danger was not intending anything dishonest, but that he didn’t realize where my sites were hosted and gave me the wrong information. I no longer think this was an honest mistake after being repeatedly charged. I told the woman in billing that, obviously, I agreed that I did not need to go through with the subscription, and it was cancelled. Since that time, I have been repeatedly billed, totalling $1023.99, and I’m sure I will again be billed next month as Sitelock has not responded to my requests for refunds and termination of any services.

This isn’t the first time we have heard of how hard SiteLock makes it to cancel services once they have gotten you signed up, which seems quite intentional at this point.

Part of SiteLock’s response to this is rather incredible:

We always put our customers first, and strive to deliver exceptional customer satisfaction.

Do they think that people will believe that selling a very expensive service that someone didn’t need based on what seem to be lies, is in anyway putting customers first?

It appears this customer was able to get the situation resolved to their satisfaction, so if you are in the same situation it looks like filing a complaint with the BBB could resolve the issue (if it does, please let us know in the comments section below). You should also make sure to leave a review there as well, so people looking into their service know what is really going on.