3 ms·

I'm a bit curious as to their explanation: > The attacker gained a root access to the server for ~40 minutes and > All data on the website server is encrypte

I'm a bit curious as to their explanation: > The attacker gained a root access to the server for ~40 minutes and > All data on the website server is encrypted. Manual actions are needed to make this data readable, so the attacker could not gain access to the data even when having a server console access. Unless the "encrypted data" is simply being stored on that server, and not used, this seems like a hopeful statement to make. If a server process is accessing it, then it must have the key, at the very least, in memory (which root can access, though finding the key might be somewhat of a feat). Even if the truly valuable stuff was on another server, could the hacker not masquerade as the webserver itself, and make requests that appear to have originated from the webserver? Granted, this assumes a lot about the ability of the attacker. I'm mostly saying it's possible, not that it's probable; the latter is harder to determine. Good see them rebuilding on fresh hardware: better to start from scratch than to try and "uncompromise" a system. Shame on the provider though; I'm curious to know who: I feel like such situations deserve a bit of name-and-shame, as they represent a very severe failure on the part of the provider. And the provider should detail very clearly what steps will be taken such that this will not happen again.

mattdw 13y ago
> Unless the "encrypted data" is simply being stored on that server, and not used, this seems like a hopeful statement to make. If a server process is accessing it, then it must have the key, at the very least, in memory (which root can access, though finding the key might be somewhat of a feat) The attacker got access via a reboot, so something as simple as passphrase-protected private keys would probably be sufficient here - "manual actions" could well refer to "enter the passphrase after startup". Or using something like kerberos, where credentials have to be fetched/validated via a separate server.
rdl 13y ago
I suspect they have a base OS installation and then have a post-boot encrypted partition which requires manual passphrase entry over ssh or console to unlock, containing all the relevant data. That's a pretty normal way to set up remotely-adminned fairly secure servers. When it's "cold" (offline, or running but in system-low mode), you have no real protection of the OS, but you essentially distrust the machine whenever it gets rebooted without your consent. If someone can get root on the server while it's in "high mode" (normal operation, after keys are entered), any protections are irrelevant anyway. The risk is if the attacker can cause enough reboots that you stop caring about reboots so much, and just blindly enter the passphrase; the attacker then puts up something which steals the passphrase, and then uses the passphrase on an already-imaged drive, winning the game. Or if the attacker can use one of a large number of vulnerabilities to get access to your data when it's running in system-high mode; either an app-level vulnerability or either local access + local root, or remote root. Server technology sucks for anything needing great security but adminned strictly remotely.
- cantfindmypass 13y ago
  > I suspect they have a base OS installation and then have a post-boot encrypted partition which requires manual passphrase entry over ssh or console to unlock, containing all the relevant data. That's a pretty normal way to set up remotely-adminned fairly secure servers. Debian and Ubuntu both support this pretty painlessly. 1) Do the base install with full disk encryption. 2) Put an ssh public key into /root/.ssh/authorized_keys 3) Install dropbear. 4) Force a initramfs rebuild if it doesn't happen automatically. You'll get an initramfs that has dropbear ssh embedded which you can log into and unlock the disk.
  - rdl 13y ago
    Right, but there's no real proof the dropbear/sh/etc. you talk to is untampered after reboot; it could easily be logging, if someone shut your system down and replaced the boot drive. ssh vs. serial console at least requires they extract some (unencrypted) key from the drive, though.
lorddoig 13y ago
The DNS resolves to 81.17.24.30 which apparently is owned by Private Layer Inc and is located in Switzerland. Private Layer's homepage (https://www.privatelayer.com/ https://www.privatelayer.com/) shows a selection of dediboxes, so I'm guessing that's the provider.
- shibe0shibe0 13y ago
  Was this attack done on Privatelayer or have they just moved to this datacenter after the attack? I use this datacenter, they've already posted my passwords via skype before - wouldn't suprise me if they were subjected to social engineering.

mattdw 13y ago

> Unless the "encrypted data" is simply being stored on that server, and not used, this seems like a hopeful statement to make. If a server process is accessing it, then it must have the key, at the very least, in memory (which root can access, though finding the key might be somewhat of a feat) The attacker got access via a reboot, so something as simple as passphrase-protected private keys would probably be sufficient here - "manual actions" could well refer to "enter the passphrase after startup". Or using something like kerberos, where credentials have to be fetched/validated via a separate server.

rdl 13y ago

I suspect they have a base OS installation and then have a post-boot encrypted partition which requires manual passphrase entry over ssh or console to unlock, containing all the relevant data. That's a pretty normal way to set up remotely-adminned fairly secure servers. When it's "cold" (offline, or running but in system-low mode), you have no real protection of the OS, but you essentially distrust the machine whenever it gets rebooted without your consent. If someone can get root on the server while it's in "high mode" (normal operation, after keys are entered), any protections are irrelevant anyway. The risk is if the attacker can cause enough reboots that you stop caring about reboots so much, and just blindly enter the passphrase; the attacker then puts up something which steals the passphrase, and then uses the passphrase on an already-imaged drive, winning the game. Or if the attacker can use one of a large number of vulnerabilities to get access to your data when it's running in system-high mode; either an app-level vulnerability or either local access + local root, or remote root. Server technology sucks for anything needing great security but adminned strictly remotely.

cantfindmypass 13y ago
> I suspect they have a base OS installation and then have a post-boot encrypted partition which requires manual passphrase entry over ssh or console to unlock, containing all the relevant data. That's a pretty normal way to set up remotely-adminned fairly secure servers. Debian and Ubuntu both support this pretty painlessly. 1) Do the base install with full disk encryption. 2) Put an ssh public key into /root/.ssh/authorized_keys 3) Install dropbear. 4) Force a initramfs rebuild if it doesn't happen automatically. You'll get an initramfs that has dropbear ssh embedded which you can log into and unlock the disk.
- rdl 13y ago
  Right, but there's no real proof the dropbear/sh/etc. you talk to is untampered after reboot; it could easily be logging, if someone shut your system down and replaced the boot drive. ssh vs. serial console at least requires they extract some (unencrypted) key from the drive, though.

lorddoig 13y ago

The DNS resolves to 81.17.24.30 which apparently is owned by Private Layer Inc and is located in Switzerland. Private Layer's homepage (https://www.privatelayer.com/ https://www.privatelayer.com/) shows a selection of dediboxes, so I'm guessing that's the provider.

shibe0shibe0 13y ago
Was this attack done on Privatelayer or have they just moved to this datacenter after the attack? I use this datacenter, they've already posted my passwords via skype before - wouldn't suprise me if they were subjected to social engineering.