Web Hosts — One-Stop-Shops For Mass Hacking? 70
jjp9999 writes "More than 70,000 websites were compromised in a recent breach of InMotion. Thousands of websites were defaced and others had alterations made to give users a hard time accessing their accounts and fixing the damage. A similar attack hit JustHost back in June, and in a breach of Australian Web host DistributeIT just prior to that, hackers completely deleted more than 4,800 websites that the company was unable to recover. The incidents raise concern that hacker groups are bypassing single targets and hitting Web hosts directly, giving them access to tens of thousands of websites, rather than single targets. While the attacks have caused damage, they weren't as malicious as they could have been. Rather than defacing and deleting, hackers could have quietly planted malware in the sites or stolen customer data. Web hosting companies could be one of the largest holes in non-government cybersecurity, since malicious hackers can gain access through openings left by the Web host, regardless of the security of a given site."
Server Execution is the Issue (Score:5, Informative)
Most quality web hosting provides customers with shell access to the web server, or when cases where they don't, usually something like PHP is installed that usually allows for arbitrary execution.
On a web server that hosts a few thousand sites, using the Bing IP Search [bing.com], you can find a list of all the domains. Usually there will be a lowest hanging fruit that's easy enough to pluck. Or, if you can't get shell access through a front-facing attack, you can always just sign up for an account with the hosting company yourself.
So once you have shell, then it's a matter of being a few steps ahead of the web host's kernel patching cycle. Most shared web hosting services don't utilize expensive services like ksplice and don't want to reboot their systems too often due to downtime concerns. So usually it's possible to pwn the kernel and get root with some script-kiddie-friendly exploit off exploit-db. And if not, no doubt some hacker collectives have repositories of unpatched 0-day properly weaponized exploits for most kernels. And even if they do keep their kernel up to date and strip out unused modules and the like, maybe they've failed to keep some [custom] userland suid executables up to date. Or perhaps their suid executables are fine, but their dynamic linker suffers from a flaw like the one Tavis found in 2010 [pastie.org]. And the list goes on and on -- "local privilege escalation" is a fun and well-known art that hackers have been at for years.
So the rest of the story should be pretty obvious... you get root and defeat selinux or whatever protections they probably don't even have running, and then you have access to their nfs shares of mounted websites, and you run some idiotic defacing script while brute-forcing their /etc/shadow yada yada yada.
The moral of the story is -- if you let strangers execute code on your box, be it via a proper shell or just via php's system() or passthru() or whatever, sooner or later if you're not at the very tip top of your game, you're going to get pwn'd.
Re:VMs are cheap. Lawsuits are expensive (Score:3, Informative)
Sorry, but VMs are just a different flavor of shared hosting and your recommendation doesn't do any good. With VMs, VPS or dedicated servers hosted on a network operated by clueless network admins simply gives you a new kind of insecurities. For example, when some other dedicated server is sending out spoofed ARP replies to take over your default gateway, you do open your box to simple man-in-the-middle attacks.
And dedicated servers won't help if you're operating them with a clueless admin - and exactly those are the one's who are asking such stuff in #httpd.
I've been working at a quite large web host for more than ten years now. When taking into account the ratio of shared vs. dedicated customers, I see a higher ratio of dedicated customers being hacked every day: the number of possible insecurities is simply higher.
With "classic" shared hosting, your host is running a single kernel and relies on unix permissions to separate sites from each other: a flaw in the kernel or when setting permissions will expose the host. Having proper permissions set is an easy task (just say no to "chmod 777"), so your cracker usually has to target the kernel, usually from a local user account (e.g some "hacked" website running year-old, insecure installs of Wordpress or something else).
With VMs, your host is running a single hypervisor and relies on that hypervisor to properly separate VMs from each other: so a flaw in that hypervisor or its configuration will give the cracker full access to every VM. A (security-wise) proper configuration isn't that obvious to many guys, so this is really an issue.
What's usually required: local user access to a single VM, usually by exploiting their outdated, insecure phpBB/whatever-install.
After that, just take a look at what kind of virtual hardware you're seeing, and e.g. start googling for "vmware exploit".
However, many VMs, VPS and dedicated servers are simply poorly administrated and both shared and dedicated websites poorly operated.
I've seen a hundreds of shared hosting sites exploited within a single day via insecure, customer-installed scripts - but none of those exploiters was ever able to take over our shared hosting environment. The reason is simple: our admins actually do care about their servers, care about their own reputation and take pride in what they do. We also do develop our custom kernel patches inhouse and du manually check wether we actually do need a newer kernel (fixing old and introducing new vulnerabilities) or wether we just would like to backport those patches to our own set of kernels. We're not only running "usually" hardended systems, but customers are granted access only to a specially hardended chroot environment with hand-selected suid binaries, paranoid logfile monitoring and custom kernel patches preventing and alerting any not-whitelisted privilege escalation or any non-whitelisted uid-0-process (so far, those alerts have only been accidentally set off by interns doing their job in unexpected, not-whitelisted ways). Our systems also automatically trigger counteractions, like e.g. temporarily firewalling brute-force password cracking attempts to non-existant users and freezing strange-behaving processes on our servers. And once some notice on a possible vulnerability does come up, at least three admins in parallel do investigate those issues and think about how to solve those issues.
Within years, the most publicity on our shared hosting security was due to some guy who used an insecure, customer php-script to replace a customer's index.html with some content like
#:~$ id
uid=0(root) gid=0(root) groups=0(root)
Of course, the permissions of index.html still did belong to the customer ... and the Apache logfile clearly showed a POST to the insecure php-script with the same timestamp than the one of index.html.
We're also offering dedicated servers - who also run in a hardened environment, but still do run "usual" linux distributions and windows installs.
Hardending takes pla