×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Hosting Provider Automatically Fixes Vulnerabilities In Customers' Websites

Soulskill posted about a year ago | from the what-could-possibly-go-wrong dept.

Security 73

An anonymous reader writes "Dutch hosting provider Antagonist announced their in-house developed technology that automatically detects and fixes vulnerabilities in their customers' websites. The service is aimed at popular software such as WordPress, Drupal and Joomla. 'As soon as a vulnerability is detected, we inform the customer. We also explain how the customer can resolve the issue. In case the customer does not respond to our first notice within the next two weeks, we automatically patch the vulnerability.' Antagonist plans to license the technology to other hosting providers as well."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

73 comments

Why not fix it immediately? (3, Insightful)

loufoque (1400831) | about a year ago | (#42050729)

In two weeks it might be too late.

Re:Why not fix it immediately? (5, Interesting)

sabri (584428) | about a year ago | (#42050773)

In two weeks it might be too late.

You're talking about customer data here. They may have some customizations in the code that break if you allow yourself to patch it.

I would take another approach: disable the vulnerable file until the customer fixes it. By fixing it for them you may generate expectations which you'll not be able to match in the long run: "don't worry about software updating, the hosting company will do it for us".

Re:Why not fix it immediately? (3, Interesting)

loufoque (1400831) | about a year ago | (#42050795)

It would have to detect that it can safely apply the patch. Also it could be opt in, of course.

Re:Why not fix it immediately? (-1)

Anonymous Coward | about a year ago | (#42050871)

Have you ever fantasized about sucking a thick black dick, inhaling the pungent scent from beneath his well-hung, potato-sized balls and wrapping your long tongue around them as Jar Jar Binks would?
 
  Have you ever tongued the tip and have enveloped the large dark mushroom until it throbs and squirts thick, hearty chlorinated goo down your gulping gullet? Do you go "Hlllurrrgh" when it is too much for you to guzzle down and does it then drip all over the front of your shirt? Have you ever asked for seconds afterward?

Me Neither. Posted from my Mac.

Re:Why not fix it immediately? (0)

Anonymous Coward | about a year ago | (#42051231)

In two weeks it might be too late.

You're talking about customer data here. They may have some customizations in the code that break if you allow yourself to patch it.

I would take another approach: disable the vulnerable file until the customer fixes it...

Er disable the vulnerable file? You either seem to be confusing an infection for a vulnerability, or you have no idea how web services like this actually work.

Try "disabling" a few .ini files and I'm certain you'll have the customer calling alright, but they won't be the ones fixing a damn thing.

Re:Why not fix it immediately? (1)

crutchy (1949900) | about a year ago | (#42051899)

you can prevent access to individual files easily enough (in apache anyways)

will it likely break the customer's site, sure it will, but it will also jolt them into action

while it may seem that the customer would be reasonably pissed off, you could have it as a clause in the signup agreement that if a vulnerability was found the vulnerable file will be made inaccessable till the vulnerability is patched... after all it may be their website, but its the service provider's hosting infrastructure. it would be no different if you rented a car to someone and they kept leaving the keys in it whenever they got out

What action? (1)

Taco Cowboy (5327) | about a year ago | (#42051973)

will it likely break the customer's site, sure it will, but it will also jolt them into action

Yep, it sure will jolt them into action ... in court
 
It would be extremely foolish to forget that we do live in a sue-happy world
 

Re:What action? (1)

crutchy (1949900) | about a year ago | (#42052041)

It would be extremely foolish to forget that we do live in a sue-happy world

not as foolish as assuming that the US means the world

Re:What action? (1)

Taco Cowboy (5327) | about a year ago | (#42052269)

Try UK, Australia, France, Germany, Japan, Korea, Hongkong, Singapore ...

You think lawyers in countries other than the good ol' US of A just sit there all day and do nothing?

Re:What action? (1)

pgdave (1774092) | about a year ago | (#42053321)

Try UK, Australia, France, Germany, Japan, Korea, Hongkong, Singapore ...

You think lawyers in countries other than the good ol' US of A just sit there all day and do nothing?

If you mean 'Nothing useful', Yes :0)

Re:Why not fix it immediately? (1)

sabri (584428) | about a year ago | (#42060045)

Er disable the vulnerable file? You either seem to be confusing an infection for a vulnerability, or you have no idea how web services like this actually work.

Yes. A simple chown root:wheel and chmod 000 will usually do the trick*. And I'm pretty familiar with webhosting services, I used to work for the largest hosting provider in that country.

*yes, I know that is easily circumvented. However, someone proficient enough to circumvent that would be proficient enough to fix the root cause as well.

Re:Why not fix it immediately? (1)

cultiv8 (1660093) | about a year ago | (#42051309)

I would take another approach: disable the vulnerable file until the customer fixes it. By fixing it for them you may generate expectations which you'll not be able to match in the long run: "don't worry about software updating, the hosting company will do it for us".

The issue is not so much as "disable the file" but rather "disable the module/plugin/extension", which would be even worse if this happened automatically.

Re:Why not fix it immediately? (0)

Anonymous Coward | about a year ago | (#42051337)

In two weeks it might be too late.

You're talking about customer data here. They may have some customizations in the code that break if you allow yourself to patch it.

I would take another approach: disable the vulnerable file until the customer fixes it. By fixing it for them you may generate expectations which you'll not be able to match in the long run: "don't worry about software updating, the hosting company will do it for us".

There's no guarantee that an unpatched website is responsible for any damage. I think this approach is fantastic. It sure beats letting problems to unaddressed, and the hosting service is being both altruistic and respectful. They could even charge for automatically patching sites as a service.

Bully!

Re:Why not fix it immediately? (3, Insightful)

Anubis IV (1279820) | about a year ago | (#42051449)

So, if you're running WordPress or a popular message board (e.g. phpBB, vBulletin, whatever, take your pick) and the developer releases a general security update that applies to everyone, you'd be fine with your host disabling essentially your entire site until you fixed it? And if you're on vacation for a week or two when it happens? What then? I rather like the fact that the stuff I run can essentially sustain itself in my absence.

I might be okay with it if it was in the terms of service and the customer had been given fair warning that their site would be disabled if they didn't take action (though I'd never host with them). I may also be okay with it in cases where a vulnerability is actively being exploited and it's causing some form of harm to the host. But to pro-actively disable "vulnerable files" which may be necessary to the functioning of a site without first providing notice is not something that I could condone. I'm still undecided on even having them apply their own fixes, to be honest.

Re:Why not fix it immediately? (2)

Bios_Hakr (68586) | about a year ago | (#42054541)

>>the developer releases a general security update that applies to everyone, you'd be fine with your host disabling essentially your entire site until you fixed it?

It all depends on the TOS from the host. Maybe the host declares that they disable clients that are contributing to (or may contribute to) network abuse. Unpatched machines will get compromised and become launchpads for attacks on others.

>>And if you're on vacation for a week or two when it happens? What then?

Would you rather come back from vacation to a disabled but uncompromised site, or to a enabled but compromised site? For the first case, you'd need to apply the updates and then restart the server. For the second case, you'd need to scrub the machine, re-install all your software and customizations, then restore your databases and content directories from backup.

>>I rather like the fact that the stuff I run can essentially sustain itself in my absence.

The point is, it can't. You can't secure a box and walk away for days/weeks/months. You need to be actively maintaining your servers.

Re:Why not fix it immediately? (2)

Anubis IV (1279820) | about a year ago | (#42055253)

Would you rather come back from vacation to a disabled but uncompromised site, or to a enabled but compromised site?

Oh, the first, no doubt, but that's missing the point by setting up a false dichotomy. The third possibility, and the far more likely one, is that I'll simply return to a vulnerable, uncompromised site, and will have time to patch it on my own terms. Again, I'm speaking purely about personal sites here, and it's not as if every single phpBB forum running X.Y gets compromised the day after X.Y+1 gets released. I should have time to decide whether X.Y+1 is right for me or not, as well as investigate the issues I might encounter with upgrading. By taking that decision away from me, my hand gets forced in ways that could impact my visitor's ability to use my site.

Re:Why not fix it immediately? (1)

sabri (584428) | about a year ago | (#42059387)

So, if you're running WordPress or a popular message board (e.g. phpBB, vBulletin, whatever, take your pick) and the developer releases a general security update that applies to everyone, you'd be fine with your host disabling essentially your entire site until you fixed it? And if you're on vacation for a week or two when it happens? What then? I rather like the fact that the stuff I run can essentially sustain itself in my absence.

I might be okay with it if it was in the terms of service and the customer had been given fair warning that their site would be disabled if they didn't take action (though I'd never host with them). I may also be okay with it in cases where a vulnerability is actively being exploited and it's causing some form of harm to the host. But to pro-actively disable "vulnerable files" which may be necessary to the functioning of a site without first providing notice is not something that I could condone. I'm still undecided on even having them apply their own fixes, to be honest.

I partly agree with you. If it is a general security update that is not actively being exploited: let it be. However, if it concerns a widely exploited problem, then yes: disable either the vulnerable script or the entire website, if you are hosted on a shared platform. Reason for this is that your script may open the entire server for malicious users and be a stepping stone to exploit local vulnerabilities. So by keeping your vulnerable site enabled, the hoster would be risking damages to all other sites hosted on that system. If I'm the hoster, I would prefer having 1 lawsuit with a good chance to win rather than tens of suits for negligent behavior.

Re:Why not fix it immediately? (0)

Anonymous Coward | about a year ago | (#42051565)

So, this is a derivation of a one-click installation software (Installatron, Fantastico) that mandates patches instead of permitting clients to selectively opt-in thereby irrevocably breaking certain modifications?

Great.

Re:Why not fix it immediately? (1)

crutchy (1949900) | about a year ago | (#42051925)

who's forcing anyone to use any particular hosting provider? if a customer doesn't like what they're paying for, they should move on or stfu. changing dns records isn't rocket science.

Re:Why not fix it immediately? (1)

spongman (182339) | about a year ago | (#42051951)

They may have some customizations in the code that break if you allow yourself to patch it.

yeah, 'cos it's not going to break when someone hacks the shit out of it...

Re:Why not fix it immediately? (0)

Anonymous Coward | about a year ago | (#42051757)

Because they want "license fees" from standard business practices "on a computer" and other legal mumbo jumbo.

Re:Why not fix it immediately? (1)

gagol (583737) | about a year ago | (#42053093)

Would be hard to enforce patent in court, they are not the first provider to suggest web applications upgrades to their customers. Patenting upgrading a web app after two weeks is a very long shot.

What can possibly go wrong? (2)

adius (613006) | about a year ago | (#42050763)

The road to hell is paved with good intentions

Re:What can possibly go wrong? (1)

spongman (182339) | about a year ago | (#42051959)

i think the good intention here is letting a vulnerable site with vulnerable user data stay accessible from the internet.

Doing business with a company named 'Antagonist'.. (1)

noobermin (1950642) | about a year ago | (#42050765)

It doesn't help that their logo is colorful.

Re:Doing business with a company named 'Antagonist (1)

c0lo (1497653) | about a year ago | (#42051427)

It doesn't help that their logo is colorful.

Well, can be worse... imagine the doing business with the Contrarian [slashdot.org]

not new (0)

Anonymous Coward | about a year ago | (#42050767)

Webfaction has been doing doing automated notification for several years... I also don't like the thought of my provider forcing patches on me. What if I have implemented an alternative fix because the official fix breaks my site?

Re:not new (0)

Anonymous Coward | about a year ago | (#42050893)

I suppose you could use those two weeks to tell them that you're working on your own fix. At least you would have responded.

Liability (2)

rebelwarlock (1319465) | about a year ago | (#42050771)

Seems like they could end up with a lawsuit on their hands. What happens when a customer gets hit with a previously undiscovered WP exploit, after their host had already told them that they patched all the WP vulnerabilities?

Re:Liability (4, Insightful)

Njovich (553857) | about a year ago | (#42050891)

They probably claim no such thing as having patched all WP vulnerabilities. Also, keep in mind that culture in Netherlands is really not to sue people for any minor thing (and if there was a lawsuit, damages awarded would be quite proportional, and costs are lower than some other countries).

will it automatically convert feet to meters ??? (1)

Anonymous Coward | about a year ago | (#42050775)

just curious, will it convert feet to meters ???

Re:will it automatically convert feet to meters ?? (1)

viperidaenz (2515578) | about a year ago | (#42051007)

Why do you want that? If you're spelling metre "meter" you're American, so isn't feet more appropriate? Unless you're not talking about distance and want to convert the feet of an animal into an instrument for displaying data.

Re:will it automatically convert feet to meters ?? (0)

Anonymous Coward | about a year ago | (#42051161)

I spell it that way to... am i an american as well?
Kidding aside, i never realy liked how "metre" sounds really. maybe thats why?

Re:will it automatically convert feet to meters ?? (1)

Anonymous Coward | about a year ago | (#42051233)

you misspelled "to" and "realy" in a two line post... so if you aren't American, then I'm going to go with illiterate.

Re:will it automatically convert feet to meters ?? (1)

Anonymous Coward | about a year ago | (#42051217)

If you assume the britts are the only ones using "metres" you're an american, it's spelled meter in most other languages.

Re:will it automatically convert feet to meters ?? (1)

mcgrew (92797) | about a year ago | (#42058491)

Well DUH. A meter is only a few inches longer than a yard, just multiply by three. If you need accurate measurements, use a meterstick instead of a yardstick.

Thanks for your help (2)

RobbieCrash (834439) | about a year ago | (#42050789)

I'll be finding a new host now.

You're not being paid to view my site or make changes to it, let me know and shut it down if it becomes a problem; keep your fingers out of my site.

Re:Thanks for your help (5, Insightful)

Njovich (553857) | about a year ago | (#42050935)

At this point, if you want control over your site you can easily run some kind of VPS. If you use shared hosting, do you really want to share your server with a bunch of vastly outdated joomla and wordpress sites? This constitutes the majority of sites on your average shared hosting provider... leading to potential escalations to other sites (not always true, but it's possible), being used to host or send spam, leading to blacklisting of the server on spam lists etc.

Re:Thanks for your help (1)

RobbieCrash (834439) | about a year ago | (#42051319)

Yeah, you're right. Reading the article I assumed it was a VPS, but after browsing the rest of the site I get that it's a new Anglefire or whatever. That's something I have no issue with. I read the article assuming it was OS level patching. This I don't care about.

Re:Thanks for your help (2)

pipatron (966506) | about a year ago | (#42051391)

Why would you find a new host when you're obviously not a customer at the hosting provider implementing this change? Or did you mean that you want to change from your current one to actually use this new, because you approve of the changes? Your two messages here are very conflicting.

Re:Thanks for your help (0)

Anonymous Coward | about a year ago | (#42051479)

he was talking shit.
nothing new here. guy had a kneejerk response to something he isn't even involved in so he had to talk about how they lost his business when he wasn't ever a customer...

Re:Thanks for your help (1)

viperidaenz (2515578) | about a year ago | (#42050971)

Why are you finding a new host?
You should have read terms and conditions you agreed to when you signed up. You are paying them to view your site and make changes to it. It's part of the service you're paying for.

Re:Thanks for your help (2)

LordLucless (582312) | about a year ago | (#42050975)

The Slashdot headline looks to be a bit exaggerated. This sounds like they're just auto-patching certain versions of some software. They're not "detecting vulnerabilities", they're detecting your software version. Any pure-play hosting services (ie: a dedicated wordpress host) have been doing this for ages.

Re:Thanks for your help (1)

yoduh (548937) | about a year ago | (#42051143)

There are software packages out that watch files that are being touched and scan them for known matches, viruses, etc and can quarantine them. Also software that watches out for relaying of emails and scripts sending out a ton of email (spam). A decent shared hosting company already does these two things. Common practice would be to disable the malicious code if it's still there (a lot of bots upload, execute, then remove the files) or reset compromised passwords and notify customers of what's going on. Let the customers deal with their own stuff. It's way to messy to force these types of upgrades on them, with the exception of maybe known exploits - like automatically replacing outdated timthumb.php code.

Re:Thanks for your help (0)

Anonymous Coward | about a year ago | (#42054999)

So you can keep on doing exploits from it? Go away malware-maker/bot-herder.

Good idea, wrong solution (2, Interesting)

Anonymous Coward | about a year ago | (#42050939)

Having dabbled with running shared hosting for 10+ years, there is a very clear business need for something like that.

The first line of defense for the web hosting company is to set security layers so that when a website gets hacked, only that account is compromised. Most respectable host can do that now.

But where does that leave you when a website gets compromised? Sure, the hack is contained to that account only, but still, script kiddies are running all kind of stuff on that account, and you have no other choices but suspend that account, and write an explanation letter to the customer.

And then what? The small business owner has no effing clue what the hell you are talking about and is furious that his website is down. You then proceed to explain that his site is hacked, and that nothing on it can be trusted no more. Does he have a clean backup? Of course not.. He contacts his buddy that set up the site 2 years ago. He has no clue of course. Blames the host for suspending the site of not being secure enough.. Buys some cheap hosting elsewhere and moves the site away from you.

This is a LOOSE LOOSE situation...

SO: I clearly see why they are being pro-active on this problem. There is a certain market segment of the shared hosting business that can benefit. That being said, I much, much prefer the mod_security approach, which works as a filter on the HTTP layer, to mitigate most script kiddies and automated hacks, which covers pretty much all the potential hacks these small websites can be targeted with and has much less potential side-effects.. Modifying customer data is a big no-no IMHO...

Re:Good idea, wrong solution (-1)

Anonymous Coward | about a year ago | (#42051145)

that's lose-lose, you retard.

Re:Good idea, wrong solution (-1)

Anonymous Coward | about a year ago | (#42051237)

sry. I am french, and slightly retard.

Re:Good idea, wrong solution (-1)

Anonymous Coward | about a year ago | (#42051701)

Sentences begin with a capital letter, you ignorant fuck.

Re:Good idea, wrong solution (3, Informative)

wvmarle (1070040) | about a year ago | (#42051509)

They do not modify customer data; only the software that runs the customer's sites. Which to me is totally cool as of the reasons to use a shared hosting site would be to not have to worry about the software that runs it.

Re:Good idea, wrong solution (2)

BradleyUffner (103496) | about a year ago | (#42052099)

They do not modify customer data; only the software that runs the customer's sites. Which to me is totally cool as of the reasons to use a shared hosting site would be to not have to worry about the software that runs it.

If you modify the code that writes the data you could be indirectly modifying the data.

Re:Good idea, wrong solution (0)

Anonymous Coward | about a year ago | (#42057167)

The software that runs the customer site is stored in files (php scripts for example) and is part of the 'data' the web host is caring for.
Modifying a customer website is modifying their data, to me it is the same.

Re:Good idea, wrong solution (0)

Anonymous Coward | about a year ago | (#42057243)

That's no better. At my workplace, we recently had a vendor decide they could remote in and make patches to our production system without our permission. Guess what? They broke it, resulting in an emergency downtime and headaches for several of our IT analysts and admins. The vendor immediately got all remote access revoked except for times when they are hired to do so. Of course, they're very unhappy that they don't have free reign on that server anymore, but that's just too bad. It's a risk and liability for us. We're a hospital. We don't like that much risk.

Re:Good idea, wrong solution (2)

toygeek (473120) | about a year ago | (#42051941)

You nailed it right on the head. The customer will just take their crappy outmoded php or perl or whatever to some other host who will gladly take their money. I was in web hosting as a sysadmin for several years. I had a customer who had built his website in php, and very poorly. You could to http://hisjackasswebsite.bizfo/index.php?myawesomemalwaresite.com/virus.asp [hisjackasswebsite.bizfo] and frame ANY site into his. He refused to believe it was his problem, even after I proved it to him first hand. So, I suspended his site (I was getting sick of getting that server blocked on sorbs etc) and he went somewhere else. I contacted his new provider and let them know the score and advised them to watch out. They were actually thankful for the heads up. Could this program have fixed that? Doubtfully. Will the problem persist? Yes. Because people are lazy and cheap!

Re:Good idea, wrong solution (0)

Anonymous Coward | about a year ago | (#42053563)

You could to http://hisjackasswebsite.bizfo/index.php?myawesomemalwaresite.com/virus.asp [hisjackasswebsite.bizfo] and frame ANY site into his. He refused to believe it was his problem

Obviously it's a feature, not a bug.

Re:Good idea, wrong solution (1)

mcgrew (92797) | about a year ago | (#42059615)

This is a LOOSE LOOSE situation...

I don't know, it seems pretty tight to me.

It's nice to have the option (0)

Anonymous Coward | about a year ago | (#42051255)

But please, let me have the option to say, in advance, "take no action" or, at a minimum, "take no action unless my web site is causing harm to others, in which case, just reroute it to a backup site."

Detection is nice, auto-patching leads to trouble (1)

aggemam (641831) | about a year ago | (#42051287)

We do the same where I work (detection part only), but wouldn't touch customer data. So the most we can do is warn the customers.

This isn't new (0)

Anonymous Coward | about a year ago | (#42051975)

I've had this happen with clients I've moved to WP Engine here in the USA and it is becoming more common. They only give a week to delete offending plug ins before they'll do it for you.

Licensing (0)

Anonymous Coward | about a year ago | (#42052151)

"Antagonist plans to license the technology to other hosting providers as well"

License the technology, also know as 'patch'. Well, at least they didn't patent it.

Easy! (1)

dkf (304284) | about a year ago | (#42052727)

It's trivial to fix most vulnerabilities in customer websites without spending effort on scanning their code. There's a simple configuration change that will deal with virtually all the problems in one swoop.

Turn off PHP and ASP.

Re:Easy! (1)

cybertears (778765) | about a year ago | (#42055709)

Yeah, turning off PHP and ASP is a great way to stop these things, as well as a great way to shut your own business down.

Well, it could be done, kind of (1)

drinkypoo (153816) | about a year ago | (#42054729)

You could implement this in a limited fashion simply by scanning customers' installations for outdated versions of the CMS and its modules, and updating them. Updates for the CMS are simple with Drupal and possibly with other CMSes, and updates for the modules are handled from within the CMS in most cases. I would not be upset if someone would keep Drupal and the modules updated for me if I missed an important (security-related) update.

Auto-update scripts already exist (0)

Anonymous Coward | about a year ago | (#42055885)

The technology to do this already exists, Fantastico and Softaculous both automate the installation of many different CMSes and they will install updates when available. I don't think they will do automatic updates but you run into problems every time you update any way because certain plugins won't be compatible or themes will not be compatible, etc. For people that actually care about staying current it would be trivial to write a perl script that installs updates through the Wordpress admin interface.

Hostgator (0)

Anonymous Coward | about a year ago | (#42057999)

Already does this and has for ~4-6 months

Applications installed from their web-based installer get updated automatically

(cant remember if this requires a checkbox at install time or no)

Disclaimer: Ex HG employee.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...