Fall Sale! Code FALL2024 takes 25% OFF our Pro Plugins & Books »
Web Dev + WordPress + Security

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:

[ Bluehost website files ]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:

[ Bluehost Sitelock email ]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:

[ Bluehost injected files ]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:

  1. The shady Sitelock malware alert
  2. 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.

About the Author
Jeff Starr = Web Developer. Security Specialist. WordPress Buff.
The Tao of WordPress: Master the art of WordPress.

15 responses to “Bluehost, Sitelock, SSL, and .htaccess”

  1. Marcus Tibesar 2019/05/16 2:48 pm

    A similar thing happened to me when I joined WP Engine. Without my consent they shut off revisions and optimized my database. It took me about a week of research to find out why my database all of a sudden shrunk. When I discovered they did this without my consent or even a notification I cancelled my account and I have never gone back. These big hosting companies think they can change your files, and we’re too stupid to find out or even care. BIG mistake…

    • Jeff Starr 2019/05/16 3:19 pm

      Yes some of us are paying attention. I’ve also seen other hosts make unannounced changes to customer property. For example Media Temple once inserted links from my Dungeon page with ads to their WordPress hosting pages. Really invasive and shady behavior, who knows how many sites received the same treatment. Like you say, they think they are smarter than everyone else and can do whatever they want. Fortunately some of us are paying attention to the details.

  2. Luke Cavanagh 2019/05/16 8:20 pm

    Interesting that the email would get sent out without the host doing any real digging into the issue.

    • Jeff Starr 2019/05/16 8:57 pm

      Excellent point. Could mean that they give Sitelock open access to everything on the server?

  3. Rich Trefz 2019/05/17 8:11 am

    … 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. …

    Kill Bill: But one thing we won’t do is sneak into her room in the night like a filthy rat and kill her in her sleep.

  4. Jim Walker 2019/05/17 8:41 am

    Yes, SiteLock does have open access to all accounts, as it’s part of their hosting offering / control panel now.

    And if you mention the word “compromise” or “hacked” in any correspondence or discussion with support you’ll be immediately redirected to the SiteLock sales team.

    The free SSL setup and .well-known is required for the LetsEncrypt or AutoSSL to funtion. These are verification related files and directories for the most part and not malicious.

    It is now common for hackers to add their back door scripts into these directories. So these necessary directories need to be included in any malware checking/scans you may run as well.

    Thank you for the fine play-by-play. Sadly, I hear this story almost daily. Over two-thirds of every call I receive nowadays includes the word “sitelock” along with a rather horrific customer story about same.

    Enjoy and Love.

    • Jeff Starr 2019/05/17 8:45 am

      Thanks for your insight. So do you think the two events might be related? Such that the Sitelock scan detected Bluehost adding of the .well-known stuff? I may need to update the article.

      Updated to add: if the two events are related, it would be better for optics. But they already sent the apology email, which then would not have been necessary. Catch 22?

  5. Jim Walker 2019/05/17 3:13 pm

    That odd rewrite rule

    RewriteRule (.*) https://w3b.guru/$1 [R=301,L]

    is an obvious hack. But even so, I can’t find anything remotely malicious about that website (well at least not reported online). The w3b.guru website has been up for a couple years without reports or security concerns.
    Blackhat SEO?

    That said, it sure seems like an erroneous knee jerk reaction by SiteLock’s automation. Sadly, many get caught in this play.

    Whether an errorful scanning and reporting system or overly aggessive salesmanship by a web hosting company… You’re not the first who’s reported this behavior.

    • Jeff Starr 2019/05/17 3:19 pm

      I wrote/added that rule. Why do you think it is a “hack”? Blackhat SEO? What..?

      • CipherDrqconis 2019/05/18 12:29 pm

        RewriteRule (.*) https://w3b.guru/$1 [R=301,L]

        Isn’t this just a standard your.domain.com redirect to www.your.domain.com rule?

        Syntactically I usually see it written as:

        RewriteRule (.*) https://w3b.guru/$1 [L, R=301]

        But that is likely to be because this is how it is shown in the standard .htaccess documentation. I too am confused why this would be considered as a “hack” or BlackhatSEO…

      • I agree it’s a very common logic used in that rewrite. I may have reversed the flags, but order does not matter there.

        Perhaps Jim will enlighten us with a response..

  6. Jim S Smith 2019/05/22 7:25 pm

    When stated “Bluehost”, that had my attention already.

    Please note:

    Bluehost AND Sitelock are both owned by a huge company called Endurance International Group. (EIG)

    EIG is perhaps the largest owner of “internet real estate” concerning web-hosting, domain registrars, and other companies like Sitelock, Mojo Themes, etc.

    I do my absolute best to steer clear of any companies owned by EIG, and for good reason. Many of their acquired companies ending firing most, if not all, of their most talented and experienced staff, and hire for cheap folks who seem to not have as much good experience and knowledge of the technology their employer serves. Hostgator turned downward shortly after they were acquired by EIG, and their hosting premiums increased considerably.

    – Just my “two cents”.

    – Jim

    PS: I had pretty good experience with Namecheap for hosting, though.

  7. Jim S Smith 2019/05/24 12:21 pm

    The Let’s Encrypt SSL option was a good thought. I, like several others here, agree on the service should at least inform you when they decide to make those configuration changes, rather than just do as they see fit. Those who watch, closely, their file-access/modification times, would naturally take notice of unannounced changes to their files.

    Chalk this one up to “Professional Courtesy”.

    BTW: w3b.guru – Nice jump-off point. Very handy.

    – Jim S.

Comments are closed for this post. Something to add? Let me know.
Welcome
Perishable Press is operated by Jeff Starr, a professional web developer and book author with two decades of experience. Here you will find posts about web development, WordPress, security, and more »
BBQ Pro: The fastest firewall to protect your WordPress.
Thoughts
I disabled AI in Google search results. It was making me lazy.
Went out walking today and soaked up some sunshine. It felt good.
I have an original box/packaging for 2010 iMac if anyone wants it free let me know.
Always ask AI to cite its sources. Also: “The Web” is not a valid answer.
All free plugins updated and ready for WP 6.6 dropping next week. Pro plugin updates in the works also complete :)
99% of video thumbnail/previews are pure cringe. Goofy faces = Clickbait.
RIP ICQ
Newsletter
Get news, updates, deals & tips via email.
Email kept private. Easy unsubscribe anytime.