Tag: SiteLock

The Reality Behind Praise for a Hack Cleanup Done by SiteLock

In dealing with hacked websites, we are often brought in to redo hack cleanups after another company has done a cleanup and the website gets hacked again. That isn’t necessarily the fault of the company doing the cleanup, but what we have found is that with those websites the company doing the previously cleanup almost always has unintentionally or intentionally cut corners.

The first thing we ask when it is brought up that there was a previous cleanup is if it was determined how the website was hacked. The answer is almost universally that determining how the website was hacked never even came up. Not only is doing that one of the three basic components of a proper cleanup, but if that isn’t done then you have no way of knowing if the vulnerability that allowed the website to be hacked still exists or not and therefore if the website is still vulnerable.

Even after finding out the company that did the previous cleanup didn’t do things right and having to hire us to re-clean the website we have had people say that the previous company did a good job. It is based on things like that, which leads us to believe that positive comments about companies providing security services are often not all that reliable.

A recent example of that type of issue involves frequent topic of this blog, SiteLock. Here was recent tweet from one of their customers:

It sounds like they did a good job, right?

SiteLock then thanked them:

When we first went to look at the website to see if it looked like it been properly cleaned and secured after seeing these tweets, the website was down due to the web host having restricted access to it (a web host that is run by the owners of SiteLock). As of now this is what you get when visiting it:

You don’t have to be a security expert to see that the hack hasn’t been resolved. Beyond what you can see there, which is “hacked by” message and an otherwise empty website, the website is still running an outdated version of WordPress, 4.5.9.

Based on our experience dealing with people who have been customers of SiteLock this poor result isn’t some outlier from an otherwise high quality provider of hack cleanups.

Mr.ToKeiChun69 Defacement Campaign Seems to Be Targeting Websites Hosted with Endurance International Group (EIG) Brands

Yesterday we were contacted by someone looking for second opinion as to whether the web security company SiteLock’s claim that their website contained malware was true. The website’s owner believed that their web host BlueHost and SiteLock might be trying to scam them.

In the case of this website it wasn’t hard to determine that the website was hacked, as this is what was shown on the homepage:

That type of hack is referred to as a defacement hack.

By malware, that may have been what SiteLock was referring to because as we found while previously giving someone a second opinion, for some reason SiteLock labels evidence of a defacement hack as malware (that seems to be a general issue, as they also labeled a spam link that way as well).

After we let website’s owner know that unfortunately the website was hacked, they responded that they felt it was an inside job. We didn’t believe that to be the case, but instead of just saying that was unlikely, we wanted to be able to provide more concrete evidence.

One way to do that would be to find some other websites hit with same defacement that were not hosted with the same web hosting company or another one partnered with SiteLock. When we did a search on Google for “Mr.ToKeiChun69” the first result was a page documenting defacements by Mr.ToKeiChun69 on the web site Zone-H.org, which documents defacements of websites.

In looking at some of the websites that had been defaced by Mr.ToKeiChun69 we found that they all were hosted by web hosting brands owned by the Endurance International Group (EIG). Their brands include BlueHost, as well as A Small Orange, FatCow, HostGator, iPage, IPOWER, JustHost, and quite a few others. SiteLock has a “security partnership” with EIG where SiteLock pays EIG a majority of the fees from services sold through the partnership. The majority owners of SiteLock also run EIG.

While that might lead some to see the worst case, that this was inside job, for us it didn’t. But it did seem rather odd that all the websites would be at one web hosting company and that was possibly an indication that the company has some security problem.

To better understand if there was really a correlation between the web hosting provider and these defacements we did a more thorough check of where the defaced websites were hosted. We checked the first ten websites listed on the 1st, 11th, 21st, 31st, and 41st page of results for this defacement on Zone-H.org. That checked websites that are dated on there as far back as June 29.

Below are the results. We have listed each domain name, the IP address it currently is hosted on, and finally the ISP listed for that IP address or the web host. The ISP Websitewelcome.com is connected to HostGator and Unified Layer is connected to BlueHost, though the websites might be hosted with other EIG brands.

Page 1

  • endblameshameguilt.com: 192.254.236.84 (Websitewelcome.com)
  • acimfordummies.org: 192.254.236.84 (Websitewelcome.com)
  • wakechild.com: 192.254.236.84 (Websitewelcome.com)
  • tena-frank.com: 192.254.236.78 (Websitewelcome.com)
  • acourseinmiraclesfordummies.com: 192.254.236.84 (Websitewelcome.com)
  • decodingacim.com: 192.254.236.84 (Websitewelcome.com)
  • endblameshameguiltgame.com: 192.254.236.84 (Websitewelcome.com)
  • toddtylermusic.com: 192.254.236.80 (Websitewelcome.com)
  • lachildrensridingcenter.com: 192.254.236.8 (Websitewelcome.com)
  • topsportscamcorders.com: 192.254.236.8 (Websitewelcome.com)

Page 11

  • iphonenstuff.com: 192.254.236.82 (Websitewelcome.com)
  • sneakerpicks.com: 192.254.236.82 (Websitewelcome.com)
  • dalmatianadvice.com: 192.254.236.82 (Websitewelcome.com)
  • subscribesave.com: 192.254.236.82 (Websitewelcome.com)
  • helpmebuilda.com: 192.254.236.82 (Websitewelcome.com)
  • bestboatplans.com: 192.254.236.82 (Websitewelcome.com)
  • spelbonusar.com: 192.254.236.82 (Websitewelcome.com)
  • gamingnshit.com: 192.254.236.82 (Websitewelcome.com)
  • marenart.com.au: 192.254.236.82 (Websitewelcome.com)
  • retailstartupbookinabox.com: 192.254.236.82 (Websitewelcome.com)

Page 21

  • www.blackandwhitesecurityltd.com: 192.254.232.90 (Websitewelcome.com)
  • dallasgayboys.com: 192.254.232.86 (Websitewelcome.com)
  • untieeecs.com: 192.254.232.86 (Websitewelcome.com)
  • jonathanjoyner.com: 192.254.232.86 (Websitewelcome.com)
  • www.smcntx.com: 192.254.232.86 (Websitewelcome.com)
  • www.culinairteamzeeland.nl: 192.254.232.90 (Websitewelcome.com)
  • strandvakantieman.nl: 192.254.232.90 (Websitewelcome.com)
  • napers.nl: 192.254.232.90 (Websitewelcome.com)
  • www.camping-renesse.nl: 192.254.232.90 (Websitewelcome.com)
  • www.campingdebrem.nl: 192.254.232.90 (Websitewelcome.com)

Page 31

  • 81tagorelane.com: 50.87.147.75 (Unified Layer)
  • skies39-newlaunch.com: 50.87.147.75 (Unified Layer)
  • newlaunch-gshplaza.com: 50.87.147.75 (Unified Layer)
  • 3dinvisibilitycloak.net: 192.232.251.55 (Websitewelcome.com)
  • professional-liability-insurance.net: 192.232.251.55 (Websitewelcome.com)
  • lyynx.net: 192.232.251.55 (Websitewelcome.com)
  • aksolution.net: 192.232.251.55 (Websitewelcome.com)
  • krilloils.org: 192.232.251.55 (Websitewelcome.com)
  • 3dinvisibility.org: 192.232.251.55 (Websitewelcome.com)
  • ellipticalmachineshelp.com: 192.232.251.55 (Websitewelcome.com)

Page 41

  • topwebber.com: 192.185.21.208 (Websitewelcome.com)
  • yoholly.info: 192.185.21.208 (Websitewelcome.com)
  • myironsuit.com: 192.185.21.208 (Websitewelcome.com)
  • laptoplifestylecafe.com: 192.185.21.208 (Websitewelcome.com)
  • bellyfatcombat.net: 192.185.21.208 (Websitewelcome.com)
  • herbzombie.com: 192.185.21.208 (Websitewelcome.com)
  • biggerbuttshortcuts.com: 192.185.21.208 (Websitewelcome.com)
  • blowtalk.com: 192.185.21.208 (Websitewelcome.com)
  • waisttraineraustraliaco.com: 66.198.240.58 (A2 Hosting)
  • besthairextensions.co.nz: 192.185.44.88 (Websitewelcome.com)

With 49 of the 50 websites currently being hosted with EIG that would certainly seem to point to there is some correlation between the web host and the hackings. As with something that doesn’t have a connection to a web host, you would expect to see a fair amount of different web hosts showing up with that many websites.

So what about the one website that isn’t currently hosted with EIG? It turns out it was hosted with them at the time it was defaced. The IP address of the website on June 29 according to Zone-H.org was 192.185.44.88, which is one connected to HostGator. The records for the domain name were changed on July 4, which is probably when the web hosting was changed.

We don’t know what the cause of this is. It could be that the person or persons behind the Mr.ToKeiChun69 defacements is only targeting EIG hosted websites, has been unsuccessful in targeting websites at other web hosts, or only notifying Zone-H.org of websites hosted with EIG. What would seem more likely is that they are taking advantage of some security issue in EIG’s systems.

To be clear we don’t think that this is an inside job.

We notified the person that contacted us about the correlation, which they hopefully will pass along to BlueHost.

You Don’t Need to Get In a Long Term Contract With SiteLock to Get a Hacked Website Cleaned Up

On about a daily basis we are dealing with people that come to us looking for advice and or help after having an interaction with web security company SiteLock. To make sure we are providing them the best information possible we keep track of what is being said by others about SiteLock as that helps us to be able to explain things that are brought up with us that otherwise wouldn’t make much, if any, sense.

A recent complaint about them that we ran across brings up something that we have been getting a lot questions about recently, so we thought posting on that would helpful.

Here is the complaint from the SiteLock’s BBB page:

We needed help to clean our website (they were referred to us from *********)- we are a children’s educational program and our site had been hacked by an Asian Pornography site. We were about to be featured on national TV so we needed a fix quickly. We were told that our only option was a one year…contract at $99/month- and that everything on our site would be fine. Within 30 days we still had issues and contacted them-ended up having to leave ********* and set up clean,virus-free hosting and change site- at considerable expense to us–were told we were responsible for entire contract. Cherise at first said if we waited until the first 4 months were up we could then cancel and that would count. When I called at the end of that 4 months I was told it was too late and we needed to pay-all anyone ever repeated was “you signed a year contract’. We DID try to cancel within 30 days- which under Florida law – businesses are required to follow. We were forced to pay.

There is no reason that you need to get in to a long term contract to get a hacked website cleaned up, especially a $1200 a year one. We and many others offer one-time clean up services, which are much cheaper than that, and in at least our case, won’t leave you with unresolved issues. Based on everything we have seen the reason why SiteLock pushing this type of plan is that they and their commissioned sales people are trying to get as much money as possible out of people (we recently interacted with a current SiteLock customer that they tried to sell an additional unneeded service on the basis harmless activity occurring on the website).

While there are web hosts that will strongly push their customers to hire SiteLock to clean up a hacked website, if you ask them directly they will tell you don’t have to use SiteLock. The reason they are pushing SiteLock, isn’t that SiteLock does a really great job at cleaning up hacked, as complaints like the one above show, but it is because they are getting paid by SiteLock and in the case of one of SiteLock’s biggest partners because they are run by SiteLock’s owners. Interestingly in the complaint the web host has been redacted at least once, leaving people unaware of the level of connection they had with SiteLock in this instance.

That the customers was still having issues isn’t all that surprising when you consider SiteLock doesn’t do the work needed to make sure the things they claim lead to website reinfections are done when doing cleanups and unlike any other company that we have been brought in after to re-clean a website, they do such a bad job in some instances that they leave websites broken.

Resolved?

One question we get asked about fairly often that we don’t really have a good answer to, is what to do if somebody has run into a situation like the one in the complaint (that is part of why we have a focus on making sure people don’t get involved with SiteLock in the first place). The responses to this complaint indicate it might to be to file a complaint with the BBB, though that isn’t clear.

Here is SiteLock’s response, which indicates that it was resolved:

In regards to complaint #********, we apologize for any confusion or frustration the customer may have experienced. At SiteLock, we always strive to deliver exceptional customer service. Although a contract with agreed upon terms had been signed, our number one priority is delivering the… highest levels of satisfaction. We have taken immediate actions to address the issue, and are happy to report the matter is resolved. 

But the customer’s response seems to indicate that SiteLock hadn’t actual resolved it yet:

Better Business Bureau: I have reviewed the response made by the business in reference to complaint ID ********, and find that this resolution would be satisfactory to me.  I will wait until for the business to perform this action and, if it does, will consider this complaint resolved. Regards, **** *******

If you have been able to get a refund or otherwise get yourself unwound from a SiteLock contract please leave a comment so that others can have a better idea of what might work for them.

SiteLock is For Some Reason Labeling Spam Links as Malware

We often have people coming to us looking for advice after an interaction with the web security company SiteLock. That frequently involves claims by SiteLock that a website contains malware. Not only is the claim not always true, but in some instances the files they have labeled as being malicious don’t really make sense as being malicious (compressed database backups for example). Back in February we ran across what looks to be part of the explanation for this, SiteLock’s malware scanner labels evidence of non-malware based hacks as malware.

In that instance it involved SiteLock’s detection of a website defacement (they were identifying the wrong website as being defaced though), which they were labeling as malware. Back in May we ran across a tweet from SiteLock that seemed to be saying that they would also label spam comments in a database as malware. It turns out that when it comes to spammy content this also applies to spammy links.

Here is screenshot we were forwarded while providing a consultation recently, showing a spam link being identified as malware and being labeled “SiteLock-HTML-SEOSPAM-iar”:

Seeing as website malware refers to either malicious code being served to visitors of a website or malicious code that is in the underlying files or database that that generate a website, labeling spammy links as malware isn’t accurate.

Why SiteLock is doing this isn’t clear. It could be as simple as lack of understanding of what they are doing. While they promote themselves as the “global leader in website security”, there is plenty of evidence out there that really don’t know much on the subject. It also could be intentional. Someone would probably be more likely to order a $100 a month protection plan (which their commissioned sales people are often trying to sell people on) if you told them they had malware on their website instead of a spam link. This also makes it harder for another security company to figure out what is going on, because if they look for malware on the website and don’t find anything they might reasonable assume they missed something that SiteLock had found.

This all is good reminder for anyone dealing with a claim from SiteLock that a website contains malware, to get evidence from them as to what they are claiming is the malware as that should go a long way to clearing up if it is fact malware, some other type of hack, or a false positive. If you have gotten that information from them about a claimed malware issue with your website and are still not sure what is going on, we are always happy to provide a second opinion on the issue.

The Online Trust Alliance Doesn’t Seem Too Trustworthy

When it comes to words that might be reasonably associated with the web security company SiteLock one of them isn’t “trust”. You don’t have to look farther that Google’s search suggestions to see that:

Google;s second search suggestion for "sitelock" is "sitelock scams".

But if you do want to look farther you could look at the situation where with a couple of their services, their content delivery network (CDN) and web application firewall (WAF) services, they promote the services as if they themselves provide them. For example, they use phrases including “SiteLock servers“, “SiteLock patent-pending technology“, and “our IP addresses“. But in reality the service are provided by another company, Incapsula. Beyond just having a security company lie about something that there doesn’t seem to be a need to, the lie is rather troubling because both of those service involve sending a website’s traffic through a third-party’s systems. While SiteLock’s customers are told those systems are theirs, it turns out they belong to a company that the customers neither are aware or have a business relationship with. That raises some pretty obvious privacy and security concerns.

Based on that we don’t understand how an organization named the Online Trust Alliance would think it is appropriate to name SiteLock to their “Online Trust Audit and Honor Roll”, as announced by a SiteLock press release.

The press release lists what is evaluated for that:

As the only comprehensive, independent online trust benchmark study, the ninth annual OTA Online Trust Audit evaluates websites in three categories: consumer protection, responsible privacy practices and security. Based on a composite weighted analysis, sites that scored 80 percent or better overall, without failing in any one category, received Honor Roll status.

If you look at the complaints from SiteLock customers it sounds like the public is need of protection from SiteLock (just last week looked at an example of SiteLock trying to sell a customer on getting unneeded work done). As for security, while SiteLock’s website may be secure, that isn’t even the case for customers included in SiteLock’s cases studies.

A Single Tweet Nicely Sums Up the Problem With WordPress Allowing SiteLock to Be Involved With WordCamps

The web security company SiteLock has a well earned reputation that can be summed up with what Google suggests when you type in their name:

Google's second suggestion is "sitelock scams".

That obviously isn’t a reputation you would think that any company would want. It would probably be difficult for SiteLock to legitimately change it though since their business model seems to be based around the activity that gets them labeled as such.

It would also be difficult because if they, for example, stopped partnering with web host to try to get people to pay them to clean up hacked website that are not in fact hacked, then they would actually have to really clean up websites to get paid and from everything we have seen they are even worse than the average web security company, which is already quite bad, when doing that. For example, we are often brought in to re-clean hacked websites after some other company had previously had done that and then the website got hacked again. While that isn’t always their fault, in almost every instance we have been told that the determining how the website was hacked never even came up, despite trying to do that that being a basic part of the cleanup and important to make sure the vulnerability that allowed the website to be hacked has been fixed. That is certainly something we have seen with SiteLock. What we haven’t seen with other companies is that SiteLock has caused websites to be broken after doing their work.

Instead of trying to change, SiteLock looks to have focused on various efforts to present a public face very different than the one that their customers and not always willing potential customers can find themselves dealing with. What looks to be an important component of that effort is their involvement and sponsorship in the conferences for WordPress, WordCamps, which uses money they have gotten from their questionable business practices. We think a tweet put out by one of those WordCamps succinctly shows what the problem with WordPress allowing that to occur is:

The claim that SiteLock wants make your WordPress secure is belied by many things we have run across, including a few recent examples: thinking that leaving malicious code on a website for a while is not a threat, not taking the actions needed to prevent hacked websites from being reinfected, and not warning about vulnerable plugins or insuring they are being kept up to date on a website they are supposed to be keeping secure. But maybe the most troubling recent example is that SiteLock is still knowingly spreading false information about the security of the core WordPress software and using it to make a profit. We would love to hear from someone on the WordPress or WordCamp side of things how that makes anyone’s WordPress secure.

At some point, maybe we have already reached that point, you have to say that WordPress is complicit in what is going on here. Back in September of last year we contacted the central WordCamp organization to let them know that about the issues with SiteLock and ask for a comment about the situation or a more general comment on any restrictions on who can be a sponsor. We never got any response from them, though it was pretty clear they saw the message. So it seems that they can’t actually justify what is going on, but are still willing take money SiteLock has gotten through less than above board business activity. We later left a comment on a blog post about SiteLock on the WordCamp US’ website, shortly afterwards the comments left on that post were removed and commenting was disabled, so there does seem to an effort to hide what is going on.

What could explain some of why they continue to allow SiteLock’s participation is that SiteLock’s owners don’t just sponsor WordCamps under the SiteLock brand, but also through brands of the web hosting company Endurance International Group, which they run. For example, at WordCamp Europe they were a higher level sponsor through EIG brands Bluehost and MOJO Marketplace (MOJO Marketplace also doesn’t seem to be too concerned about security):

SiteLock Uses Harmless Activity on Website as a Reason to Try to Sell Unneeded Malware Removal to One of Their Customers

When you have a malware infected or otherwise hacked website it can make a lot of sense to hire someone with expertise in handling the cleanup of them to do that for you. Beyond that they would have the knowledge to quickly resolve the issue for you, where we have seen the value of doing that for our clients is that they often can use help understanding what is going on. Often times they are concerned about things that they don’t need to be and we can easily clear things up for them.

Unfortunately, far too often they are concerned about things due to misleading or outright false information being put out by other security companies. That then leads in to the big problem when it comes trying to hire an individual or a company for any type of security service, many of them really don’t know and or care much about security. On top of that there doesn’t appear to be good way to find one that isn’t true about, since these companies don’t seem to have a problem with lying and reviews of them come from customers who often are unlikely to have a good sense of the quality of the service they have gotten since they don’t have the expertise needed to determine that (we have had people saying another company did a good job even after they have hired us to re-do work that wasn’t done right by that company).

We recently had someone that came to us that believed there website had a re-occurrence of a malware issue and were looking for an alternative to the company they were already paying to secure their website, SiteLock, to do deal with it. That was in part because SiteLock had not detected any issue they had noticed.

The first thing we always do when someone comes us to about dealing with a malware infected or otherwise hacked website is to determine that it is in fact hacked. In this situation the belief that the website was infected with malware was based on some things the website’s owner had seen in the log file of HTTP activity. In reviewing those we found that those things were harmless. There were several request for spammy URLs, but the status code of the responses was 404, which indicates that a page with that URL did not exist. The other concerns related to request coming from a Russian search engine and requests coming from the file that does cron jobs for WordPress. Other checks should no current issue with the website.

SiteLock had given them a very different response when they had brought up what the customer had seen the log. SiteLock didn’t address the specifics that were raised and seemed to just assume that the website infected. They implied that the infection coincided with the SiteLock’s web application firewall (WAF) service that was in use being downgraded from “Enterprise level” to the “Premium level” (contrary to SiteLock’s marketing that service is actually provide by another company). To resolve the issue they suggested upgrading the WAF back to “Enterprise level” and having their “Expert Services” clean it up.

If all that were true it would seem to be reasonable to ask why they offer the “Premium level” WAF that permitted the website to get infected. You might also ask why you should pay more to clean up a website when the service you already paying to protect didn’t actual accomplish that.

While it is possible that SiteLock assumption that the website was infected and recommending that more money being spent with them was based on them not understanding that you should determine that a website was hacked before trying to clean it up, everything we have seen points to something else. That being that from everything we have heard and seen when you get in touch with SiteLock you are usually going to interact with commissioned sales person. It wouldn’t be surprising that a person that is not a tech and are getting paid if they can sell you something, would instead of determining that there wasn’t any issue, try to sell this person on an additional service and to a more expensive version of an existing service. It also would be in line with what have heard in numerous other instances when SiteLock failed to provide protection, that the answer was to move to a more expensive service.

SiteLock Still Spreading False Information About the Security of WordPress to Their Customers

Back in September we wrote about how the web security company SiteLock had introduced a new feature that was supposed to warn about vulnerabilities on WordPress websites, but would falsely claim that websites running older WordPress versions had vulnerabilities in them that they didn’t.

This seemed to be caused in part by a fundamental lack of understanding of how WordPress handles security, which involves security fixes being released for older version of WordPress that have the automatic background updates feature (WordPress 3.7 and above). This is something that anyone dealing with hacked WordPress websites should know since part of properly cleaning them involves determining, to the extent possible, how they were hacked and you would need to know what vulnerabilities would exist in a version of WordPress when cleaning it. From everything we have seen SiteLock doesn’t properly clean up hacked websites (and they even use that fact as a reason to upsell their customers), so maybe it shouldn’t be surprising they wouldn’t know this.

It also seems to be caused in part by them not understanding the underlying data source for the vulnerability information, the WPScan Vulnerability Database, as that correctly labels which versions of WordPress are vulnerable to the vulnerabilities (as we will show in a bit).

We know that SiteLock is aware of all of this as they clearly read our post as they filed a DMCA takedown notice to remove an image we had included in the post.

You would think that after becoming aware of this SiteLock would have fixed this, right? Well it turns out 9 months later they are still falsely claiming that WordPress website contain vulnerabilities they don’t.

The other day someone contacted us after they had been told by their web host iPage that they their website had security issues and they should sign up for SiteLock. After doing that they contacted us after seeing our previous post about this issue and thinking that what SiteLock had told them about vulnerabilities on their website wasn’t true.

The website was running WordPress 4.6.6 at the time and SiteLock claimed it had the following medium and high severity vulnerabilities:

Severity: High
Category: csrf
Summary: WordPress 4.2-4.7.2 – Press This CSRF DoS
Description: CSRF DoS vulnerability in WordPress versions 4.2 to 4.7.2 through the Press This functionality.
Severity: Medium
Category: rce
Summary: WordPress 4.3-4.7 – Potential Remote Command Execution (RCE) in PHPMailer
Description: Potential Remote Command Execution (RCE) in PHPMailer used in WordPress versions 4.3 to 4.7.1 can potentially be used to remotely execute commands.
Severity: High
Category: bypass
Summary: WordPress 4.2.0-4.7.1 – Press This UI Available to Unauthorised Users
Description: Authentication bypass vulnerability in WordPress Press This versions 4.2.0 to 4.7.1 allows unauthorized users to access the UI.
Severity: High
Category: csrf
Summary: WordPress 2.8-4.7 – Accessibility Mode Cross-Site Request Forgery (CSRF)
Description: Cross-Site Request Forgery (CSRF) in WordPress versions 2.8 to 4.7 via Accessibility Mode allows unauthorized actions to be performed.
Severity: Medium
Category: bypass
Summary: WordPress 2.8.1-4.7.2 – Control Characters in Redirect URL Validation
Description: Control Characters vulnerability in WordPress versions 2.8.1 to 4.7.2 through the Redirect URL Validation
Severity: Medium
Category: unknown
Summary: WordPress 3.0-4.7 – Cryptographically Weak Pseudo-Random Number Generator (PRNG)
Description: Cryptographically Weak Pseudo-Random Number Generator (PRNG) vulnerability in WordPress versions 3.0 to 4.7 in the multisite activation key creates the potential to guess/brute-force the activation key.
Severity: High
Category: xss
Summary: WordPress 3.4-4.7 – Stored Cross-Site Scripting (XSS) via Theme Name fallback
Description: Stored Cross-Site Scripting (XSS) WordPress versions 3.4 to 4.7 via Theme Name fallback allows malicious code to be stored on the site.
Severity: High
Category: xss
Summary: WordPress 4.3.0-4.7.1 – Cross-Site Scripting (XSS) in posts list table
Description: Cross-Site Scripting (XSS) vulnerability in WordPress versions 4.3 to 4.7.1 through the posts list table.
Severity: Medium
Category: xss
Summary: WordPress 2.9-4.7 – Authenticated Cross-Site scripting (XSS) in update-core.php
Description: Authenticated Cross-Site scripting (XSS) WordPress versions 2.9 to 4.7 via update-core.php allows malicious code to be injected to the page.
Severity: High
Category: xss
Summary: WordPress 4.0-4.7.2 – Authenticated Cross-Site Scripting (XSS) in YouTube URL Embeds
Description: Authenticated Cross-Site Scripting (XSS) vulnerability in WordPress versions 4.0 to 4.7.2 allows an attacker to inject malicious code on to the site through YouTube URL Embeds.
Severity: High
Category: xss
Summary: WordPress 3.6.0-4.7.2 – Authenticated Cross-Site Scripting (XSS) via Media File Metadata
Description: Authenticated Cross-Site Scripting (XSS) vulnerability in WordPress versions 3.6.0 to 4.7.2 allows malicious code to be injected on to the site via Media File Metadata
Severity: High
Category: sqli
Summary: WordPress 3.5-4.7.1 – WP_Query SQL Injection
Description: In WordPress 3.5 to 4.7.1 WP_Query is vulnerable to a SQL injection (SQLi) when passing unsafe data.
Severity: Medium
Category: unknown
Summary: WordPress <= 4.7 – Post via Email Checks mail.example.com by Default
Description: Post via Email Checks mail.example.com by Default in WordPress version 4.7 and earlier.

Those vulnerabilities don’t exist in WordPress 4.6.6, which can be seen by looking at the relevant entries in the WPScan Vulnerability Database. Let’s take a look at a couple of examples:

For the vulnerability “WordPress 3.0-4.7 – Cryptographically Weak Pseudo-Random Number Generator (PRNG)” the vulnerability was fixed in version 4.6.2:

For the vulnerability “WordPress 3.6.0-4.7.2 – Authenticated Cross-Site Scripting (XSS) via Media File Metadata” you can see that it was fixed in version 4.6.4:

It also worth noting here that the severity ratings that SiteLock provides here look to be vastly overstated since none of these vulnerabilities is likely (or has in fact been) exploited on wide scale, which you would expect at least for vulnerabilities rated as being high severity.

iPage isn’t innocent in this, as not only do they get a significant percentage of the price being paid for SiteLock services sold through their partnership, but their parent company also happens to be run by SiteLock’s owners.

You would also think that WordPress might make a point of warning people away from SiteLock since they are profiting off falsely claiming that WordPress websites contain vulnerabilities, but instead they have welcomed them as sponsor and speaker at various WordCamps, WordPress conferences. In fact they thanked them for their “commitment to the WordPress community”:

We’d like to thank each of our 2017 global community sponsors for their commitment to the WordPress community. Their generous contributions support community events like WordCamps and WordPress user groups worldwide.

The Problems Caused By SiteLock Using Nessus as Their Vulnerability Scanner

The other day we mentioned how we often have people that contact us about situations where the web security company SiteLock has contacted them claiming that their website has malware, but SiteLock has not provided any evidence of that. Recently we have started being contacted about situations where SiteLock is contacting a website’s owner claiming that the website has some vulnerability that could lead to the website being hacked. So far in those instances SiteLock has not provided any evidence to back up their claims, so we can’t access their validity directly. But we have continued to see problems with their vulnerability scanner, which seems like it would likely also be what would be the source of their claims.

What looks to be an overarching issue with their vulnerability scanner is that the underlying technology isn’t really designed to be in the fashion it is. Back in December we stumble on to the fact that at least part of their vulnerability scanner is really just them using a piece of software named Nessus, which as best we can tell that is something that isn’t really designed to be used by end users. Instead it looks like it is designed to be used by security professionals and software developers. For them producing false positives would be less of an issue since they could fairly easily evaluate if there is an issue, whereas end users are not usually going to have that capability. It is even more of a problem if someone is using those unreliable results to try to sell people on security service, as SiteLock might be doing.

An example of the issue can be seen in a recent thread on the WordPress Support Forum, where someone got notified of a claimed security problem in the login page of a WordPress blog:

This was sent to me by SiteLock about a security problem on my wordpress blog. The CGI issue is attached to the login page. Can this be fixed please?

Synopsis: A CGI application hosted on the remote web server is potentially prone to SQL injection attack.

Description: By sending specially crafted parameters to one or more CGI scripts hosted on the remote web server, SiteLock was able to get a very different response, which suggests that it may have been able to modify the behavior of the application and directly access the underlying database.

An attacker may be able to exploit this issue to bypass authentication, read confidential data, modify the remote database, or even take control of the remote operating system.

Note that this script is experimental and may be prone to false positives.

Solution: Modify the affected CGI scripts so that they properly escape arguments.

Right off the bat this information doesn’t seem end user friendly as it looks as though the reference to CGI script in that is really a reference to any sort of code running on a website (as can be seen by this list of CGI abuses on the website for Nessus).

That confusion lead to a moderator falsely claiming that it would appear the website is compromised:

WordPress does not use CGI for anything, so if you’re getting that on WordPress’s login page, it would appear that your site has been compromised as their tool has identified.

Carefully follow this guide. When you’re done, you may want to implement some (if not all) of the recommended security measures.

Beyond that two things stick out.

The first being the statement noting that “this script is experimental and may be prone to false positives.” Why is something experimental and known to produce false positives being used to produce the results of SiteLock’s vulnerability scans?

The second one being the part that states “By sending specially crafted parameters to one or more CGI scripts hosted on the remote web server, SiteLock was able to get a very different response, which suggests that it may have been able to modify the behavior of the application and directly access the underlying database.”. Changing the values that are sent with a request could produce a very different response for obvious non-security reasons. Say if you changed the value of parameter specify what to be search for on a search page, you would expect to get different results. If you sent an invalid value with a request you might also get a very different result than if you sent a valid one.

Based on everything we have seen from the results of SiteLock’s vulnerability scanner so far, the results don’t look reliable. So we would recommend avoiding it if you are looking to determine the security of your website. If you do have them claiming that there is a vulnerability and you want to be on the safe side, we would recommend you get a second opinion from someone familiar with handling security issue with the software you are using.

Hacker Provides More Information on Fixing Defacement Hack Than SiteLock and HostGator

When it comes to claims that a website contains malware or is otherwise hacked coming from the web security company SiteLock or their web hosting partners our recommendations is to not ignore their claims despite the serious problems with false claims. Instead we recommend getting a second opinion from another company that deals with hacked websites. We are happy to do that for free and a lot of people have been taking us up on that offer.

The first thing we do when contacted about a second opinion is to find out what evidence SiteLock and or the web hosts has provided as to the claimed issue. In doing that we have seen that in most cases the supporting evidence of the claim falls in to one of two very different categories. In the first they have provided a listing of examples of impacted files and in the other they provided no details whatsoever. So far we haven’t seen a strong correlation between either of those and veracity of the claim.

In one recent instance where a website was really hacked they provided no information whatsoever, while the hacker actually provided helpful information.

In response to our question about what evidence the owner of the website mentioned they had received none despite multiple calls a day, but they had noticed a couple of pages in the Google search results with hacked content.

From that we already had a good idea as to what was going on.

When we looked at those pages we found that they had the following message:

Hacked By Not Matter who am i ~ i am white Hat Hacker please update your wordpress

The only vulnerability that has existed in the core WordPress software that has been exploited in a wide scale in years (maybe close to a decade) was vulnerability that allowed modify the content of posts, which existed in WordPress 4.7.0 and 4.7.1. As long as WordPress’ automatic background updates were working properly this vulnerability was not a threat, as it was fixed with a new version well before the vulnerability started being exploited. That issue could have explained how a hacker was able to add that message to the pages they did.

Based on all those things it wasn’t surprising to find that the website was running WordPress 4.7.1.

At that point we recommend that the website’s owner update WordPress, undo any changes made to the post content, and see about making sure that automatic updates are able to function going forward.

If SiteLock or HostGator had told them that in the first place the issue could have easily been resolved, but it likely wouldn’t have lead to a SiteLock sale, which is possible explanation why they wouldn’t do that. You might be wondering why a web host wouldn’t want their customer to be secured, the answer is in part that HostGator and other Endurance International Group brands received a lot of money when SiteLock sales are made through their partnership. Another part of the answer is that SiteLock’s owners also run the web hosting company.

It isn’t just that they didn’t provide any details; they told them something that is not accurate with this type of issue:

“During a recent SiteLock security scan of your website, malware was detected that could jeopardize the safety of your website and your customers’ data.”

The website doesn’t look to have contained any malware. The reason for the claim that malware was detected appears, based on our previous experiences, to be due to SiteLock’s malware scanner not just be used to detect malware, but any evidence of a hack, but any issue detected incorrectly being labeled as a malware issue.