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.

Cleaning Up a Hacked Website May Not Impact Email Spam Blacklisting

We recently had a couple of people come to us looking for a hack cleanup done for their websites due to the website or its domain name being blacklisted. The term blacklisted is sometimes used by website security companies to refer to situation where a website has been flagged by some entity as being hacked, calling that blacklisting looks to us like one of the many ways they try to turn up the fear factor around the security of websites. The more common usage and where it is more accurately used is with email spam blacklists. In both cases what was being referred to by the people contacting us was the latter and in both cases cleaning up a hack wouldn’t have taken care of the blacklisting.

When anyone contacts us about a hacked website we first want to access the situation to among other things, make sure the website is truly hacked, as we are often contacted about situations where the website isn’t actually hacked. In the case of these two websites, only the first appears to have been hacked, but when inquiring about who was blacklisting we found out that even with that one what was of more concern than fixing the website (it was broken in addition to being hacked) was that emails sent from the domain associated with the website were not reaching the recipients.

In both cases when we went to look into the details of the blacklisting what we found was that neither their websites nor their domain names were being blacklisted. Instead what was being blacklisted was the IP address associated with the websites/domain names. That sounds like a minor difference, but it was very important in these situations because when went to look at the details of why the IP addresses were blacklisted we found that this was due to other websites sharing the same IP address, which would likely be on the same server as well. So nothing done with the websites we were being contacted about would have resolved that, instead action related to the other websites would need to be taken and that would be best handled by contacting the web hosts for the websites.

There was another important possible implication of the blacklisting being caused by other websites when it came to the first website, as it seems possible that there was some security issue at the server level or the web host level that caused the website to be hacked. We say that because you had three websites that seems to be sharing the same server that had been hacked in the same time frame and both others had been hacked to be used in way that caused the IP address to be blacklisted. At least in our experience, hacked websites causing email spam blacking listing isn’t a common issue so to have two websites on the same server cause that in the same time frame would lead us to believe there might be a connection between the hack of the two.

With the first website the web host quickly took action with the other websites and got the blacklisting removed, but as far as we are aware there wasn’t anything done about the possibility of breach of the web host’s systems. With the second we can see the blacklisting was quickly resolved, but we don’t what caused that, as we didn’t hear back from the person who contacted after informing them about what was actually at issue and what would need to be done to resolve it.

Security Journalist’s Bad Focus and Flashpoint’s Questionable Business Risk Intelligence

When it comes to why website security is in such bad shape there are lots of parties that play a role. Journalists could play a critical role is shining a light on what is wrong with the security industry, but for the most part they instead act as stenographers for claims made by security companies without a concern for the accuracy of the claims or if they are newsworthy.

An example of that this week that we happened across (there are in all likelihood plenty of others just this week) involved what seems like an insignificant claim. Multiple outlets including The Register, SecurityWeek, and Bleeping Computer ran with a story of a claim that a thousand Magento websites had been hacked. A hack of that size alone doesn’t seem all that significant and highlighting it might not be helpful if it leads people to think of Magento being less secure than other solutions that are in fact less secure. What might make this newsworthy is if the method of the hacking was significant, say a new vulnerability was being exploited. As we will get to in a bit, it seems like the claimed source of the hacks might not be accurate, but if true, it doesn’t seem all that significant and isn’t Magento related.

It isn’t that security journalist haven’t had anything to cover recently were there could be some real journalism done when it comes to hacked websites. Recently we have been discussing a situation where a relationship between a web hosting company and a security company looks to have lead to the web hosting company ignoring hackers targeting their customers and possibly ignoring that their systems have an insecurity that is leading to the hackings. Questioning those companies could provide more insight on the situation and might lead to corrective action being taken.

The claims about the Magento websites being hacked came from a company named Flashpoint, which promotes itself delivering business risk intelligence, which they describe thusly:

Business Risk Intelligence (BRI) broadens the scope of intelligence beyond threat detection in the cyber domain to provide relevant context to business units not traditionally afforded the benefits of intelligence from the Deep & Dark Web. By informing decision-making and improving preparation, BRI mitigates risk across the enterprise.

BRI can not only bolster cybersecurity but also confront fraud, detect insider threats, enhance physical security, assess M&A opportunities, and address vendor risk and supply chain integrity. The results are better decisions that protect a company’s ability to operate.

To us that sounds like something that probably isn’t of much value when so often security basics are still failing to be done, but it seems to be easier to sell people on more advanced things than on what they really need to be doing.

If their claims about Magento websites being hacked are any indication that intelligence seems to be of little value. Here is the kind of insight that provides:

Researchers at Flashpoint are aware of the compromise of at least 1,000 Magento admin panels, and said that interest in the platform has continued unabated on entry-level and top-tier Deep & Dark Web forums since 2016. Attackers have also demonstrated continued interest in other popular ecommerce-processing content management systems such as Powerfront CMS and OpenCart.

Hackers being interested in hacking websites shouldn’t be news to those in the security industry. That they would interested in popular software also shouldn’t be news. What might useful intelligence is if it was discovered that hackers were exploiting a zero-day vulnerability, which is a vulnerability being exploited before the developers of the software are aware of it, but that isn’t the case here.

Here is the claimed cause of the hacks:

The Magento sites are being compromised through brute-force attacks using common and known default Magento credentials. Brute-force attacks such as these are simplified when admins fail to change the credentials upon installation of the platform. Attackers, meanwhile, can build simple automated scripts loaded with known credentials to facilitate access of the panels.

There isn’t an explanation of how they determined that was the case and we can’t think of what “known default Magento credentials” would refer to, so that leaves us to wonder if they actually know how the websites were hacked (or have even a basic understanding of Magento).

Later they made additional reference to “default credential usage” usage that seems unconnected to Magento:

In the meantime, the rash of attacks resurrects the epidemic of default credential usage among admins. Default credentials were at the core of the 2016 Mirai attacks where hackers were able to access connected devices such as security cameras, DVRs and routers using known and common default passwords. The compromised IoT devices were corralled into a massive botnet that was pointed at a number of high-value targets including DNS provider Dyn, French webhost OVH, and journalist Brian Krebs’ website in order to carry out crippling distributed denial-of-service attacks.

The Mirai attacks involved trying to gain access to Internet of things (IoT) devices using factory default usernname/passwords, but Magento doesn’t have a default username/password like that, so we are at loss to understand what they are talking about (it might be that they have no idea what they are talking about).

For a moment let’s assume what they are claiming about trying to log in using common passwords is true, since that is certainly a real issue. What seems to be the biggest take away from that is that security basics (like using a strong password) are still not being done, while companies like Flashpoint are selling people on the need for additional security services. You would hope that these companies might consider that they might be part of the problem instead of the solution for the poor state of security, but we have seen no indication that they do.

What also sticks out to us is that Flashpoint doesn’t seem to understand basic security terminology, as they are mixing up two different types of attacks. What they are talking about, trying to log in using common passwords, is a dictionary attack. They instead refer to it as a brute force attack, which actually refers to trying to log in using all possible passwords. How you would protect against those is very different, so understanding the difference is important for those in the security industry. That the Wikipedia manages to get this right and Flashpoint doesn’t seems like an indication that they don’t have the best grasp of security, which might explain them trying to sell people on business risk intelligence instead of something that will have a better effectiveness at improving security.

SiteLock and Sucuri Inaccurately Portray Hidden Spammy Content on Website as Malware

We frequently have people contacting us for a second opinion on claims from the security company SiteLock that their websites have been hacked. To be able to provide that we ask for the evidence being presented by SiteLock to back that claim up. An important reason for doing that is that SiteLock appears to refer to anything they detect as possibly being an indication of a hack as malware, even if it isn’t malware.

Malware is short for malicious software and can accurately refer to one of two things when it comes to websites. The first being malicious code being served from a website and the second being malicious code located in a website’s files or database.

One reason why they might refer to any indication of a hack as being malware is to make the issue sound more serious than it really is and make you more likely to pay them for some security service. As an example of that, in one instance where we were contacted about a claim of theirs, what they were claiming was “critical” severity malware was just a link to another website. What was even supposed a problem with the link, which was included with a comment on a blog post, wasn’t clear since the domain name of the website being linked wasn’t registered anymore, but saying there is an issue with a link would sound a lot less concerning than “malware”.

Someone that they recently contacted with a claim that their website contained malware, had also been told by the SiteLock representative that called them that Google would “shut down” their website due to the issue. In reality Google doesn’t shut down websites and since the issue wasn’t actually malware they wouldn’t even block access to the website if they had detected the issue.

That person had then run the website through the Sucuri SiteCheck scanner, which also claimed the website contained malware. Sucuri also goes the over top in making issues seem as bad as possible to sell their service:

The small text there states:

Your site appears to be hacked. Hacked sites can lose nearly 95% of your traffic in as little as 24 to 48 hours if not fixed immediately – losing your organic rankings and being blocked by Google, Bing and many other blacklists. Hacked sites can also expose your customers and readers private and financial information, and turn your site into a host for dangerous malware and illicit material, creating massive liability. Secure your site now with Sucuri.

What they actual identified there is what we would describe as hidden spammy content, which is a less serious issue than malware. It also didn’t contain any code, JavaScript or otherwise, despite Sucuri labeling it as “Known javascript malware” and stating that “Malicious Code Detected”.

While Google might penalize a website for that hidden spammy content like that, it isn’t going to do any harm to people visiting the website.

If you visit the link they provide for the details of that type of issue, http://labs.sucuri.net/db/malware/spam-seo.hidden_content?24, the description doesn’t mention “malware”, but does mention “hiding spammy content”:

Hiding spammy content (links, spammy texts, etc) on legitimate web pages is a common black hat SEO trick. It helps use existing site pages in black hat SEO schemes while keeping it invisible to site visitors and webmaster.

There are many techniques that help hide certain parts of a web pages. Most of them include either CSS or JavaScript. The simples is placing spammy content inside a div tag with the display:none; style.

Another interesting similarity between those two companies, which seems like it ties in to the overstated impact of the real issue on this website, is that security services provided by both SiteLock and Sucuri don’t seem to be focused on actually securing websites. Instead they seem to be more focused on trying to deal with after effects of the website having been hacked after having left the websites insecure. That all could be an indication the companies don’t have a good understanding of what they claim to have expertise in or that they are just interested in trying to get as much money out of people instead of being focused on improving security.

This Review Seems Like Evidence That SiteLock’s Vague Emails About Supposed Vulnerabilities Are Just a Marketing Ploy

On a fairly regular basis we are contacted by people looking for advice after being contacted by the security company SiteLock. From what we have seen a lot of the claims that SiteLock and their representatives make are misleading or false and seem to be intended to get people to sign up for unneeded services.

In some cases the claims are obviously false, like when they falsely claimed that a website contained “critical” severity malware due to having a link to an unregistered domain name.

In other cases the claims sound impressive, but they fall apart upon inspection. That was the case with SiteLock’s “likelihood of compromise” scores, which are promoted as being based on “high-level security analysis by leveraging over 500 variables to score a website’s risk on a scale of low, medium and high”. When a Forbes contributor reached out to SiteLock for an explanation on how their website that supposedly had a “Medium” “likelihood of compromise” could even be compromised in way that was considered by SiteLock’s analysis, they claimed they would and then stopped responding:

When asked how a remote attacker might then modify the files on a CMS-less single-page self-contained static website without either guessing/phishing/resetting the account password or finding a vulnerability in the server stack, a representative initially said they would work with their engineering team to send me some examples of how such a site could be compromised, but later said they would not be commenting further and did not respond to two subsequent requests for additional comment.

One of the claims we have yet to see any evidence that there is any basis behind it, are claims that websites have some undetailed vulnerability, which are made in emails like this:

Because website security is important, your hosting provider has provided you with a complimentary scanner from SiteLock that proactively checks for malicious threats and vulnerabilities. This scan regularly reviews your website plugins, themes and content management system (CMS) for potential vulnerabilities.

During a recent scan, a vulnerability was detected on your website.

For details on the findings, including the location of the vulnerability and remediation options, please contact SiteLock today. We would be happy to walk you through your dashboard and talk to you about next steps. Our security consultants are available 24/7 to answer your questions.

Call 844-303-1509 or email support@sitelock.com

A recent positive review of SiteLock we ran across certainly seems to give more weight to possibility that there really vulnerabilities that they have discovered. Here is the review:

I responded to your email letting me know I had vulnerabilities on my websites. After our conversation everything was taken care of to thwart those vulnerabilities with your premium firewall. David was very helpful in making me understand how the firewall will benefit me. Thank you!

If there were really were vulnerabilities, what would need to done to take of the vulnerabilities would be to fix them. A firewall wouldn’t fix them. At best it might limit the ability to exploit them, but SiteLock doesn’t provide evidence that their TrueShield Web Application Firewall is effective at all (they might not have any idea if it is since the service is provided by another company, something they lie about) and in some cases that type of firewall can be easily bypassed entirely. It also worth noting here that as far as we are aware when you get in touch with SiteLock you are talking to a commissioned sales person, not a technical person with security expertise, so they likely wouldn’t know if what they are selling someone is actually beneficial or not to that person.

What we previously have seen with this type of email made it seem like the claims could be baseless, as among other things they have even sent message where the didn’t even say what website was supposed to have been impacted. The review seems in line with that, as it looks like it is just a way to get people to contact them and then sell them on security services that are not actually even focused on protecting websites from being hacked.

As we said the last time we mentioned these emails, you could probably safely ignore these messages, but if you want extra assurance you could contact SiteLock and ask for evidence of their claim (though we have heard in the past that they wouldn’t provide that) or check to make sure you are doing the important things to keep your website secure, like keeping your software up to date. While we don’t recommend it, we also offer a security review to check over things like if software you are using is known to be insecure.

SiteLock Admits To the Meaningless of Website Attacks Stat, While Still Promoting It

Recently we have put forward the idea that a way to better understand the poor state of the security industry is to think of it as the “insecurity industry”, as much of the industry is not interested in actually securing websites, but instead on selling people on the idea that they should be buying expensive security services without an expectation that they will actually provide effective protection. One company that really exemplifies that is SiteLock. Just a couple of weeks ago we discussed how they promote their service in way that indicates that it doesn’t actual protect websites, as they portray that instead of keeping websites from being hacked they provide incomparable security by being better able to deal with the after effects of leaving websites vulnerable to being hacked (though they didn’t provide any evidence they are even good at what they claim to be able to do).

One of things we mentioned previously as part of what defines the “insecurity industry” is selling people on the idea that websites are under constant attack. That is something that SiteLock frequently brings up. For example, in a press release from March 12 they claimed:

The average website is attacked 59 times per day, which is up a staggering 168 percent from the previous year.

If you think about for a second though, that doesn’t sound like a meaningful statistic since the average website isn’t being hacked 59 times a day or even once a day.

A couple weeks after that press release, SiteLock had a bit of a problem as their latest claimed stats indicated that attacks were down:

Websites experienced 44 attacks per day on average in Q4 2017, a 25 percent decrease from the previous quarter.

Part of the way they tried to downplay that was to extrapolate out that number over a year (despite knowing that the number is variable):

Despite this decrease, a single website can still experience 16,000 attacks in one year alone.

As far as we are aware the average website isn’t being hacked once a year even, so once again the stat is rather meaningless.

Next up they downplayed it by saying the number of attacks isn’t actually meaningful:

“A decrease in attacks does not mean that websites are safer. In fact, it may even be the opposite,” says Neill Feather, president of SiteLock. “Hackers are constantly trying new avenues and even leveraging older tactics that continue to be successful. As our research shows, cybercriminals are now able to successfully breach a site with fewer, more targeted attacks. Now more than ever, businesses need to evaluate their current security posture and ensure they have both the right technology and a response plan in place should a hack occur.”

So if attacks are up you should be concerned, if attacks are down you should be even more concerned, it is almost like the number of attacks isn’t meaningful at all.

That claim sticks out considering that they are still make a big deal of the number of attacks. They even created a graphic in that very post highlighting the number of attacks:

What would be a relevant stat would be how many successful attacks there are. The quote from the President of SiteLock indicates they would know that, “our research shows, cybercriminals are now able to successfully breach a site with fewer, more targeted attacks”. We doubt they actually do, but assuming they did, telling people the truth, which is that the successful attacks are very uncommon, would get in the way of scaring people. So how uncommon? From everything we have seen we are talking about an incredible small fraction of one percent of attacks that are successful.

Another part of the about the quote from the President of the company that sticks out to us is “businesses need to evaluate their current security posture and ensure they have both the right technology and a response plan in place should a hack occur”. This gets to the idea of the “insecurity industry” because the expectation that even though you have the “right technology” (that is paying SiteLock or somebody else for a protection service) you should be assuming you are going to get hacked anyway. The reality though is that if you do the basics of security you can prevent most hacks (even ones that advanced security products fail to protect against). In some cases though doing the basics won’t protect websites from hacks in part due to things that SiteLock and other security companies are doing that they shouldn’t and thing they are not doing, but should be doing (like failing to determine how websites they are cleaning up have been hacked).

Part of the next paragraph after his quote is in line with selling insecurity as security:

Additionally, a website scanner can find malware on your site, helping to mitigate threats in real time.

If you are finding malware on a website you are past the threat stage and have already been exploited. Unless a malware scanner is running constantly, it is likely wouldn’t help in realtime and we haven’t seen any evidence that any malware scanner is all that effective at detecting malware (SiteLock has promoted theirs with bogus independent testing). Selling people that detecting malware on a website isn’t an indication that a security product failed, but it is working, is exactly is exactly what the “insecurity industry” is.

Beyond scaring people, another reason why a company would put out stats like this is to get press coverage, since journalists will run with this type of thing even if the data is of questionable value (we have seen plenty of instances where security journalist have run with wholly false claims, including from SiteLock). You might think that a journalist might notice that SiteLock is even saying the stat isn’t meaningful here and not run with it in this instance, but that didn’t happen. Among them, the Washington Post ran with it with the headline “A typical small business website is attacked 44 times a day” and Tech Republic “The average SMB website is attacked 44 times per day”.

Sucuri’s Website Application Firewall (WAF) Makes Improving Websites’ Security Harder, While Being Easily Bypassable

When cleaning up a hacked website there are three main components to doing that properly. We often find that security companies don’t do two of those. One of them being trying to determine how the website was hacked. The other being getting the website secure as possible, which usually involves getting the software on the website up to date. If a company isn’t able to make sure the software is up to date, it seems likely they also are not familiar enough with the software that they should be dealing with hacked websites running it.

One well known company that usually skips doing those things is Sucuri. They promote as alternative to doing that securing, that you can rely on the virtual patching provided by their website application firewall (WAF). There are a number of reasons why that is bad idea, including that they don’t present any evidence, much less from independent testing, that their virtual patching is effective (they also don’t present any evidence that their service is effective at protecting websites in general). Probably the largest problem with relying on that though, is that it can be incredibly easy to go completely around their WAF, leaving websites that haven’t been properly secured wide open to being hacked.

Before we get in to that, what lead to us writing this post was our recent experience with their WAF making it harder to get a website secured.

We were recently brought in to upgrade a Joomla installation on a website that Sucuri cleaned but had failed to upgrade the software on it. When we went to do that upgrade we ran into an error, “ERROR: AJAX Loading Error: Forbidden”:

That error message doesn’t provide much information on what was going wrong and we would guess that others that run into it might get stuck at that point. In debugging that we found that when an AJAX request was made to  /administrator/components/com_joomlaupdate/restore.php the response being received was this page:

Access Denied - Sucuri Website Firewall If you are the site owner (or you manage this site), please whitelist your IP or if you think this block is an error please open a support ticket and make sure to include the block details (displayed in the box below), so we can assist you in troubleshooting the issue.

At that point we could have contacted the person we were dealing with from the website and get them to try to whitelist our IP address, but there was a far quicker solution, simply bypassing Sucuri’s WAF, which can be incredibly easy to do.

Here’s is how Sucuri explains how their WAF works:

The reality is that all HTTP/HTTPS traffic does not have to begin where they show it beginning in that graphic, instead, if you know the IP address of the Original Host you can connect directly to it, bypassing the WAF entirely.

While in something we will get to in a moment, Sucuri refers to this IP address as being “hidden”, in reality it often isn’t hidden at all. In the case of the website we dealing with we just pulled up the DNS records for the website and the second IP address (after the Sucuri one) was the Original Host’s IP address (there was another equally easy method available as well). By simply associating that IP address with the domain name in a computer’s host file the Sucuri WAF can be bypassed.

From previous real world experience we can say that people will in fact rely on Sucuri’s WAF to keep them safe instead of keeping software up to date, which can leave people wide open to attack if someone just takes time to bypass the WAF. What makes that particularly problematic is that a website could appear to be secure for a long time, leading to people claiming that Sucuri’s solution is effective, and only later it becomes clear that things were not as how they seemed.

Here’s what makes this even more troubling, Sucuri is aware of the ability to bypass their WAF, but they either don’t understand that their attempt solution to stop that doesn’t resolve the issue or they don’t care that that what they are providing is fundamentally insecure.

The page Prevent Sucuri Firewall Bypass on Sucuri’s website begins:

If someone knows your hidden Hosting IP address, they can bypass our Firewall and try to access your site directly. It is not common or easy to do so, but for additional extra security, we recommend only allowing HTTP access from our Firewall.

The best way to prevent hackers from bypassing our Firewall is limiting their access to your web server. To do this, all you have to do is add restrictions to your .htaccess file so that only our Firewall’s IP will be able to access your web server.

As we already noted, the IP address isn’t necessarily hidden at all. Calling attempting to prevent the easy bypass as “additional extra security” as opposed to being essential, doesn’t provide much assurance that they actual are concerned about the security of websites using their service.

The larger issue here is that trying to restrict what IP address can access the Original Host directly isn’t very effective. That is because all someone has to bypass that restriction is to spoof a permitted IP address, which involves making it seem a request came from a different IP address than it really did. Either Sucuri doesn’t understand that or doesn’t care that their WAF is fundamentally insecure, neither of which should be true about a security company.

Their a major limitation with spoofing an IP address that is important to note though, which is that any response would not be sent back to the system sending the spoofed requests since the response would be sent back to the spoofed IP address. But with the kind of vulnerabilities we see actually being exploited on websites that often wouldn’t be an issue since the hacker doesn’t need to receive a response to gain further access to the website. Oncee they have access they could remove the IP address restriction or send any responses they need in way they can still access (say writing them to a file accessible through the website).

While we wouldn’t recommend using Sucuri’s WAF (or their services in general), if you are using it, restricting IP addresses as suggested in that previously mentioned article would provide better security when using their WAF.

Zucando Lifted Description Text For Their Zen Cart Upgrade Service From Ours

One of the problems we see across various services we provide is that there are lots of companies offering services that they seem to have a limited, at best, understanding of what they are providing. One of things that can disguise that is that we often find that other companies have copied descriptions of our services, including in some cases claims about our capabilities. That obviously makes it hard to determine who you should go with when you see multiple companies making similar claims without knowing that the others not only don’t have the capabilities claimed, but that they are making claims that are just copied from elsewhere.

In some cases in the past we have seen companies that knew so little about what they were offering that they had changed the properly spelled names of software to incorrect spellings (probably because they ran the text through a spell checker that wasn’t aware of those).

Recently while looking into something we ran across an example of somebody copying the description on one of our services. Here is how the description for our Zen Cart Upgrade Service began as of August 23, 2011 on archive.org:

Keeping your installation of Zen Cart up to date is important because it insures your website is not hacked through a known vulnerability in Zen Cart. If your Zen Cart installation has already been hacked we can clean it up and then upgrade it. In addition to making sure your website is secure, new minor releases fix bugs and new major release add new features and functionality.

The version as of June 11 of that year was slightly different.

Here is how the description of the same type of service by a company named Zucando (https://zucando.com/zen-cart-modules/services/zen-cart-upgrade) begins today:

Keeping your installation of Zen Cart up to date is important because it insures your website is not hacked through a known vulnerability in Zen Cart. If your Zen Cart installation has already been hacked we can clean it up and then upgrade it. In addition to making sure your website is secure, new minor releases fix bugs and new major release add new features and functionality.

Those are exactly the same except for the lack of a link to a hack clean up service. Nowhere on their website do they seem to offer such a cleanup service.

According to release notes tab of their service, it was created well after we had started using that description text:

  • Date Added: 18 Dec 2013

The earliest version of their page that archive.org has, is from March 4, 2014 and the text is exactly the same as it is today.

Google isn’t really help to people since their page shows up higher than ours in relevant search results despite the text being based on ours.

This Looks Like It Might Be Another Instance of SiteLock Partnered EIG’s Apparent Security Issue

A week and half ago we discussed a situation where there looked to be at least a hacker specifically targeting websites hosted with web hosting company EIG, which does business under the brands including A Small Orange, Bluehost, FatCow, HostGator, iPage, IPOWER, JustHost and quite a few others. The more concerning possibility is that the hacker wasn’t just targeting websites hosted with EIG but taking advantage of some security issue within their systems to breach the websites. Due to their relationship with a web security company, SiteLock, they don’t seem to have an interested in investigating this type of situation (and neither does SiteLock).

That wasn’t the first time we had run across the possibility of such a situation occurring with EIG, back in July of last year we discussed another instance, but in that case we were not brought in to clean up any websites targeted, so we had a very limited ability to assess what was going on.

We have now run across yet another instance that lines up with the others.

We were contacted about a hacked website after the person handling a replacement of that website was in contact with SiteLock (due to the website being hosted with HostGator) and then they found our blog posts about SiteLock.

What they had been told by SiteLock was the same kind of stuff we hear a lot. That included that they were told that if the website was cleaned up of the “malware”, but not protected by SiteLock going forward, it would just get infected again. Because the website was for a church, the SiteLock representative said they could provide a discounted rate of $400-600 a year (which doesn’t seem to actually be a discounted rate). Instead they hired us to clean it up for a lot less than that.

What we knew before we started working on the cleanup was that the main website in the account was serving up Japanese language spam when crawled by Google and other search engines, which lead to the search results for the website to also show that. That website was running Joomla 1.5, which was EOL’d in September 2012. There was a recently set up WordPress installation, which was being prepared to replace that website, and that website was not serving that spam content to search engines.

What would seem to be the obvious security concern there would be the Joomla installation, since it is using software that hasn’t been supported in 5 and half years. We haven’t seen evidence that Joomla installations of that vintage are currently exploitable in some mass fashion, so that seemed less likely to us. There was also the possibility of an extension installed in the Joomla installation being a security concern since those would be equally out of date.

The code causing the Japanese language spam wasn’t hard to find, it was obfuscated code added to the top of the index.php file in the root directory of the Joomla installation, which is also the root directory of the website. The last modified date for that file was years ago, which probably meant the hacker had changed it to hide that they had modified the file (which is very common).

As we started more thoroughly reviewing the files to look for any other malicious code on the website, the only place we found them was in multiple files that were located in a directory for a plugin, /wp-content/plugins/html404/, in another WordPress installation on the website. That additional WordPress installation hadn’t been mentioned to us.

That plugin contained files from version 2.5.6 of the plugin Akismet as well as files with malicious code in them. Those files were named:

  • 404.php
  • idx.php
  • jembud.php
  • wso25.php
  • xccc.php

That WordPress installation was running WordPress 4.7.9, which is an outdated major version, but should be secure due to WordPress releasing security updates for older major versions. The website was using a customized version of a popular theme and only one other plugin installed, neither of those things look like a likely source of a security issue.

In looking over the WordPress accounts for that website we found that the first account, which normally be the one created when WordPress was installed was named “html404”, which considering it matched the name of plugin’s directory, seemed like it was probably changed by a hacker (likely with the password also being changed).

In the looking at the session_tokens for that user in the wp_usermeta table of the database for that WordPress installation we could see that at nearly the same time that plugin’s files were listed as last being modified on January 25 someone had logged in to that account from an IP address in Indonesia (which isn’t where the website is located).

A non malicious file in the root directory of the website connected with the code added to the index.php file was also listed as last being modified at the same time, so it looks like the breach of the WordPress installation lead to the Joomla website being modified.

Because the web host for the website, HostGator, did not have any log archiving enabled we could only see the HTTP logging from the day we were cleaning up the hack limiting what we could gleam from that. The FTP logging didn’t show any access that shouldn’t have happened.

Looking around for any other mentions of this that might allow us to give the client better information on what could allowed what had occurred to happen, we came across a thread on the website for WordPress with other people that had been impacted. That provided further confirmation of what we had been piecing together, but nothing that shed any light on the cause.

At that point the possibility that this could be another example of whatever security issue might be going on at EIG was at top of mind. Since a hacker with either direct access to the databases on the server or access to files on it, which would give access to the configuration files with database credentials in them need to access the databases, could change a WordPress username/password like this. There was no direct mention of what web hosts the websites mentioned in that thread were using, but one of the participants username pointed to the website impacted and the website was hosted with Bluehost, another EIG brand.

In the previous instances where we found an EIG connection there was a defacement involved that had showed up on the website Zone-H. That allowed us to easily check over numerous websites to see what the host were. That isn’t the case with this hack, but we did check over a number of websites we could find that were involved and what we found was they all were hosted with EIG brands. Here are the IP addresses along with the EIG brands of websites we found reference to being impacted:

While the sample set we have is smaller in the previous instances the chances that all of the website we checked would all happen to be at one hosting company is not what you would expect if the hacking was caused by something unrelated to the web host. At best it looks like we have now run across multiple hackers that look like they are only targeting this one company, but what seems to be a reasonable possibility is that there is a security issue in EIG systems that is allow hackers to exploit them.

Several of those are from the same IP address, which would likely mean they are on the same server.

SiteLock’s Idea of Protection Doesn’t Seem to Involve Real Protection

Considering that EIG brands heavily push people to hire SiteLock to clean up websites, it seem incredibly hard to believe that SiteLock could have missed what we have picked by just dealing with a couple of websites, if they were properly dealing with hacked websites. But from what we know they don’t usually properly clean up hacked websites. Instead of doing proper cleanups they sell people on services that claim to protect websites, as what was attempted to be sold in this instance, that don’t even attempt to do that.

If you are not determining how websites are being hacked, it would be difficult to be able to protect them. If there is an issue with EIG’s system, it would unlikely that such a service could protect against it, so spotting that type of situation would be really important.

SiteLock’s lack of interest in true protection is even worse in the light of the fact that SiteLock has “partnered” with a web host that seems at best uninterested that hackers are specifically targeting their customers or worse, their customers are getting hacked due to a security issue in the web host’s systems. But it gets even worse, when you know that while the relationship between EIG and SiteLock is promoted as partnership, the reality is that the two companies are very closely connected then they let on publicly. The majority owners of SiteLock also are the CEO and board member of EIG, which neither side mentions publicly. So you have the owners of a security company that seems to be uninterested in security of websites it is supposed to be protecting also looking to be leaving websites they host insecure. On top of that both sides would profit from this insecurity as EIG disclosed that they get 55% of revenue for SiteLock services sold through their partnership, so both companies have a financial incentive to not find and fix something like this as long as their customers doesn’t become aware of what is going on and leave in mass. That seems like a good argument for keeping security companies and web hosts at arm’s length (maybe not surprisingly with the other instance of a security company closely tied with a web host the security company doesn’t seem to be interested in security either).

Wordfence Has Missed This As Well

SiteLock isn’t the only security company that seems to not be on the ball here. In the previously mentioned thread on the WordPress website one of the participants mentioned they were going to have the security company Wordfence “perform a comprehensive security review and if necessary, final clean-up” after being impacted by this. In the follow up there is no mention at all of Wordfence having made any attempt to determine how this occurred, just that “I am happy to report that the Wordfence security analyst found no evidence of malware on the website.”. Considering that trying to determine how a website was hacked is one of three basic parts of a cleanup, it seems a bit odd that there wouldn’t be a mention of Wordfence not figuring out the source if Wordfence had done things right and mentioned that they were unable to determine the source of the hack

The follow up response to that was from a Wordfence employee, who instead of being concerned about the source of hack being a mystery, just promotes a post on the Wordfence website that wouldn’t have any impact on resolving the underlying cause of these hacks. So it would seem they are unconcerned about this as well.

Sitelinks in Google’s Search Results Missing “This site may be hacked.” Warnings

Last week we discussed a US government contractor that offers several security services, including “Cyber Security” a service, while having hacked website, which we had run across after they were in the news for their involvement with questionable practices at US Housing and Urban Development (HUD) department. That incongruity between offering security services and not being able to secure their own website, makes it seem not all that surprising to us that in follow up reporting on the situation with the HUD department it was reported that the company was possibly engaged in fraudulent billing as well.

There is another thing we noticed in relation to the hack, though, which is that Google is currently incompletely warning that they are aware that websites are hacked.

In our previous post we mentioned that, for example, when you visited the website’s Careers page you would be redirected to a casino website. When showing up in Google’s search results that page is flagged with the message “This site may be hacked.”:

But when that same page is shown as a sitelink there is no warning:

Being a sitelink versus as standalone result should have no impact on whether this type of issue is occurring (and that is the case with this website), so Google should warn there as well.