Tag: iPage

iPage Causing OpenCart Websites to Stop Functioning

We recently had someone come to us for OpenCart support after out of the blue the website stop functioning and the following error was being shown instead:

Warning: require_once([redacted]/system/startup.php): failed to open stream: No such file or directory in [redacted]/index.php on line 17 Fatal error: require_once(): Failed opening required ‘[redacted]/system/startup.php’ (include_path=’.:/usr/local/lib/php-5.5.22-amd64/lib/php’) in [redcated]/index.php on line 17

The error message seemed to indicate that a file was missing, but when we checked the files the file in question, /system/startup.php, was still there. With a closer look at the message we could see that the file was being requested from a different location than it seemed it should. What we then found was that web host for the website, iPage, had for some reason changed the directory path for the account of the website. The configuration files still had the old location included in the directories listed in them. This wasn’t a one off issue, as while we were looking into the issue we found another instance of that involving another OpenCart based website two months ago.

The quickest solution to the issue is to simply update the path for various settings in the /config.php and /admin/config.php files. The limitation with that is that if iPage changes the directory path again the website would stop working again.

To workaround that we then tried to use relative paths for the various directories listed in those files, which worked except images were not showing up. In troubleshooting that we noticed the “src” attribute for images was empty. We the found that the cause of that was the following code in the file /catalog/model/tool/image.php (also in /admin/model/tool/image.php):

if (!is_file(DIR_IMAGE . $filename) || substr(str_replace('\\', '/', realpath(DIR_IMAGE . $filename)), 0, strlen(DIR_IMAGE)) != DIR_IMAGE) {
	return;
}

The second check in that if statement would fail causing no image to be specified.

Removing that check would resolve that issue, but the problem would reoccur after any upgrade due to the new version of the file restoring that code.

Ultimately we added code to the configuration files to get the current directory path using getcwd(), so that if iPage changes it again then the new one will be used automatically and the website won’t go down.

iPage’s Strange False Claim of Malware Being Detected on a Website

We get a lot of people that contact us looking for a second opinion as to a claim that their website contains malware coming from the SiteLock and or their web hosting partners. One of the latest included a head scratching claim in an alert from the web host iPage (the logo shown with that is SiteLock’s, so maybe they did the scan):

Malware has been detected on your site during a recent scan. 0 domain may be affected.

So there was malware detected on their site during a recent scan, but it impacted “0 domain”. Those seem like they are contradictory statements to us, but maybe something that doesn’t count as a domain was impacted?

What we suggested to the website’s owner was to contact iPage for more evidence because that wasn’t enough based on that to give a second opinion as to the veracity of the claim, though it seemed unlikely considering the website was built with the Weebly website builder provide by iPage.

The response they got from iPage was that the there was not any malware, but they were not provided with an explanation as to what had happened:

We apologize for any inconvenience caused. I have performed a scan of your account and it is malware free. Right now there is no alert regarding infection is shown in the ControlPanel.

If you receive an alert similar to this from iPage whether it actually lists a positive number of domains affected or not, our recommendation is to contact iPage for more information and then get a second opinion instead of signing up for a SiteLock service, which they are trying to sell you from that alert, right off the bat.

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.

iPage Provides Conflicting and Bad Advice on Cleaning Hacked Websites

When it comes to dealing with a hacked website, the advice you are going to get from a web host isn’t necessarily very good. For example, we have often seen them tell people their websites must have been hacked due to outdated software, without the web host having done anything to determine if that was true (and in some cases despite the website not even using outdated software). In one recent instance we found that one of the brands of the web hosting company Endurance International Group, JustHost, was pointing toward an outdated version of Joomla as the source of hack, while they were offering to install that version on websites despite support for it ending over two years before. Since the installation occurred through another Endurance brand, MOJO Marketplace, it looks like that version probably being offered for install across their other brands as well.

With that that type of thing happening at Endurance, it might not be surprising to see what we recently came across while doing a consultation with someone with a hacked website using one of their other brands, iPage, in which they provided conflicting and bad advice on dealing with a hacked website.

Here was is most of the original email they sent to their customer about a hacked website:

During a routine scan, we detected suspicious contents that suggest your ‘[redacted]’ account has been compromised. We have temporarily suspended your website to protect your website visitors from getting impacted and also preventing the impact on your website reputation as well as our server’s reputation.

We have uploaded a file ‘websitescan.txt’ within the stats directory of your account which contains the full list of infected files. We need you to take one of two actions suggested below:

Please follow the steps given below to remove the infected contents on your own:
1. Open the ‘websitescan.txt’ file through your FileManager (OR use ‘FTP’ software like FileZilla).
2. Clean or remove each of the listed files.
3. You can also upload a clean copy of web files from your local backup.

Alternatively, we encourage you to contact our preferred partner, SiteLock. In addition to long-term solutions like their Fix and Prevent products, which offer daily scans and removal of malware, SiteLock also provides an emergency service, SiteLock 911. You can call our dedicated SiteLock support representatives using the Toll Free number (United States and Canada customers only): (855) 378 6200. International: +1 415 390-2500. To learn more about SiteLock, please go to: https://www.ipage.com/product/sitelock

So in that email they recommend simply cleaning/removing or replacing the files they identified.

When they refer to SiteLock as their preferred partner what they really mean they are getting paid a lot of money to push their services (SiteLock’s owners also happen to run Endurance International Group).

In a follow up email they had these recommendations:

Please remove the malicious contents or replace the infected files with a clean copy of web files from your local backup.

Our best recommendation is to completely remove all the files from the account and restore the contents from a known clean backup. An alternative would be going through a company such as SiteLock to clean and secure all scripts. If this isn’t done and the malicious files that are found through scanning are simply removed, the vulnerability will still exist and you will encounter the files again and again.

Those two paragraphs seem to conflict with each other as the second one states that if “the malicious files that are found through scanning are simply removed, the vulnerability will still exist and you will encounter the files again and again”, but the first paragraph and the first email suggest doing just that.

The larger problem with this is that whether you were to “completely remove all the files from the account and restore the contents from a known clean backup” or remove the indicated files that isn’t going to resolve the vulnerability. The malicious code in files on the website had to get there somehow, so there must be something that allowed that and you would need to fix that. To be sure you had fixed it, instead of just guessing that you had, you would need to figure out how the website was hacked in the first place. Nowhere in the emails do they suggest doing those things and those are things their “preferred partner” SiteLock usually doesn’t do based on everything we have seen with them.

One of SiteLock’s Owners is Also The CEO of Many Of The Company’s Web Hosting Partners

SiteLock is a web security company that we had originally became aware and wrote a number of posts about due to our seeing the poor quality of their services when working on client’s websites that had previously used their services. Due to those posts we started started getting contacted about more serious issues with them, namely that in a lot of cases they seem to be scamming people. One of the things that has stood out to us in looking into the situation was the fact that so many web hosts have partnered and continued to stay partnered with them. Was the money that we assumed SiteLock was paying them for the partnership worth the damage to their reputation, seeing as in complaints about them the web host who had partnered with them is frequently brought up?

In looking for some information for another post about the company we ran across the fact that the CEO of a major web hosting provider is also the one of the owners of SiteLock (the other owner is a director of the same provider), which does a lot to explain their partnerships and also raises even more question as to the probity of what is going between them.

On the about page of SiteLock’s website there is no mention of the ownership of the company, doing a Google site search of their website didn’t bring up any mention of either of the two entities that appear to be their parent company.

On the website of one of those, UnitedWeb, SiteLock is shown as one of their brands of the company, while the web hosting companies Endurance International Group and IPOWER are listed as public companies:

unitedweb-brands

The connection between of all of those entities isn’t clear based on that, though.

A little searching brought us to this page that seemed to point to a direct connection between SiteLock and Endurance International Group, which with more checking seems to be confirmed. In Endurance International Group latest quarterly report it states that:

The Company also has agreements with Innovative Business Services, LLC (“IBS”), which provides multi-layered third-party security applications that are sold by the Company. IBS is indirectly majority owned by the Company’s chief executive officer and a director of the Company, each of whom are also stockholders of the Company.

What is Innovative Business Services? That is the entity that owns SiteLock (referred to as a member on that page). So the CEO and a director of Endurance International Group are the owners of SiteLock.

It not clear where UnitedWeb falls in that, but it looks like it might be the owner of Innovative Business Services, and then in turn that is owned by the CEO and directory of Endurance International Group.

Unless you are very involved in website hosting you probably don’t recognize the name Endurance International Group, but they own many well known web hosts. The brands page of their website they highlight some of the more high profile ones including A Small Orange, Bluehost, FatCow, HostGator, iPage, and IPOWER:

endurance-international-group-brands

But that just scratches the surface, here is the all of their current brands (most of them appear to be web hosting companies) as listed on the Wikipedia page for the company:

  • 2slick.com
  • AccountSupport
  • Arvixe LLC
  • A Small Orange
  • ApolloHosting
  • AppMachine
  • Berry Information Systems L.L.C.
  • BigRock
  • BizLand
  • BlueBoxInternet
  • BlueDomino
  • Bluehost
  • BuyDomains
  • CirtexHosting
  • Constant Contact
  • Directi
  • Dollar2Host
  • Domain.com
  • DomainHost
  • Dot5Hosting
  • Dotster
  • easyCGI
  • eHost
  • EmailBrain
  • EntryHost
  • Escalate Internet
  • FastDomain
  • FatCow
  • FreeYellow
  • Glob@t
  • Homestead
  • HostCentric
  • HostClear
  • HostGator
  • HostNine
  • HostMonster
  • HostV VPS
  • hostwithmenow.com
  • HostYourSite.com
  • HyperMart
  • IMOutdoors
  • Intuit Websites
  • iPage
  • IPOWER/iPowerWeb
  • JustHost
  • LogicBoxes
  • MojoMarketplace.
  • MyDomain
  • MyResellerHome
  • MySocialSuite
  • NetFirms
  • Networks Web Hosting
  • Nexx
  • PUBLICDOMAINREGISTRY.COM
  • PowWeb
  • PureHost
  • ReadyHosting.com
  • ResellerClub
  • Saba-Pro
  • SEO Gears
  • SEO Hosting
  • SEO Web Hosting
  • Site5
  • Southeast Web
  • SpeedHost
  • Spertly
  • StartLogic
  • SuperGreen Hosting
  • Typepad
  • Unified Layer
  • USANetHosting
  • vDeck
  • Verio
  • VirtualAvenue
  • VPSLink
  • Webzai Ltd.
  • WebHost4Life
  • webhosting.info
  • Webstrike Solutions
  • Xeran
  • YourWebHosting