[deleted]
Hetzner Servers Compromised
61–70 of 133 posts
Re: Hetzner Servers Compromised
#62I've got a login for robot.your-server.de and have changed my password but don't seem to have one for konsoleh.your-server.de. Is the konsoleh login/account something that would have gotten created for me automatically? i.e. do I need to worry about it?
You need a konsoleH account for the registration of 'special' domains not covered by the robot. One doesn't have one by default.
I think webspace users get a konsoleH account, too.
Re: Hetzner Servers Compromised
#63Earlier quoted context omitted.
What if attacker infects unencrypted part used for booting? Do you have protection against that? It's relatively easy on Linux, where /boot is usually not encrypted.
Agreed, but typically /boot isn't automounted when it's a separate partition, which means they would need a root-access compromise already .
Hetzner allows to netboot any server via admin panel. After booting into recovery os, you can modify unencrypted parts as you wish.
Re: Hetzner Servers Compromised
#64Seriously, again?? I think such a fauxpas shouldn't be tolerated twice.
Do you have link to their previous hack?
Here is the (english) mail they sent to customers back in October 2011 on the previous intrusion:
Re: Hetzner Servers Compromised
#65One of the differences between servers in data centers and desktops is that servers don't reboot a lot. So the bad guys can build an in memory system that doesn't change anything on disk (which avoids the configuration management system from flagging it) and if it cloaks itself as a normally long lived process then active monitors might be fooled as well.
It then runs, effectively undetected, until the server reboots which can be months (or even years).
Tools to protect against those threats are going to have start taking into account process activity and footprint.
Re: Hetzner Servers Compromised
#66Full text of the email sent to cutomers: Dear Client At the end of last week, Hetzner technicians discovered a "backdoor" in one of our internal monitoring systems (Nagios). An investigation was launched immediately and showed that the administration interface for dedicated root servers (Robot) had also been affected. Current findings would suggest that fragments of our client database had been copied externally. As…
"The standard techniques used for analysis such as the examination of checksum or tools such as "rkhunter" are therefore not able to track down the malicious code."
rkhunter is out of date.
http://rkhunter.sourceforge.net/
http://en.wikipedia.org/wiki/Rkhunter
We use it as well but I'm not sure it is an example of a serious security practice when given with only one other "checksum or tools such as" type statement.
Re: Hetzner Servers Compromised
#67As part of the registration process with hetzner.de, you have to send them scans of personal documents (such as passport, drivers license or similar). I asked them just now if these systems were compromised and they promptly replied: "The system that stores scans of ids, credit cards and so on was not compromised. In addition to that, we delete that information after 21 days."
"you have to send them scans of personal documents (such as passport, drivers license or similar)."
What? Seriously?
"In addition to that, we delete that information after 21 days."
Hmm, do they delete the info that ends up on backup copies? How do you know they even actually delete it in 21 days? It's not like there is a third party even auditing which you can rely on. (Not that I'd ever do that for something like this anyway, I would just find another provider.)
Re: Hetzner Servers Compromised
#68Earlier quoted context omitted.
Just got the email too. I'm quite happy with how clear they are about what happened and how they hash their passwords. Very different from Linode. I just wish that they used bcrypt instead of a salted SHA256 but at least it's salted (and anyway in my case I never reuse passwords so no big deal).
> I just wish that they used bcrypt instead of a salted SHA256 but at least it's salted (and anyway in my case I never reuse passwords so no big deal). If they fall under PCI:DSS, they might not be able to use bcrypt since it isn't an official recommended standard. (I am of course assuming that they mean PBKDF2 when they say salted SHA256.)
Would they be able to get around this by encrypting it two times? On of the times with the official recommend standard an another time with bcrypt?
Re: Hetzner Servers Compromised
#69As part of the registration process with hetzner.de, you have to send them scans of personal documents (such as passport, drivers license or similar). I asked them just now if these systems were compromised and they promptly replied: "The system that stores scans of ids, credit cards and so on was not compromised. In addition to that, we delete that information after 21 days."
"you have to send them scans of personal documents (such as passport, drivers license or similar)." What? Seriously? "In addition to that, we delete that information after 21 days." Hmm, do they delete the info that ends up on backup copies? How do you know they even actually delete it in 21 days? It's not like there is a third party even auditing which you can rely on. (Not that I'd ever do that for something like t…
Yes seriously, here is what they asked me on first order with them:
"Since you're a new customer with Hetzner, we ask you for a scan of your passport or ID card (authenticity check). It's only necessary for your first order with us.
Please send the scan by fax or as an email attachment."
When they say they delete it after 21 days, as they did in the mail I've just received, I trust them. I find their communication on this matter, as well as previous matters, open and serious.
Re: Hetzner Servers Compromised
#70Sigh, another hosting provider hack. As if Linode and OVH are not enough. This is the reason why we use full disk encryption, where we enter the key manually during boot. This way we're protected against many types of hosting provider hacks.
What if attacker infects unencrypted part used for booting? Do you have protection against that? It's relatively easy on Linux, where /boot is usually not encrypted.
The trick is putting all important data in the encrypted part. The unencrypted part must be reconstructable in an automated manner. If you are paranoid and you assume that all unplanned reboots are attacks, then you can reconstruct the unencrypted part every time. Tools like Chef make this relatively easy.