Bluehost, Sitelock, SSL, and .htaccess

[ Box Hole ] Apparently, Bluehost partnered with a company called SiteLock sometime last year. Supposedly Sitelock is a “website scanner that proactively checks for malicious threats and vulnerabilities”. I guess the service operates on Bluehost servers, and today they sent a scary email letting me know that “malware was detected” on my Bluehost site.

Here’s the thing though. I host only one site at Bluehost, and it is a simple one-page site with only a few simple files. So I was surprised by this “malware detected” alert from Sitelock. I mean, the site is so simple as to be practically identical to the default Bluehost setup.

For example, if you sign up for a new account at Bluehost (or any web host), and then don’t do anything at all with it, just leave it entirely as-is in its default state, right. Then say the server gets hacked. It MUST follow that the default hosting setup is insecure. And this is why I found the malware alert so puzzling, because the site is only a few files away from the default state of the server. So:

Either Bluehost itself was compromised or the malware alert was bogus.

Nothing to hack

Let me put it another way..

I have exactly one site hosted at Bluehost. The site consists of the following files, as shown in this screenshot:

A simple one-page site hosted at Bluehost

It’s like 10 files total. The result is a simple bookmark site for online design tools. You can check it out. Not much to hack really, it’s basically a static web page generated by a short PHP script. Indeed, the site had been rolling along just fine and then suddenly..

I get an email saying that malware was detected

Out of the blue, I receive this rather alarming email message:

Sitelock Malware Alert

Whaaa….t? Was this for real? Had my site been hacked? Infected with malware? Or worse? Hide the children!

Hacked? Time to investigate..

After receiving the scary “malware detected” email alert, I quickly examined each of the 10 site files. And really there are only four possible candidates that may have been compromised and injected with malware: the two JavaScript files, the one PHP file, or the .htaccess file. Upon close inspection, I did find some changes in my .htaccess file. Here is the original file contents:

# CANONICALIZATION
<IfModule mod_rewrite.c>
        RewriteCond %{SERVER_PORT} 80 
        RewriteRule (.*) https://w3b.guru/$1 [R=301,L]
        #
        RewriteCond %{THE_REQUEST} /index\.php [NC]
        RewriteRule (.*) https://w3b.guru/ [R=301,L]
        #
        RewriteCond %{HTTP_HOST} ^www\.w3b\.guru$ [NC]
        RewriteRule (.*) https://w3b.guru/$1 [R=301,L]
</IfModule>

These directives are carefully constructed to ensure proper canonicalization for the site. The rules work great as-is and should not be modified. Unfortunately somehow the code was changed by someone/something to look like this:

# CANONICALIZATION
<IfModule mod_rewrite.c>
        RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/[0-9a-zA-Z_-]+$
RewriteCond %{REQUEST_URI} !^/\.well-known/cpanel-dcv/[0-9a-zA-Z_-]+$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
        RewriteRule (.*) https://w3b.guru/$1 [R=301,L]
        #
        RewriteCond %{THE_REQUEST} /index\.php [NC]
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/[0-9a-zA-Z_-]+$
RewriteCond %{REQUEST_URI} !^/\.well-known/cpanel-dcv/[0-9a-zA-Z_-]+$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
        RewriteRule (.*) https://w3b.guru/ [R=301,L]
        #
        RewriteCond %{HTTP_HOST} ^www\.w3b\.guru$ [NC]
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/[0-9a-zA-Z_-]+$
RewriteCond %{REQUEST_URI} !^/\.well-known/cpanel-dcv/[0-9a-zA-Z_-]+$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
        RewriteRule (.*) https://w3b.guru/$1 [R=301,L]
</IfModule>

First. Yuck. What a mess. Would never ever do something like that. Evar.

So it looks like someone employed a script to inject the three .well-known rules after each instance of the existing RewriteCond directives. So why were the new rules added? Further digging revealed that a set of .well-known folders/files also had been added to the site. Here they are displayed via cPanel:

Thanks for adding these files without my consent /s

Tip: To view hidden files when viewing via cPanel, you can append &showhidden=1 to the URL query string.

So from what I gathered, someone decided to modify my site’s .htaccess file and created several files/folders on the server — without my consent. This should be considered malicious activity and completely unacceptable. I mean seriously. If you want/need to change something on your customer’s sites, the very least you can do is let us know with an email or something. Just sneak attacking in the middle of the night when nobody is looking and injecting a bunch of unwanted or unexplained crap is detestable at best.

So apparently the Sitelock Malware Alert was correct?

So at this point, there were two problems with my Bluehost account:

The shady Sitelock malware alert
The injected .htaccess code and set of .well-known files

Were these two events related? Was the “malware” detected by Sitelock referring to the injected code and files? That would be rather unusual as the .well-known cruft actually does serve a purpose for those who use it.

Time for some answers..

Wanting to understand the Sitelock alert and the injected codes (and whether the two events were related), it was time to call Bluehost support @ 844-460-5814 for some answers.

After waiting on hold for 30 minutes listening to horrible elevator music, finally got through to a support specialist who was super friendly but ultimately didn’t know anything relevant. The rep did ask about the origin of the email, if it was from support at sitelock.com, which it was. He then said that Sitelock had sent out that email alert by mistake, which I assume means it was sent to all Bluehost customers. I wonder how many customers will pay for the suggested “help”?

Moral of the story

So it turns out that the two events (ironically) were not related. At some point (I assume) Bluehost or cPanel injected the .well-known code into my .htaccess file, and also created the three new directories on the server. Then in a separate incident, Sitelock sends out a false-positive scary malware alert. Just a coincidence that I happened to discover both at the same time.

I say “assume” it was Bluehost because why would an attacker waste resources on something like adding .well-known files. There is nothing to be gained from it. So I assume it was Bluehost and not an outside attacker.

Update: Sitelock responds

Shortly after communicating my displeasure with the whole affair, I receive the following email from Sitelock:

Dear Customer,

To help protect your website, your hosting provider has partnered with SiteLock to provide your website with a complimentary malware scanner. Every day this nifty little tool checks your website for malware and sends you an alert if any is found so you can decide how you want to fix it.

You’re receiving this email because during a recent scan, a false positive mistakenly occurred generating an email in error. We apologize for the inconvenience and assure you the problem has been fixed. If you feel like you need more information, give us a call or email us 24/7/365 at 877-257-9263 or support at sitelock.com. We here at SiteLock are ready to help you if needed.

Stay Secure,

The SiteLock Team

Love the closing: “Stay Secure” indeed. Hopefully this is a one-off incident that hasn’t happened before and won’t happen again. Lots of people would have no way of knowing whether this malware alert was correct or not.

Note that the email address has been obfuscated in the previous email message.

Update: About the .well-known rules

For those interested in “why” the .well-known rules were added, I found this enlightening post, which explains:

This messy block of conditions is injected automatically by cPanel before every RewriteRule directive when it auto-renews an SSL (Let’s Encrypt?) security certificate. These conditions ensure that the validation file (required in order to renew the SSL cert) is accessible.

So for anyone who needs the required .well-known code for Let’s Encrypt SSL auto-renewal to work, you can add the following rule block to your site’s root .htaccess file:

# CPANEL SSL RENEWAL
<IfModule mod_rewrite.c>
        RewriteCond %{REQUEST_URI} ^/\.well-known/acme-challenge/[0-9a-zA-Z_-]+$ [OR]
        RewriteCond %{REQUEST_URI} ^/\.well-known/cpanel-dcv/[0-9a-zA-Z_-]+$ [OR]
        RewriteCond %{REQUEST_URI} ^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
        RewriteRule ^ - [L]
</IfModule>

Then in your site’s root directory, create the following folders:

/.well-known/
                /acme-challenge/
                /pki-validation/

Such that acme-challenge and pki-validation are subfolders of .well-known. Do not include the forward slashes / in the file names. From what I can tell, this is all that is required, but make sure that you test that everything works according to your needs, etc.

Update: Probably what happened

I wrote this post a few months ago after the event. Since then, I’ve done more research on this, and in retrospect it looks like the injected code and files happened automatically when Bluehost rolled out their free SSL via Let’s Encrypt functionality sometime last year.

Before the hack, my site was non-SSL with a clean .htaccess file and no .well-known cruft on the server. Then at some point, Bluehost “upgraded” everyone’s site with Let’s Encrypt SSL. And in doing so, apparently the process added the code and files.

So everything makes sense, but it still sucks that files were changed on the server without anyone’s consent. And this probably happened to hundreds of thousands of sites (however many Bluehost upgraded to SSL). Next time, PLEASE give customers a heads up with a simple email or whatever. Don’t just take liberties with people’s property — you might break something important.