Wow, quite the attack. I'd go straight after Linode with a lawsuit.
There may be something in their EULA to protect them against this type of lawsuit
Topic: Hacked Linode & coins stolen to 1NRy8GbX56MymBhDYM... - page 14. (Read 62186 times)
There may be something in their EULA to protect them against this type of lawsuit
Quote
We appreciate your business and certainly want to keep you as a happy and satisfied customer. If there is anything we can do to make this up to you, certainly let us know.
Ask them to cover your losses.
Wow, quite the attack. I'd go straight after Linode with a lawsuit.
There may be something in their EULA to protect them against this type of lawsuit
Linode confirmed that it was their fault, see bottom of pastebin.
So far it looks like superadmin account of Linode Manager leaked, which also explains why there was no login attempt to my account, although there was job for restart & password change.
So far it looks like superadmin account of Linode Manager leaked, which also explains why there was no login attempt to my account, although there was job for restart & password change.
Are they going to cover your losses ? This is a substantial amount of money involved.
Wow, quite the attack. I'd go straight after Linode with a lawsuit.
Sorry to hear that guys. I only hope Gavin manages to achieve consensus and use his available resources to have that multisig feature implemented.
A classic example of why we need ps2h
With p2sh Slush could have had one key on the server and a second key on an independent device (with third key kept always offline on paper as failsafe). If he makes payments in batches he could even keep the second device offline outside payment windows and route signing through vpn or tor to provide further hardening.
ps2h is needed to provide not just "stupid user protection" but enterprise grade security solutions.
Linode confirmed that it was their fault, see bottom of pastebin.
So far it looks like superadmin account of Linode Manager leaked, which also explains why there was no login attempt to my account, although there was job for restart & password change.
So far it looks like superadmin account of Linode Manager leaked, which also explains why there was no login attempt to my account, although there was job for restart & password change.
Yes, but if the bagholder isn't happy about the "quality" of the coins,
the person who committed the theft is now known.
This is not the right thread for this, we should move.
The person is not known unless 100% of bitcoin services ID customers.
Sorry to hear that guys. I only hope Gavin manages to achieve consensus and use his available resources to have that multisig feature implemented.
Getting access to the Linode admin UI doesn't give access to the server itself. You can view the console, but you just get the login prompt. You still need the server's password to log in.
To reset the password the server has to be shut down so that /etc/shadow can be modified. At that point they could just go in and grab the data, but they most likely used Linode's password changer to minimize the downtime to a few seconds to help prevent getting caught.
A reboot wouldn't be required if they got access to the Linode hosts, but it doesn't sound like that was the case here. I'm guessing the exploit is in their web-based server management.
To reset the password the server has to be shut down so that /etc/shadow can be modified. At that point they could just go in and grab the data, but they most likely used Linode's password changer to minimize the downtime to a few seconds to help prevent getting caught.
A reboot wouldn't be required if they got access to the Linode hosts, but it doesn't sound like that was the case here. I'm guessing the exploit is in their web-based server management.
This is by far one of the scariest things about the process. Considering Slush and the Faucet were compromised at roughly the same time, it points to the flaw being in Linode's administrative control panel. A -very- scary situation, considering Linode is one of the largest VPS providers around.
The downside is this would destroy fungibility. I'm not eager to see that happen.
Agreed.
This is why I said many people would dislike this idea.
However, there is nothing anyone can do to prevent it from happening
at some point: all the data to do this is right there, in the block chain.
No one needs to prevent it, and the data is not all right there in the chain, the most relevant piece in this case is in this thread.
Thefts are not usually known in the first minutes after they happen. It will be trivial to switch the coins before they get the taint. Someone else will hold the bag (and they'll be kindly informed after it is too late by your spiffy taint client).
Getting access to the Linode admin UI doesn't give access to the server itself. You can view the console, but you just get the login prompt. You still need the server's password to log in.
To reset the password the server has to be shut down so that /etc/shadow can be modified. At that point they could just go in and grab the data, but they most likely used Linode's password changer to minimize the downtime to a few seconds to help prevent getting caught.
A reboot wouldn't be required if they got access to the Linode hosts, but it doesn't sound like that was the case here. I'm guessing the exploit is in their web-based server management.
To reset the password the server has to be shut down so that /etc/shadow can be modified. At that point they could just go in and grab the data, but they most likely used Linode's password changer to minimize the downtime to a few seconds to help prevent getting caught.
A reboot wouldn't be required if they got access to the Linode hosts, but it doesn't sound like that was the case here. I'm guessing the exploit is in their web-based server management.
isnt there a way to manage autopayouts with encrypted wallets so that if your wallet gets accessed its still highly encrypted and unspendable
Your software has to know the encryption key in order to make the payouts.
In this particular case it may have helped - if the key was stored only RAM (Slush would have had to type it in every reboot) it would have been wiped when the server was rebooted. On the other hand, if the attackers get access without rebooting they can grab the key out of RAM and decrypt the wallet.
The reboot is what's throwing me on this whole thing ... I've got to go read the timeline again, it wouldn't make sense to me to reboot the machine (potentially alerting the server admin ) if you were able to comprise a linode node at the level that has been suggested.
edit: nvm, its clearly explained in the OP. though why a node would need a reboot after a password change is beyond me
I'm under impression, you are the first (or one of the very few) people who were hacked and decide to cover the loss from their own pocket. Now I'm happy we have at least the 2%.
So we can see that all linode bitcoin users were affected - if I were you I would contact everyone else affected and send a letter to the company demanding to cover the losses or have a class action lawsuit. At least that's what I would do but I am not a lawyer/what's their ToS/on what terms you were using their service,etc, but I wish you good luck.
I am against anything that could potentially put coins into limbo and add even a hint of centralization to the mix.
plus, there is no way I would trust any organization to decide how "tainted" my coins were ... it sounds like it could be ripe for abuse
plus, there is no way I would trust any organization to decide how "tainted" my coins were ... it sounds like it could be ripe for abuse
Agreed on both count, but ... read my previous post: there nothing
you can do to prevent this from being built by someone at some point.
Oh yeah, no doubt about that
I'm curious, How is this handled in the "real world" now with currency?
isnt there a way to manage autopayouts with encrypted wallets so that if your wallet gets accessed its still highly encrypted and unspendable
Your software has to know the encryption key in order to make the payouts.
In this particular case it may have helped - if the key was stored only RAM (Slush would have had to type it in every reboot) it would have been wiped when the server was rebooted. On the other hand, if the attackers get access without rebooting they can grab the key out of RAM and decrypt the wallet.
isn't this something the new bips can help with
Not to throw petrol on this absolute fkup(and it does seem linode is to blame), isnt there a way to manage autopayouts with encrypted wallets so that if your wallet gets accessed its still highly encrypted and unspendable(atleast within the next couple of billion years before its cracked)
I am against anything that could potentially put coins into limbo and add even a hint of centralization to the mix.
plus, there is no way I would trust any organization to decide how "tainted" my coins were ... it sounds like it could be ripe for abuse
plus, there is no way I would trust any organization to decide how "tainted" my coins were ... it sounds like it could be ripe for abuse
The downside is this would destroy fungibility. I'm not eager to see that happen.
The idea of reputation is intriguing, but realistically that will just mean people will pay for premium laundry services that can provide freshly-mined coins. Mining could become unusually profitable for a while.
The idea of reputation is intriguing, but realistically that will just mean people will pay for premium laundry services that can provide freshly-mined coins. Mining could become unusually profitable for a while.
Jump to: