

LocalBitcoins received an attack against the site infrastructure - AdamGibbins
https://localbitcoins.com/

======
zik
This type of attack seems to be becoming more and more common - social
engineering the server provider to gain root access. Good work by the
localbitcoins guys in making everything so secure that even with root access
the intruder (probably) gained nothing.

------
deathanatos
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.

~~~
rdl
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
> 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
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.

------
jvoorhis
LocalBitcoins' blog post about the attack can be found here.

[http://localbitcoins.blogspot.com/2014/05/attack-against-
loc...](http://localbitcoins.blogspot.com/2014/05/attack-against-
localbitcoins.html)

------
wfn
Good use of full disk encryption (or encryption of everything but the base
bootable OS) and separation of systems (bitcoind on a separate server.) That's
the way to do things! Good on them.

------
ch
It seems that if a bitcoin site is to use a 3rd party hoster, they would be
wise to at least require all email correspondence be cryptographically signed;
better still , why not require encrypted email exchanges.

Is there a hosting provider which supports this level of service?

~~~
_asciiker_
kimeralive.com offers private mail servers that are not accessible via non
encrypted ports and require TLS :) (disclaimer, I'm the CTO at Kimera)

~~~
ch
I'm not referring to just private mail services, but rather if you can implore
customer service to remotely administer you servers (even just rebooting) via
email they should only act on crypto signed correspondence. Seems this would
reduce the success of email social engineering as an attack vector. It might
not make sense in all cases but if I am storing monetary value for others it
would be a nice extra level to promote.

~~~
_asciiker_
That is certainly something worth considering. We could validate PGP
signatures.

------
conformal
i strongly suggest that sites concerned with their security use (1) full-on
colocation services and (2) encrypt the partition they store user data on or
encrypt the entire disk.

if you have proper disk encryption, it is non-trivial to game the remote
physical access to the machine, e.g. attacker convinces someone to use 'remote
hands' to reboot server and then gets console redirected pre-boot. if you have
disk encryption in this scenario, whether it is on the user data partition or
the whole disk, you will surely be notified of the unscheduled reboot and can
investigate it.

it is always best to host your own machines (_not_ VPSes) and be able to
provide some level of compartmentalization to your hosting setup.

~~~
stefanha
Careful, disk encryption usually doesn't cover the entire disk. So an attacker
can place an evil initramfs in the /boot partition that stores away your disk
encryption passphrase, for example.

This is even easier if the operating system partition is plaintext and only
the data partition is encrypted. Then it's trivial to modify any binary,
library, or startup scripts!

Encryption just means an attacker cannot get at the data right away. But once
the admin brings up the system again (not knowing something has been tampered
with) it's pretty easy to get access.

~~~
hbbio
This is exactly the reason why they say they are not restarting the site now
but are building a new fresh server instead.

------
pstrateman
Cloudhashing has seen a large number of these attacks.

All such attacks are futile, we are hosted by professionals and employ full
disk encryption.

That any data at localbitcoins was compromised is shameful.

