GoDaddy Wants Your Root Password

Johnny Fusion writes "The writer of the Securi Security Blog had an alarming awakening when a honeypot on port 22 on a GoDaddy-hosted VPS recorded login attempts using his GoDaddy username and password and even an attempt to login as root. It turns out the attempt was actually from within GoDaddy's network. Before he could 'alert' GoDaddy about the security breach, he got an email from GoDaddy Demanding his root login credentials. There is an update where GoDaddy explains itself and says they will change policy."

Comments

Feature, not a bug.

[LostCluster]

When my trivia game was hosted at EV1Servers (now part of The Planet company) I kept my root password on file with them at all times, and quite a few times support logged in and helped me with a problem, like telling me the reason my webserver went down was that the Warnings file in Apache had hit the Linux system limit.

This isn't GoDaddy the domain registrar looking for your passwords, this is GoDaddy the hosting provider wanting to log in to a customer's VPS that's running on their hardware, and most likely is calming down a paranoid admin if he's yelling at Slashdot about a "security breach" when support wanted to log in.

Nothing to see here... move along.

Re:Feature, not a bug.

[batrick]

A VPS is rented space on hardware in the same way you rent an apartment. You don't own the hardware, but that doesn't mean the host can break into your box whenever he wants. Maybe the contract asserts they have that right (you would be an idiot to contract with them). Use Linode (arguably the best VPS provider in the industry): http://linode.com/ (I am not affiliated with Linode.)

Re:Feature, not a bug.

[mysidia]

Two things... (1) of course they can determine that after logging in with the credentials.

(2) Godaddy is using fricking Virtuozzo as their VPS hosting platform right?

They technically then don't NEED the root password at all if so.

In theory, they could 'vzctl enter' a customer's VPS from the host node. To be clear: _entering_ a container, spawns a new shell child process with the customer's VZPID, such that the child shell is actually created inside the customer's VPS.

Now there might be some reasons they wouldn't want to do this, or that they'd want to wrap that in additional layers.

Well, the reason is entering a VPS from the host node potentially places the VPS they have entered in control of the user's terminal.

That could in theory be a security risk to GoDaddy's own system.

So by getting the VPS root password, they can enter the VPS over the network, instead of through the hardware node.... thus, not ensuring a VPS can never have control over a terminal logged into the hardware node.

Basically, this is more sound security wise.

Anyways... there definitely doesn't seem to be anything wrong with GoDaddy gaining access to a customer VPS on an official basis, for good reasons, to investigate possible customer abuse or malware.

As long as they follow professional standards, respect customer privacy completely, do not conduct any abuses, such as stealing leaking info, or gratifying personal curiosities (IOW: no abuse whatsoever) -- basically everything you would expect from an admin of Gmail or Yahoo mail (as in not reading your e-mail and using it for personal uses, to satisfy curiosities, blackmail you, etc...).

Oh yeah, and that they exclude any utilization they generate from the customers' bandwidth / resource bills.

No Surprises Here

[neoform]

Not surprising at all.

I had a domain with Godaddy a few years ago when they breached ICANN's rules by threatening to confiscate my domain unless I paid them $200, because I had supposedly breached their TOS.

GoDaddy is not to be trusted.

Re:No Surprises Here

[neoform]

Someone (falsely) accused me of spamming.

However, even *if* I was a spammer, what right does godaddy have to confiscate my domain? I didn't even have any hosting with them, I just had a domain registered. This is clearly against ICANN policy. Registrars are not arbiters who get to take your domain away because they feel like it.

Always seperate hosting, dns, and registeration

[cenc]

As someone that has been around the block with running a lot of web sites (well, a couple thousand at least) for say the last 10 years, I have learned the hard way to not put all your eggs in one basket. Registries come and go, even the big boys (at least service comes and goes, policies change), hosting providers can go bad for all kinds of reasons, and your DNS services are your keys to the castle in terms of just how much damage an outage can do to a buisness (backup DNS severs people).

So? Don't give it to them.

[Hurricane78]

Make a backup of your server, and then tell them that they won’t get it.

If they switch off your server, sue them for extortion, trespassing (in case they entered the server) and damages. [Same rules as with a (business) apartment and a landlord.]

But I personally already had hosters asking me for the root password. I refused. That was it. They did not do anything. (We still had a contract, after all.) Of course they told me that they wouldn’t give me support for the software. But I wouldn’t have wanted that anyway, since on the last managed server, they wrecked my database when one of their idiot admins did “fix” something.

I don’t see the problem. Let them bitch. Tell them to fuck off or you’ll sue. Done.

Re:Christian morality

[Anonymous Coward]

They have a long standing policy of refusing business with people who promote an agenda that counteracts conservative Christianity. It's impossible to register or get hosting for a pro-choice site with them for instance. Just because they use T&A in their ads doesn't make them even handed. It just shows that they will stoop to any level to attract customers.

Re:I wonder...

[fuzzyfuzzyfungus]

I'm not sure that that is true, at least not true enough to be useful. The case of the OS in a VM that doesn't trust its VM host is, it would seem to me, quite similar to that of the program running on an OS/other programs environment that it does not trust.

Where have we seen a lot of focus on that problem? DRM(and, secondarily, antivirus/anti-rootkit work). In both the case of the program that is trying to hide crypto keys from the computer's owner and the case of the program trying to determine, from within the running OS, whether or not the OS has been rootkitted and is now lying in various subtle ways, we have the very similar situation of a program whose memory and HDD spaces are exposed to hostile powers trying to keep secrets.

Now, the punchline has always been that the defender cannot win. Anything they try is just obfuscation, which a sufficiently clever attacker can always punch through. However, in the presence of attackers of only finite cleverness(and patience), obfuscation can work. All software DRM is breakable; but some has been harder to crack than others.

I would be curious to know where on that continuum common OSes running in VMs fall. I'd assume that they fall on the "almost totally naive" side; but, given the amount of attention on address space layout randomization, and tripwire and so forth(in the service of solving quite different security problems; but still introducing complexities) it might be harder than one would suspect, although always possible in theory.