This is quite ironic because I used to work in the security team at GoDaddy, writing tools to scan and clean websites infected with malicious code injected the same way. To find out that the company is using the same technique (for something less malicious?) is very surprising to me. I guess they never asked for a review of this feature to the security team, otherwise I doubt they would have approved it.
It's not unheard of. Some platforms offer New Relic RUM integration which breaks shit (like XML sitemaps).
I am guessing the hosting provider gets access to the information the client also gets, but that's just a guess without any evidence. It would just make sense in the absence of regulation.
This is something absolutely unthinkable in our company. However, we have heard of other providers using similar tactics in the past, so always do your research before trusting a provider with your website.
It's very common with features like A/B testing, analytics, advertising and CDN.
This should be inserted by the customer instead of filtering traffic, but not necessarily. It's very user friendly to only have a button to turn something on or off.
It’s pretty surprising to me that they could ship a feature like that without an enforced review by security and probably several other teams (legal and pr come to mind immediately).
The very notion that GoDaddy could be in a position to "clean" websites of malicious code is--what's the word?--stupefying? profoundly unsettling? mystifying?
If a customer’s website is being hosted in a shared account, the infection will quickly spread across the other websites in the same server unless the hosting provider takes the matter in their own hands. Years ago, it was common to simply suspend the infected website until the webmaster finished the cleanup by themselves. Nowadays, instead of suspending a website for a minor infection, some hosting providers simply clean the malicious code automatically, or offer a premium cleanup service if the infection is more complex.
> If a customer’s website is being hosted in a shared account, the infection will quickly spread across the other websites in the same server unless the hosting provider takes the matter in their own hands.
Not at any professional hosting service. It's not hard to secure the environment so that it'll take a classier attack than guessing somebody's WP login to get access to any other sites on the host.
The actual problem for hosting services is that compromised sites can be used to annoy visitors or other hosting services.
edit: okay, I don't care about the points, but I'm getting really curious why people disagree with this.
I agree. If it's possible for the infection to "spread across the other websites in the same server", then that implies that clients can access and modify each other's files, which is not the case with any shared hosting provider I've heard of.
What is more plausible is malicious server-side code eating up server resources, and that load impacting the websites of other customers, but that has its own solutions which are different from automated detection of malicious JavaScript code.
Most of the compromises I've dealt with over the years fall into just a handful of categories:
1. Data theft. So, ripping off a database or intercepting credentials while people log in.
2. Embed a link into page output which will try to download something from somewhere somehow. It might be phishing, or (usually) it's some kind of JS trying to infect the user with malware. Lazy attacks work by just popping up a convincing-enough warning message with a link that lets the user download the malware themselves, and it's effective enough.
3. Credit card theft. Using a third party service with iframes makes this harder, but not impossible.
4. Dropping some kind of web-based shell, like C99.
#1 doesn't get anybody to care. If that's all that ever happened, I'm pretty sure shared hosting providers would still be saying, "sucks to be you." #3 causes headaches for the site owner and makes them care, but still not the hosting provider.
#2 got the hosting providers' attention once Google launched Safe Browsing. Suddenly this put some of the responsibility for maintaining a safe network back onto the hosting providers. Their first solution was to just shut down sites discovered to have malicious code, but that really irritated the customers. So gradually hosting providers started trying to be a little more helpful.
#4 is a big headache for hosting providers, because those things don't get picked up automatically by Google, and the shells can be used to irritate other hosting providers, who will definitely start lodging complaints with whoever's upstream of the hosting provider.
Not on this list is, "try to infect other sites on the same server", because shared hosting environments have had easy access to a variety of tools for a long time now that prevents that. In a LAMP environment, that used to include SuexecUserGroup; more modern LAMP environments now use php-fpm and have PHP processes running from distinct unprivileged user accounts. There's also the usual php.ini values, like open_basedir, which limit access to the filesystem or to other PHP functions (allow_url_fopen).
I won't say it's impossible for an infected site to attack another site on the same server in a shared hosting context, but you'll need a get-out-of-jail card and those are harder to come by.
No professional shared host would allow one site to access or modify another site on the same server.
It's not normally the default, but there's a world of bad advice out there telling people to chmod everything to 777 so that their PHP CMS can upload files.
The situation with default file permissions is already terrible enough that no host should ever have o+x on home directories. And once you remove that, it doesn't matter if everything inside is 777.
Most hosting providers don't want to host malware, as it's against their terms. Instead of banning an account, trying to identify affected customers proactively sounds reasonable. Injecting your own code in their site does not.
It's honestly a smart thing for shared hosting providers to offer. Some years ago my co took over a bunch of legacy sites from another developer that were not tightly maintained Wordpress. We hosted the sites at the time at Rackspace Cloud Sites. The main reason we chose their antiquated hosting tier was that Rackspace support would handle infection cleanup when it happened.
It would take us time to assess everything and do up contracts for bring-up with these sites. Everything from old revslider and timthumb to more exotic infections. Once you got a file injection or reverse shell on a host, it would spread fast to everything on the server. Only way reliably back was catching when it came in and rolling it back to before then upgrading the vulnerable components.
"If a customer’s website is being hosted in a shared account, the infection will quickly spread across the other websites"
Hmm Shouldn't my hosting provider provide better isolation and separation from the bad accounts?
I work in a datacenter, and can confirm this exact setup is still quite common even recently. We used to offer our own shared hosting setup. Even though we've moved away from that service model and generally only support Cloud / Dedicated hardware, several of our customers do exactly that, leasing out our hardware and acting as a reseller for shared hosting services, sometimes using Plesk or another turnkey control panel, other times using their custom in-house software.
Unfortunately, shared hosting comes with all the risks described: if just one site on the server gets infected, everything else co-hosted on the box feels the effects, especially when the infection is something resource intensive like a cryptominer, or sends out spam emails en masse and gets the physical box on a blacklist. From an infrastructure standpoint we can only do so much; keeping the OS patched and up to date helps to curb the really nasty infections, but the reseller plays whack-a-mole with their customers, detecting infections and shutting domains down as needed.
It's a bit of a mess really. At the same time though, the economies of scale really seem to favor shared hosting from a pure cost perspective, especially for very small businesses that can't otherwise afford a technical team to manage a VPS. So, I think that market is always going to be there.
especially for very small businesses that can't otherwise afford a technical team to manage a VPS.
I’m way out of my area of expertise here. But from a management perspective, when it comes to managing a lot of VPS’s for something like WordPress, is there a simple service where the underlying OS and plug ins stay patched by the provider? I guess something like Elastic Beanstalk but simpler.
I guess there may be hosting providers that are that insecure, but I doubt it.
There are many ways you can secure and isolate the users. SuExec, grsecurity, strict security policies, 24/7 monitoring are just some of the things a reputable hosting provider would have.
Not to mention that in several cases, the managed service is run with Windows Server (think managed .asp hosting, or using a Windows-only middleware). So you have to tack on the extra resources for a Windows machine and the license costs.
Funny story (but not the ah-ah funny kind): such a service (hosting different customers on the same Windows machine) was still running in my previous company as of 4-5 years ago. They had long moved from physical hosts to VM, but were stuck with the legacy CMS/control panel which was more or less unpatchable (as in, the software editor didn’t exist anymore). About once a week, one of the host VMs would be taken over by hackers using one exploit or another. In that case they would kill the VM, boot a fresh one from a clean image, and start serving the customer data again after making sure it was clean. The service was not sold anymore but they had long-running customer contracts. It wasn’t making enough money to justify rebuilding it with modern software, but it was making enough that simply killing it wasn’t an option.
I was exclusively a Windows developer for 20 years - using Windows as a development and deployment platform. The cost of Windows in terms of licensing and resource was someone else’s problem.
It wasn’t until I started architecting and developing in cloud environments that the true cost of Windows became apparent - when the cost of every project I do can more or less be directly tied to me.
I still development on Windows but I found an appreciation for deploying to Linux.
Don’t get me wrong, I’m not new to the field and in hindsight it makes perfect sense, but back then, I worked for corporations that hosted their own servers and never needed to host a site for a personal/small company.
By the time I got to the point where I would think about doing something on my own, VPS hosting was so cheap, I wouldn’t have thought about anything besides a VPS like Linode.
None of this is true. VPSes have existed since the early 2000s and have been in common use since the mid 2000s; Linode was founded in 2003, for instance. Shared hosting was popular because it cost pennies, whereas VPSes would run you $30+/mo, which of course is more like $5+/mo now.
Linode's kind of expensive. I've been using VPSDime [1] for a few years, since they give us 6 GB of RAM for $7 a month. For smaller stuff, I've been happy with RamNode [2], which is $3.50 a month for 1 GB of RAM. And you can usually find good deals on Low End Box [3]. Of course, at those price points, everything is OpenVZ, which is kind of annoying.
The vast majority of Wordpress deployed in the world (and there's a lot more of it in general than we tend to see in the high tech community) exists on a WHM server, which basically deploys an Apache vhost for every site.
There's a thing called Cloudlinux, which is an additional licensed feature that provides resource fencing, but its a lot less capable than advertised ime.
Moreover, many end users rush to chmod 777 their installation because there's a lot of guides out there telling them to do so. There are also highly rated Wordpress plugins that do this silently because developers read those guides.
If someone takes control of their website and puts malicious stuff on there, GoDaddy being able to ask the customer “Hey, did you mean to do that?” and helping them roll it back is handy.
A lot of SQL injections are malicious ad scripts that will be named the same on each hack. It would be pretty easy to remove something like that as it passes back through Godaddy's router. I would hope they notify the website owner because otherwise you wouldn't know that you have a problem.
