LulzSec was working for the FBI. This is openly admitted.
http://www.theguardian.com/technology/2012/mar/06/lulzsec-sabu-working-for-us-fbi
Topic: Hacked Linode & coins stolen to 1NRy8GbX56MymBhDYM... (Read 62186 times)
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
http://pastebin.com/xy8aQY9W
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? 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.
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
...
All of this happened under the control and supervision of the FBI
Anyone still not aware of what is going on here?
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
http://pastebin.com/xy8aQY9W
Anyone still not aware of what is going on here?
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.
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
...
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....
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
http://pastebin.com/xy8aQY9W
Anyone still not aware of what is going on here?
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.
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
...
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?
Damn.
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
http://pastebin.com/xy8aQY9W
Anyone still not aware of what is going on here?
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.
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
...
All of this happened under the control and supervision of the FBI
Anyone still not aware of what is going on here?
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 
Lol we can only hope
+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.
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.
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...
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?
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:
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?
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:
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
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 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?
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 
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
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
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.
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
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
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?
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.
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.
Jump to: