Slashdot Mirror


Web Hosts — One-Stop-Shops For Mass Hacking?

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

10 of 70 comments (clear)

  1. unable to recover? by joshuac · · Score: 4, Insightful

    completely deleted more than 4,800 websites that the company was unable to recover

    They host (at least) 4,800 websites yet they don't have a working backup system in place? Amazing.

    1. Re:unable to recover? by guruevi · · Score: 2

      You would be amazed at how much data gets lost daily because enterprises are unable to keep a working backup system.

      I've worked for a web host and the more money they threw at their backup solution (this one is shiny, this one is integrated with your management platform, this one gives control to your customers, this one gives blowjobs, ...) the more unpredictable it got. They would fail to complete and/or fail to notify, 1 tape would fail and apparently the metadata for the whole backup was on that 1 tape. Or it would correctly back up everything but the restore would take a week (which was suicide for a lot of dotcoms).

      I eventually wrote an rsync script to backup to a disk system and told the developers how to parse the logs and deploy it. Sure it wasn't shiny, no such thing as bare metal restore and didn't have a lot of other features but it f*in worked. I then also learned that singular tapes are relatively expensive and about as reliable as a medium as your average hard drive.

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
    2. Re:unable to recover? by Oxford_Comma_Lover · · Score: 2

      Why would it need a "right to leave its systems vulnerable to penetration?" You could as easily say that "customers of hosting providers don't have a right to rely on the security of providers." You have to pick where to allocate responsibility. As the hosting provider usually writes the contract, guess where responsibility usually lies?

      --
      -- IANAL, this isn't legal advice, and definitely isn't legal advice for you. Also, Squee!
    3. Re:unable to recover? by FreakyGreenLeaky · · Score: 2

      Nonsense. Incremental rsyncs with periodic full rsyncs is a perfect, more efficient and faster backup system. Importantly, recovery is lightning fast compared to tape. Do some research: you can rsync only files which have changed, or everything. With a simple script on the backup machine which uses redundant storage (or machines, some offsite) you can archive these snapshots by day, week, month, whatever.

      We haven't used tape for over a decade and recovering a specific file with a specific timestamp or doing a mass recovery is just as simple - and quick.

      Your post smacks of so many who have drunk the The Backup Company (tm) koolaid and who refuse to believe that a better system exists. You're an IT manager, right? :D

  2. Server Execution is the Issue by zx2c4 · · 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, 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. 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.

    --
    ZX2C4
  3. Re:Wild West by fermion · · Score: 2
    I do not think that the low price represents security, I think it represents uptime and general service. I have used services with low prices and the only issue was uptime. I suppose for very low price services there might be an issue with backups. I also suppose with very low prices, there is going to be an issue of bandwidth and processing power.

    As has been shown, even the high end services are extremely vulnerable to attacks. No one seems to have that core competency, or at be willing to pay for it.

    --
    "She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
  4. VMs are cheap. Lawsuits are expensive by preaction · · Score: 3, Insightful

    Every day someone comes into #httpd on freenode asking "How do I protect one user's site from another user's site when both are using PHP or CGI or whatever else?" and the answer is invariably "It will cost too much to bother."

    If you are a business and you are taking in customer information, you should be held responsible when another user on that server actually figures out how much money that information is worth.

    There is no excuse. A VM is about $20 a month. A DynDNS account is less. Shared hosting is for personal home pages, not businesses.

    1. Re:VMs are cheap. Lawsuits are expensive by ista · · 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

  5. Re:WARNING: The summary is WRONG! by mrbester · · Score: 2

    Don't you try to out-weird me. I get stranger things than you free with my breakfast cereal.

    --
    "Wait. Something's happening. It's opening up! My God, it's full of apricots!"
  6. insider information here by bsDaemon · · Score: 3, Interesting

    I was going to mod, but I decided to post instead. I used to work at one of the companies mentioned, and what I hear through my channels is kind of retarded. One of the so-called "admins", who really ought to have known better, set up a tunnel from a personal VPS to an internal machine which had no internet-accessible address -- just the tunnel. The VPS got popped and that gave them access to an internal machine which had SSH keys as root to every single VM node and shared hosting box, as well as every dedicated machine on which the customer didn't have root access.

    All the VPS accounts were vulnerable, because the host nodes were compromised, so even if a VPS customer had root, they were vulnerable, too. However, that was the kind of irresponsible, non-professional crap that I saw going on there and is why I left about 2 years ago: I assumed that the longer I stayed, the more likely it was to tarnish my reputation and ruin my career. Well, that and the fact they paid for shit and worked my like a salve tied to a shift bench on a factory floor. But then, I don't really know what anyone can expect web hosting is pretty much the fast food of it, and that's the level of talent that one can reasonably expect to retain for very long, or attract in the first place in most cases.

    Some how the VPS that I left hosted there didn't get whacked, though. I guess they just forgot about me.