Hosting a web site in a shared hosting environment is many things: cheap or even free (hey, where is this site hosted?), easy to setup, and with tools like Plesk and CPanel, easy to administrate. However what it is definitely not is secure.
The perils of PHP, SQL Injection, and other security issues are well documented:
But this story is about something much more simpler and requiring much less technical tinkering, the ability to have content from another customer’s account referenced from your custom domain.
While working in my unofficial role as IT advisor to a dear friend’s company, I was contacted to help track down a security issue they were facing. This issue started with the receipt of an email from Google. (The name of the company and the shared hosting provider have been changed to protect the innocent and the guilty, respectively.)
From: noreply@google.com
Date: January 24, 2011 10:02:23 AM PST
To: abuse@myDomain.com, admin@myDomain.com, administrator@myDomain.com, contact@myDomain.com, info@myDomain.com, postmaster@myDomain.com, support@myDomain.com, webmaster@myDomain.com
Subject: Phishing notification regarding myDomain.com
Dear site owner or webmaster of myDomain.com,
We recently discovered that some pages on your site look like a possible phishing attack, in which users are encouraged to give up sensitive information such as login credentials or banking information. We have removed the suspicious URLs from Google.com search results and have begun showing a warning page to users who visit these URLs in certain browsers that receive anti-phishing data from Google.
Below are one or more example URLs on your site which may be part of a phishing attack:
http://www.myDomain .com/~ouzelc5/admin.poster.php?check=3
Here is a link to a sample warning page:
http://www.google.com/interstitial?url=http://www.myDomain.com/~ouzelc5/admin.poster.php?check=3
We strongly encourage you to investigate this immediately to protect users who are being directed to a suspected phishing attack being hosted on your web site. Although some sites intentionally host such attacks, in many cases the webmaster is unaware because:
1) the site was compromised >2) the site doesn’t monitor for malicious user-contributed content
If your site was compromised, it’s important to not only remove the content involved in the phishing attack, but to also identify and fix the vulnerability that enabled such content to be placed on your site. We suggest contacting your hosting provider if you are unsure of how to proceed.
Once you’ve secured your site, and removed the content involved in the suspected phishing attack, or if you believe we have made an error and this is not actually a phishing attack, you can request that the warning be removed by visiting
http://www.google.com/safebrowsing/report_error/?tpl=emailer >and reporting an “incorrect forgery alert.” We will review this request and take the appropriate actions.
Sincerely,
Google Search Quality Team
Note: if you have an account in Google’s Webmaster Tools, you can verify the authenticity of this message by logging into https://www.google.com/webmasters/tools/siteoverview and going to the Message Center, where a warning will appear shortly.
First, cudos to Google for performing this service. If it wasn’t for the communication from Google this problem would have likely gone unnoticed.
Before going any further, some disclosure: I’m not a UNIX admin or server god. I live and work in the database tier and only tinker outside of that domain. So forgive me if I’m stumbling through the obvious here.
My first reaction was to start with the basics. I instructed them to change passwords though knowing if they were compromised it was going to be more complex than that.
I then started to look at the site to see if any files had been changed or if unexpected content was being hosted in their directory structure. That review turned up some files that were unnecessary given the state of their web presence but nothing to account for the malicious content.
I checked the activity in the web logs and saw other URLs being accessed:
~fantom5/prep/bofa.com/safe.ssl.confirm.onlinebankingofamerica.com/index.cfm_files/foot_lock.gif
That’s when the “~ouzelc5” and “~fantom5” in the URLs came into focus. As is common on shared hosting, the provider provides a method to access your site prior to the creation or configuration of your domain name. In their case it was a URL like this:
http://server123.theSharedHostingProvider.com/~myDomainAccountName
The shared hosting services didn’t let us create other user accounts so the “~ouzelc5” and “~fantom5” must be referring to other user accounts on the same server. What puzzled me though was the ability to reference data from those accounts through our domain name. That just could not be right. The black hat was using our domain to display malicious content without actually putting any content into or having any access to our account.
The next step was to contact tech support at the hosting provider. They confirmed that another customer’s account on the server was compromised. No kidding. The follow-up question: what about the ability to access their content from our domain, regardless of their site being compromised? The response:
From: “Tech Support”
Date: 25 January 2011 6:58:14 PM PST
To: info@MyDomain.com
Subject: Re: {100-684423} Fwd: Phishing notification regarding MyDomain.com
Hello,
Thank you for contacting us. I apologize for the inconvenience this has caused. The main issue was that an account that is located on the same server as you was compromised with a phishing scam. The individuals that placed the phishing scam on the server then proceeded to use the URLs of others accounts that are located on the server with the /~ouzelc5/ added to the URL. This makes the URL cited in the google email to you actually go to the other customers account. This content is not on your account in any form.
We have taken measures to disable this activity on the server at this time so you should no longer see this URL functioning and can respond to the notice from Google to have your site rechecked and delisted from their malware lists.
The actual behavior that you were seeing is how the temp URL works, and it is not possible turn it off at this time. I apologize in advance for that.
Please feel free to contact us if you have any further questions.
I don’t know if this a pervasive issue with shared hosting providers. As one that works in the software field, with such a fundamental flaw I don’t know how the software solution used by this particular provider was deemed to be a acceptable. Well, then again I can totally see how the issue could either be unknown, ignored, or the risks determined to be low. For us as a shared hosting customer, our collective eyes have been opened to the issues we face and the need to be diligent in monitoring our internet presence.
