Bad Security

Another Reminder That People May Fail To Take Basic Security Measures While Doing More Advanced Ones

When it comes to what security companies do one of our major concerns is they tell people that need to take all sorts of advanced security measures while some many people are still failing to do the basics. Our main concern for that for some time was that people would feel overwhelmed and instead making sure they are doing the basics, they wouldn’t do anything. What we have seen more of recently is that people will do more advanced things instead of the basics, which can produce bad results, as was the case with one of security company Trend Micro’s websites getting hacked due to them failing to do one of the basics and relying on more an advanced measure that failed (even after they got hacked they didn’t take the more basic step).

Another example we ran across recently involved someone reporting that when trying to install plugin for checking for vulnerable WordPress plugins there was fatal error. The error was caused by the plugin trying to use a function that was introduced in WordPress 3.4, which was released nearly 5 years ago. That doesn’t seem like it should be a problem, but was in that case because the website they were trying to install it on was still running WordPress 3.2.1.

Why SiteLock’s Poor Cleanups Lead to Website Reinfections

If you follow our blog you will have seen us say before that we are often brought in to re-clean hacked websites after another has cleaned and then it hacked again. And as we have said before, while it isn’t always the fault of a company that did the a clean up that a website has gotten hacked again, what we have found is that in almost all the instance where we are brought in to re-clean websites the first company has cut corners. As one of three main components of a proper cleanup is trying to determine how the website was hacked and when we ask if the source of the hack was determine by the first company that answer is almost always that trying to determine that never even came up.

One of company that comes to mind as one that doesn’t do proper cleanups is SiteLock. As we seen for years they don’t upgrade the software on the website (which is large part of one of the other main components, getting the website secure as possible) and they don’t determine how the website was hacked.

So we were somewhat surprised to see a recent SiteLock had a post on their blog “Why Website Reinfections Happen”, which while written to get around the issue, is really a indictment of how SiteLock’s improper cleanups leaves websites vulnerable to being reinfected.

In the post they start out by explaining why websites get reinfected:

The short answer is that it’s most likely due to unresolved vulnerabilities. While it may seem like you’ve been singled out and targeted by some menacing hackers, most of the time that isn’t the case. The majority of website compromises are preceded by automated campaigns that locate websites vulnerable to a particular exploit the hacker wishes to employ.

That would dictate as part of the original cleanup you would want to resolve the vulnerability, so what does SiteLock claim are the causes of the vulnerabilities.

Up first is outdated software with vulnerabilities:

It is for this reason that we stress not only cleaning the website, but also patching all software and identifying and remediating all vulnerabilities present on the website.

While they stress this, their cleanup don’t actual involve updating the software and neither doing their ongoing security services. They do try to get to what they actual provide by saying this:

It is also advisable to take a more proactive approach in the future by utilizing a web application firewall (WAF) to protect your website.

The problem with this is using a WAF isn’t more proactive, instead it is reactive, as the WAF often would need to have code or a rule written to protect against a vulnerability, so unless the WAF maker is aware of a vulnerability before it is fixed that will happen after the software is able to be upgraded. There is another problem with this that trying to protect in this manner is more likely to not work properly, as can be seen with what happened recently to another security Trend Micro, decided not to keep their one of their WordPress installations up to date.

Also, worth pointing at this point is a post from yesterday where we look at the fact that one of SiteLock’s major web hosting partners (which also happens to be run by SiteLock’s owners) is offering installing outdated and insecure software on their customers websites.

Next up is unfixed vulnerabilities, which are usually newly discovered (unless a software developer doesn’t fix vulnerabilities promptly when they are notified of them):

On the less common end of the spectrum we see compromises due to undocumented vulnerabilities, where the bad guys were the first to the punch with discovering that a vulnerability exists.

To know if there is an unfixed vulnerability that was exploited you would need to know how the website was hacked, which isn’t what SiteLock does. Instead they get back to the WAF:

In this instance, your best defense is taking a proactive approach by implementing and training a web application firewall (WAF) to block future attacks.

There is no explanation of how you are supposed to be able to train the WAF to block future attacks, when you haven’t determined how the attack happened. Going back to previous issue, it also would be more effective to get vulnerability fixed in the software than trying to block attacks, because sometimes even a minor change can evade a block, whereas properly fixing the vulnerability at its root should stop any attack. Doing this would also would likely leave others using the same software vulnerable unless they used a WAF that provided protection against the vulnerability.

Also worth noting here, is that while SiteLock promotes the WAF that is included in some of their services as being their own it is fact Incapsula’s WAF.

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.