Pages:
Author

Topic: Hacked Linode & coins stolen to 1NRy8GbX56MymBhDYM... (Read 62088 times)

legendary
Activity: 1330
Merit: 1000
LulzSec was working for the FBI.  This is openly admitted.

http://www.theguardian.com/technology/2012/mar/06/lulzsec-sabu-working-for-us-fbi
legendary
Activity: 1400
Merit: 1005
Confirmed FBI operation.

Jeremy Hammond:  hacks for the FBI, sentenced to 10 years in prison in return:

http://www.dailydot.com/news/jeremy-hammond-fbi-foreign-governments-list/

http://lists.randombit.net/pipermail/cryptography/2012-March/002586.html

Quote
Apparently, a 4 day old (or rather 'official since 4 days') Parallels
Plesk control panel weakness was used yesterday to break into a number
of large Bitcoin mining pools hosted on cheap virtual servers.

http://pastebin.com/xy8aQY9W

Quote
Sabu also supplied lists of targets that were vulnerable to "zero day exploits" used to break into systems, including a powerful remote root vulnerability effecting the popular Plesk software. At his request, these websites were broken into, their emails and databases were uploaded to Sabu's FBI server, and the password information and the location of root backdoors were supplied. These intrusions took place in January/February of 2012 and affected over 2000 domains
...
All of this happened under the control and supervision of the FBI

Anyone still not aware of what is going on here?
You're saying the Bitcoins were stolen by an FBI employee?  Or what are you inferring?
legendary
Activity: 1904
Merit: 1037
Trusted Bitcoiner
Confirmed FBI operation.

Jeremy Hammond:  hacks for the FBI, sentenced to 10 years in prison in return:

http://www.dailydot.com/news/jeremy-hammond-fbi-foreign-governments-list/

http://lists.randombit.net/pipermail/cryptography/2012-March/002586.html

Quote
Apparently, a 4 day old (or rather 'official since 4 days') Parallels
Plesk control panel weakness was used yesterday to break into a number
of large Bitcoin mining pools hosted on cheap virtual servers.

http://pastebin.com/xy8aQY9W

Quote
Sabu also supplied lists of targets that were vulnerable to "zero day exploits" used to break into systems, including a powerful remote root vulnerability effecting the popular Plesk software. At his request, these websites were broken into, their emails and databases were uploaded to Sabu's FBI server, and the password information and the location of root backdoors were supplied. These intrusions took place in January/February of 2012 and affected over 2000 domains
...
All of this happened under the control and supervision of the FBI

Anyone still not aware of what is going on here?

Wow, wonder what else has happened behind the scenes?

EDIT: Wait, didn't our bitcoinica funds get hacked from a Linode server?  

pastebin.com

lol, is this crap....
hero member
Activity: 661
Merit: 500
Confirmed FBI operation.

Jeremy Hammond:  hacks for the FBI, sentenced to 10 years in prison in return:

http://www.dailydot.com/news/jeremy-hammond-fbi-foreign-governments-list/

http://lists.randombit.net/pipermail/cryptography/2012-March/002586.html

Quote
Apparently, a 4 day old (or rather 'official since 4 days') Parallels
Plesk control panel weakness was used yesterday to break into a number
of large Bitcoin mining pools hosted on cheap virtual servers.

http://pastebin.com/xy8aQY9W

Quote
Sabu also supplied lists of targets that were vulnerable to "zero day exploits" used to break into systems, including a powerful remote root vulnerability effecting the popular Plesk software. At his request, these websites were broken into, their emails and databases were uploaded to Sabu's FBI server, and the password information and the location of root backdoors were supplied. These intrusions took place in January/February of 2012 and affected over 2000 domains
...
All of this happened under the control and supervision of the FBI

Anyone still not aware of what is going on here?

Wow, wonder what else has happened behind the scenes?

EDIT: Wait, didn't our bitcoinica funds get hacked from a Linode server? 
legendary
Activity: 1500
Merit: 1021
I advocate the Zeitgeist Movement & Venus Project.
legendary
Activity: 1330
Merit: 1000
Confirmed FBI operation.

Jeremy Hammond:  hacks for the FBI, sentenced to 10 years in prison in return:

http://www.dailydot.com/news/jeremy-hammond-fbi-foreign-governments-list/

http://lists.randombit.net/pipermail/cryptography/2012-March/002586.html

Quote
Apparently, a 4 day old (or rather 'official since 4 days') Parallels
Plesk control panel weakness was used yesterday to break into a number
of large Bitcoin mining pools hosted on cheap virtual servers.

http://pastebin.com/xy8aQY9W

Quote
Sabu also supplied lists of targets that were vulnerable to "zero day exploits" used to break into systems, including a powerful remote root vulnerability effecting the popular Plesk software. At his request, these websites were broken into, their emails and databases were uploaded to Sabu's FBI server, and the password information and the location of root backdoors were supplied. These intrusions took place in January/February of 2012 and affected over 2000 domains
...
All of this happened under the control and supervision of the FBI

Anyone still not aware of what is going on here?
newbie
Activity: 28
Merit: 0
Very interesting. Now if Gox or GLBSE or who knows who else can ID one of the address....


....i hope they dont reveal cutomer data - to finish that line of thought Smiley

Lol we can only hope
newbie
Activity: 28
Merit: 0
+1

As soon as there's such a mechanism, stolen coins will find a way to avoid being detected, there's just no way you can do that 100% reliably. This would only result in a great big mess - people wrongfully accusing others of having their coins stolen (even if it was a regular payment or donation) just to get them into trouble, people fighting over evidence and reputation, online wallet services getting into trouble because some think their acceptance policies are not strict enough, tainting coins of innocent others in the process, people flooding donation addresses with tainted coins,...
Also, what would be the next step? Refuse blocks from "shady" miners who include transactions with tainted fees?

We really don't need that - fighting Bitcoin thefts at that level is just not the way to go. You'd only make it a bit harder for Bitcoin thieves at the cost of making Bitcoin a much more miserable experience for everyone else!

Oh and I'm not trying to talk anybody out of implementing such a system, please go ahead and do it, just don't expect it to become widely adopted. Even people thinking such a system would be a good idea in principle are likely to disagree on the details, fighting and lobbying for their favored policies, etc... In the end, it would have been much more effective to just make two-factor authentication easy to use for everyone.
legendary
Activity: 1386
Merit: 1097
Hey slush--so eight months later can you give us any update on this incident?  I'm curious to know if Linode host ever compensated you, even partly.  Did you get enough donations to cover even a small percentage of your losses?

Linode "compensated" me by providing one year of VPS server "for free". I sent them official snail mail letter asking for some compensation, I contacted them by email, no response.

I received around 30BTC on donations from many people and I'm really glad for that support. Still, I had to covered the rest of stolen 3094 BTC from my pocket...
member
Activity: 74
Merit: 10
Hey slush--so eight months later can you give us any update on this incident?  I'm curious to know if Linode host ever compensated you, even partly.  Did you get enough donations to cover even a small percentage of your losses?
legendary
Activity: 826
Merit: 1001
rippleFanatic
Excellent work.

Looks like it could be a potential slip-up of the thief. Now to make sure the exchanges are aware of the two extra addresses:

Code:
    Fri Jan  6 03:01:59 2012    10c0f04931b015c0d339a1510cfc23a12a6dcdbe    fcee4be6c1fc527aaa2e9bdf1dd07f8119f9d0bd1bdeee78e04fdeb56fc6ce81               0.00000000 +             367.41137900 =             367.41137900
    Sat Jan  7 01:31:48 2012    80ab5bcd943419b8988234e8e19b83389edc542a    92a05c0ae62d11a64f132976ab44cc9b1e127c189abda8948aecdb42abb4d101             367.41137900 +             298.61836200 =             666.02974100


What do you mean "two" ?


nevermind, haven't had much sleep and was confused by gap in dates.

still, it seems possible that the earliest ones could be the most revealing. there really should be a database for tagging addresses (as belonging to different exchanges, pools, services, etc.), or is there one i'm not aware of?
legendary
Activity: 826
Merit: 1001
rippleFanatic
Excellent work.

Looks like it could be a potential slip-up of the thief. Now to make sure the exchanges are aware of the two extra addresses:

Code:
    Fri Jan  6 03:01:59 2012    10c0f04931b015c0d339a1510cfc23a12a6dcdbe    fcee4be6c1fc527aaa2e9bdf1dd07f8119f9d0bd1bdeee78e04fdeb56fc6ce81               0.00000000 +             367.41137900 =             367.41137900
    Sat Jan  7 01:31:48 2012    80ab5bcd943419b8988234e8e19b83389edc542a    92a05c0ae62d11a64f132976ab44cc9b1e127c189abda8948aecdb42abb4d101             367.41137900 +             298.61836200 =             666.02974100
legendary
Activity: 1358
Merit: 1002
Very interesting. Now if Gox or GLBSE or who knows who else can ID one of the address....


....i hope they dont reveal cutomer data - to finish that line of thought Smiley

I think that what each exchanges decide to do with information that can be
mined from the blockchain in that way will very much end up being a part
of how they compete with one another.

In particular, should they choose to comply with authorities with disclosure
requests that are based on blockchain forensics, this will make using one
exchange over an other more or less of an option for a certain category of
people.

This will all lead to a diversification of the ecosystem, which is a good thing.



When I "lost" 400 BTC people were able to track down the address to GLBSE just by looking at address. I'm pretty sure there is a lot of info in here if someone wanted to look. I did offer a 40 BTC (10%) bounty however. Maybe bitcoinica could do the same:)

They don't even bother to file a police report when they get robbed or their servers breached, why would they offer a bounty? Wink
hero member
Activity: 686
Merit: 500
Wat
Very interesting. Now if Gox or GLBSE or who knows who else can ID one of the address....


....i hope they dont reveal cutomer data - to finish that line of thought Smiley
legendary
Activity: 1896
Merit: 1343
Public addresses are derived from the private key, so deterministic wallet is not the solution.  However, you are correct that you don't need the private keys.  You can simple keep a buffer of a few thousand address in your db that match private keys you store in a safe location.

I think electrum has implemented a solution where the addresses can also be derived from a seed.

I don't see how.... the private key is the only input to the formula for generate the public key/address.  Sure, you can throw away the private key after you calculate the address, but if you're hacked they will just take the seed and generate the private keys.

Do you have a link to the solution you mentioned?

yes, I was referring to "type 2" deterministic wallets. This solution is currently implemented in Electrum and Armory.

in addition, Electrum has a working example of address generator in python-php: http://ecdsa.org/remote.php
legendary
Activity: 1904
Merit: 1002
took me a while, but found it, what I meant is called a "type 2 deterministic wallet". see this post: https://bitcointalksearch.org/topic/deterministic-wallets-19137 ("Deterministic Wallets")

Quote
Type-2 is a bit less obvious and understanding it requires you to know about a property of ECC keys, roughly:

A_public_key = A_private_key*point

Which means you can do:

B_public_key = A_public_key+B_secret*point
and have a new key which has a private key:
B_private_key = A_private_key+B_secret

So a type2 wallet stores:
Master_private_key
A large Random_seed S.

and keys are given by

Privatekey(type,n) = Master_private_key + H(n|S|type)

which works just like a type-1, the advantage of the type-2 is that you can separately secure the Master_private_key, but still generate new addresses with
Publickey(type,n) = Master_public_key + H(n|S|type)*point



Thanks... that would work.  In case it's not obvious to someone else, this may help:



A_public_key = A_private_key*point, so B_public_key = B_private_key*point

B_private_key = A_private_key + B_secret -> B_public_key = (A_private_key + B_secret)*point

Since A_private_key*point is our A_public_key, this gives us B_public_key = A_public_key + B_secret*point

Like you quoted, as long as you have the first public key you can generate all the public keys in the sequence without providing enough information to reveal the private keys.



Thanks again for digging up that information.
donator
Activity: 2772
Merit: 1019
Public addresses are derived from the private key, so deterministic wallet is not the solution.  However, you are correct that you don't need the private keys.  You can simple keep a buffer of a few thousand address in your db that match private keys you store in a safe location.

I think electrum has implemented a solution where the addresses can also be derived from a seed.

I don't see how.... the private key is the only input to the formula for generate the public key/address.  Sure, you can throw away the private key after you calculate the address, but if you're hacked they will just take the seed and generate the private keys.

Do you have a link to the solution you mentioned?

took me a while, but found it, what I meant is called a "type 2 deterministic wallet". see this post: https://bitcointalksearch.org/topic/deterministic-wallets-19137 ("Deterministic Wallets")

Quote
Type-2 is a bit less obvious and understanding it requires you to know about a property of ECC keys, roughly:

A_public_key = A_private_key*point

Which means you can do:

B_public_key = A_public_key+B_secret*point
and have a new key which has a private key:
B_private_key = A_private_key+B_secret

So a type2 wallet stores:
Master_private_key
A large Random_seed S.

and keys are given by

Privatekey(type,n) = Master_private_key + H(n|S|type)

which works just like a type-1, the advantage of the type-2 is that you can separately secure the Master_private_key, but still generate new addresses with
Publickey(type,n) = Master_public_key + H(n|S|type)*point

legendary
Activity: 1904
Merit: 1002
Public addresses are derived from the private key, so deterministic wallet is not the solution.  However, you are correct that you don't need the private keys.  You can simple keep a buffer of a few thousand address in your db that match private keys you store in a safe location.

I think electrum has implemented a solution where the addresses can also be derived from a seed.

I don't see how.... the private key is the only input to the formula for generate the public key/address.  Sure, you can throw away the private key after you calculate the address, but if you're hacked they will just take the seed and generate the private keys.

Do you have a link to the solution you mentioned?
donator
Activity: 2772
Merit: 1019
Public addresses are derived from the private key, so deterministic wallet is not the solution.  However, you are correct that you don't need the private keys.  You can simple keep a buffer of a few thousand address in your db that match private keys you store in a safe location.

I think electrum has implemented a solution where the addresses can also be derived from a seed.
legendary
Activity: 1904
Merit: 1002
Quote
I myself didn't even know of linode before. If they act correctly now, I might even consider them next time I look for a VPS provider -> successful marketing.

If you should learn anything from this incident is that you shouldn't keep any big amounts of coins on a vps, linode or not.

+1

If all you need is to accept Bitcoin in an e-commerce, then you do not need to leave your private keys on the server. For example, you can use a deterministic wallet to generate your addresses without the private keys.

If your server needs to send bitcoins to customers (which was the case for bitcoinica and slush's pool), it is probably not reasonable to use a VPS, especially if large amounts are involved.

Public addresses are derived from the private key, so deterministic wallet is not the solution.  However, you are correct that you don't need the private keys.  You can simple keep a buffer of a few thousand address in your db that match private keys you store in a safe location.
Pages:
Jump to: