Update: NameCheap has fixed this vulnerability and has published a statement about it. See the end of this article for more.

An email from Google in my inbox caught my attention this morning:

Alert – Hacked content found on http://www.kirkville.com/

I use Google Analytics to track traffic to my websites, and one of its features is to warn you when there is potentially malicious content on your sites. The email listed three example pages that had “hacked” content; each of them used a URL that ended with my domain name, kirkville.com, but begin with a subdomain. They were of the form:

sub.domain.kirkville.com

A sub-domain is a domain that belongs to a top-level domain, but can be treated differently; www is a sub-domain, for example, as are ftp, mail, and others that are commonly used. A sub-domain could also host a forum or a blog, or it could be a testing server. For example, I used to run an iTunes forum at forum.kirkville.com.

You manage sub-domains on your web host’s server; in my case, I’m hosted by NameCheap, and I use Cpanel to manage domains, sub-domains, user accounts, and much more.

So my first step was to log into Cpanel and check. There were no sub-domains that I had not created; neither of the sub-domains that Google told me about were listed. I updated my Cpanel password, in case my account had been compromised. (I use two-factor authentication for that account, so this seemed unlikely.)

I then contacted NameCheap support via chat, and explained the problem. After about a half hour, I was told that “… the issue was caused by the misconfiguration on our nameservers. Your account access appears to be non-affected.” The support technician continued, “In short, it was another user that added the subdomains to their hosting account.”

Somehow, through mis-configuration of NameCheap’s namesevers – that’s the DNS servers that map domain names to numerical IP address – users were able to create sub-domains on any account that was also hosted by NameCheap. Even though I have SSL on my website – meaning that it uses https instead of http in its URL – and any incoming traffic to ht​tp://www.kirkville.com is automatically redirected to the https version of the site, the sub-domains were parsed by name servers before they reached my site’s server, so they weren’t redirected.

This is a very serious security breach. I wonder how many other people this may affect. If you use Google Analytics, you will likely receive a similar email if your domain has been used like this. But if not, you have no way of knowing.

Why would someone do this? In an attempt to piggy-back on your site’s popularity on Google or other search engines. If you get a lot of traffic, the bogus pages set up on the sub-domain may inherit some of your website’s prominence, allowing malicious users to serve spam or malware, or to make money by displaying Google ads. Interestingly, even though Google flagged these pages as “hacked content,” they were still serving Google ads; as if Google really doesn’t care how they make their money.

One could also copy the design of a website, making it look like the original, using it to trick users into giving up user names and passwords – arguably not an issue with my site, where user accounts are only used for commenting – or to scam people, if the site pretends to be one that sells goods.

NameCheap has told me that this issue is resolved, and the sub-domains are no longer accessible.

I will be reaching out to NameCheap to ask the following questions:

How many users are affected by this?

Will you be alerting all NameCheap users?

What safeguards will you put in place to prevent this from happening again?

I will update this article if NameCheap replies to these questions, or has any statement to make.

Update: Late Monday, NameCheap told me the following:

“I would like to inform you that we have implemented a permanent fix to secure domains on our servers. The parch [sic] has been rolled out on all shared servers thus similar issues should not occur any more.”

It’s worth noting that, on Twitter, they said, “Additionally, this affected a teeny tiny group of users of our web hosting service, and anyone registering domains are completely safe.”

I am hoping to find out how many are in a “teeny tiny group.”

Update (Feb 7): Here’s a follow-up article on this issue on The Register.

NameCheap has still not sent any official notification to users regarding this; at least none that I’ve received.

Update (Feb 7, later): The CEO of NameCheap has has provided more information about this issue in a series of tweets replying to my tweeting of the above Register article. He clarified how many users were affected:

Any domain using our shared hosting product were [sic] vulnerable. None of the domains using our regular domain dns. Less than 200 were exploited.

He underscores the fact that their “regular domain dns” wasn’t affected; that’s the domain names they host as registrar, but for sites that are not on their shared hosting.

Update (Feb 7, still later): NameCheap has published an update on this incident, explaining that their custom DNS settings resulted in a gap in their security. They confirm that they have fixed the issue, and claim that it only affects 12 domains. So when I discovered this – thanks to Google Analytics – it was the very beginning of the exploitation of this vulnerability, and had I not been using Google Analytics, I would likely have not have found out about this.

(Thanks to Graham Cluley for his help understanding this issue and for providing comments on a draft version of this article.)