Fake Bitcoins?

[Anonymous]

So is there actually no one on these forums that can and is willing to explain in great detail how to go about one of these attacks?

Even if his intentions were not sincere, security through obscurity is a terrible terrible practice.  Despicable.

without having access to the source for mybitcoin it's impossible to know what mistakes they made.  They've admitted only that they were not waiting for the required number of confirmations before crediting account balance.  There are also rumours that they were not even waiting for the transactions to appear in a block at all and merely marking them confirmed when they saw a new block, but I can't honestly believe anyone would code anything that bad.

If you don't like 'security through obscurity' - I recommend you start using one of the open sources exchanges based on intersango e.g. https://intersango.us/ rather than mtgox...

Will

My point was simply that it seemed no one wanted to give the guy a straight answer.  And I have an account on intersango.us actually.

My understanding of the Mt.Gox hack is that it was indeed a fake bitcoin hack also, but done in a different way.  Although to be entirely honest, I'm not sure how exactly; Mt.Gox didn't really give us a straight answer (they changed their story a few times if I remember correctly).

From what I read. MtGox was hacked by a creation of mtgox bitcoins (not deposited but created by someone) who hacked into a admin account. This person/another hacker also used a mysql injection hack (works like this. Query used to test users credentials is "SELECT * FROM `users` WHERE 'username' = '$user' AND 'password' = '$passwordHash'" or something along those lines. A SQL injection is when a person injects code into the statement in the username or password variables like "' OR 'a' = 'a'", changing the statement to "SELECT * FROM `users` WHERE 'username' = '' OR 'a' = 'a' AND 'password' = ''". Thus giving the user access to any user.)  to obtain read-only access to their users database and stole everyone's login info.

[1713866525]

1713866525

[1713866525]

1713866525

[1713866525]

1713866525

[1713866525]

1713866525

[1713866525]

1713866525

[1713866525]

1713866525

[Serith]

So is there actually no one on these forums that can and is willing to explain in great detail how to go about one of these attacks?

Even if his intentions were not sincere, security through obscurity is a terrible terrible practice.  Despicable.

macintosh264: For every confirmation it gets that much harder for an attacker to (temporarily) create fake bitcoins.  1 Confirmation means that the transaction is in 1 block in the block chain, 2 confirmations means it is in 2 blocks, 3 means 3, etc.  In a nutshell what happened with MyBitCoin is that an attacker was able to mine a invalid block, then before the block was thrown out for being invalid mine another invalid block.  In these invalid blocks it showed him depositing bitcoins to MyBitCoin.   Because MyBitCoin only waited for 1 confirmation, it assumed that these were valid transactions and allowed him to withdraw the bitcoins.  The withdrawn bitcoins were included in the actual real block-chain and therefore remained valid even after the deposits from the fake blocks were thrown out.

If you wait for 1 confirmation an attacker has to mine 2 fake blocks in a row to trick you.  If you wait for 2 confirmations, they have to mine 3.  If you wait for 3 confirmations, they have to mine 4. Etc.

Every confirmation you wait for makes it exponentially more unlikely that you are being tricked.  Remember that a block is mined about once every 10 minutes, so it would take a great deal of computing power (and luck) to successfully stay ahead of the network for a significant amount of time to pull one of these attacks off.

With that in mind, 4 confirmations should be plenty.  3 would probably be plenty even.

I think it might be more complicated then it looks on the surface because then it would take only 4.8 hours on average for a big pool such as deep-bit to plant invalid transactions and hack system with 3 confirmations, 11 hours to hack 4 confirmations, 26 to hack 5 and 60 hours to hack MtGox with 6 confirmations.

[Xephan]

I think it might be more complicated then it looks on the surface because then it would take only 4.8 hours on average for a big pool such as deep-bit to plant invalid transactions and hack system with 3 confirmations, 11 hours to hack 4 confirmations, 26 to hack 5 and 60 hours to hack MtGox with 6 confirmations.

That's probably why it's bad if any single pool has close to 50% of the total hashing power. Deepbit's the only pool I know that has managed to strung 6 or more blocks in a row during the time I was recording down who found the blocks. In just the 1500 or so blocks, they had 4x 6 blocks run and get this: an 8 blocks run.

That said, it would still be hard for them to execute such a scam because there's no way for them to predict/guarantee they will get the next X blocks in any run. If they tried it repeatedly, I think it would be quite noticeable due to an unusual number of reorgs happening.

That said 4 and 5 blocks runs were quite common so Deepbit could possibly take a realistic gamble on hacking 2 or 3 confirmations.

[indio007]

I think it might be more complicated then it looks on the surface because then it would take only 4.8 hours on average for a big pool such as deep-bit to plant invalid transactions and hack system with 3 confirmations, 11 hours to hack 4 confirmations, 26 to hack 5 and 60 hours to hack MtGox with 6 confirmations.

That's probably why it's bad if any single pool has close to 50% of the total hashing power. Deepbit's the only pool I know that has managed to strung 6 or more blocks in a row during the time I was recording down who found the blocks. In just the 1500 or so blocks, they had 4x 6 blocks run and get this: an 8 blocks run.

That said, it would still be hard for them to execute such a scam because there's no way for them to predict/guarantee they will get the next X blocks in any run. If they tried it repeatedly, I think it would be quite noticeable due to an unusual number of reorgs happening.

That said 4 and 5 blocks runs were quite common so Deepbit could possibly take a realistic gamble on hacking 2 or 3 confirmations.

I think it's more profitable to stay honest and rake in all those fees than try to spoof the block chain. Especially if it works and they get caught.Bitcoin will be declared worthless by the world.

[cunicula]

I think it might be more complicated then it looks on the surface because then it would take only 4.8 hours on average for a big pool such as deep-bit to plant invalid transactions and hack system with 3 confirmations, 11 hours to hack 4 confirmations, 26 to hack 5 and 60 hours to hack MtGox with 6 confirmations.

That's probably why it's bad if any single pool has close to 50% of the total hashing power. Deepbit's the only pool I know that has managed to strung 6 or more blocks in a row during the time I was recording down who found the blocks. In just the 1500 or so blocks, they had 4x 6 blocks run and get this: an 8 blocks run.

That said, it would still be hard for them to execute such a scam because there's no way for them to predict/guarantee they will get the next X blocks in any run. If they tried it repeatedly, I think it would be quite noticeable due to an unusual number of reorgs happening.

That said 4 and 5 blocks runs were quite common so Deepbit could possibly take a realistic gamble on hacking 2 or 3 confirmations.

I think it's more profitable to stay honest and rake in all those fees than try to spoof the block chain. Especially if it works and they get caught.Bitcoin will be declared worthless by the world.

For now. In future years, generation rates will become low and fees will remain meager. Alternative revenue models will become more attractive.

[zellfaze]

I think it might be more complicated then it looks on the surface because then it would take only 4.8 hours on average for a big pool such as deep-bit to plant invalid transactions and hack system with 3 confirmations, 11 hours to hack 4 confirmations, 26 to hack 5 and 60 hours to hack MtGox with 6 confirmations.

That's probably why it's bad if any single pool has close to 50% of the total hashing power. Deepbit's the only pool I know that has managed to strung 6 or more blocks in a row during the time I was recording down who found the blocks. In just the 1500 or so blocks, they had 4x 6 blocks run and get this: an 8 blocks run.

That said, it would still be hard for them to execute such a scam because there's no way for them to predict/guarantee they will get the next X blocks in any run. If they tried it repeatedly, I think it would be quite noticeable due to an unusual number of reorgs happening.

That said 4 and 5 blocks runs were quite common so Deepbit could possibly take a realistic gamble on hacking 2 or 3 confirmations.

I think it's more profitable to stay honest and rake in all those fees than try to spoof the block chain. Especially if it works and they get caught.Bitcoin will be declared worthless by the world.

For now. In future years, generation rates will become low and fees will remain meager. Alternative revenue models will become more attractive.

In the future, generation rates ought to be low enough that no one could possibly do this again.  Serith: If I understand the system correctly, Deepbit could cheat the system.

[vector76]

You don't need to mine 2 blocks in a row.  Mining a single block is sufficient if the network resolves the fork the way you want, and it might be possible to set things up so that this is likely.

Let's say I observe the timing of when nodes are broadcasting transactions and how they are propagating through the network.  By watching for which nodes are earliest to broadcast transactions from my target, I manage to establish a direct connection to my target.

I use a similar method of watching block broadcasts to establish connections to most of the mining pools.

Now I create a transaction making a valid, large deposit into my target.  I do not broadcast this transaction but I add it to a block that I am attempting to mine.  I mine solo, just like normal, except that I have an extra non-broadcasted tx that I am including.

Eventually, I succeed in creating a valid block.  I do not broadcast it immediately, but instead I wait until someone else mines a block, and when that happens, I immediately broadcast my block to my target.  If my target sees my block before the other block, they will accept it, and my transaction will have one confirmation.  The block chain has forked, and my target (and possibly other nodes, if my target relays quickly enough) will believe that my block is the correct one, while other nodes will believe that the other fork is the correct one.

I immediately request a withdrawal, and my target generates a transaction sending the large amount of coins to an address I control.  I also double-spend some of the inputs, sending the coins to myself.  The part of the network that did not receive my block first (which hopefully is most of the miners) will accept this as valid and work to include it in the next block.

If my block eventually "wins" because enough miners saw my block first and added onto it first, then I have just made a deposit and withdrawal, and I lose nothing.

If my block eventually "loses", then the deposit is invalidated.  If the deposit tx was not one of the inputs to the withdrawal transaction, then the withdrawal is still valid.

[Valalvax]

I don't know if you've been answered, but the trolling was getting boring to read

The way the hack is done is the server keeps track of how many bitcoins it has, someone with access to the server told it that bitcoins were deposited, then logged into their account and withdrew the coins.. same thing (sort of) that happened with MtGox

[Gavin Andresen]

+1 for vector76's hypothesis.

If mybitcoin was running bitcoin behind Tor, and had just one connection (through a Tor exit node) to the rest of the bitcoin network, then they'd be particularly susceptible to this 1-confirmation attack.

[zellfaze]

+1 for vector76's hypothesis from me as well.

This seems a lot more likely than my double block mining hypothesis.  This would also be harder to protect against.

Anyone have ideas about how to stop this sort of attack?

[SgtSpike]

+1 for vector76's hypothesis from me as well.

This seems a lot more likely than my double block mining hypothesis.  This would also be harder to protect against.

Anyone have ideas about how to stop this sort of attack?

Have your node connected to LOTS of other nodes.  Someone correct me if I am wrong.

[0x6763]

You don't need to mine 2 blocks in a row.  Mining a single block is sufficient if the network resolves the fork the way you want, and it might be possible to set things up so that this is likely.

Let's say I observe the timing of when nodes are broadcasting transactions and how they are propagating through the network.  By watching for which nodes are earliest to broadcast transactions from my target, I manage to establish a direct connection to my target.

I use a similar method of watching block broadcasts to establish connections to most of the mining pools.

Now I create a transaction making a valid, large deposit into my target.  I do not broadcast this transaction but I add it to a block that I am attempting to mine.  I mine solo, just like normal, except that I have an extra non-broadcasted tx that I am including.

Eventually, I succeed in creating a valid block.  I do not broadcast it immediately, but instead I wait until someone else mines a block, and when that happens, I immediately broadcast my block to my target.  If my target sees my block before the other block, they will accept it, and my transaction will have one confirmation.  The block chain has forked, and my target (and possibly other nodes, if my target relays quickly enough) will believe that my block is the correct one, while other nodes will believe that the other fork is the correct one.

I immediately request a withdrawal, and my target generates a transaction sending the large amount of coins to an address I control.  I also double-spend some of the inputs, sending the coins to myself.  The part of the network that did not receive my block first (which hopefully is most of the miners) will accept this as valid and work to include it in the next block.

If my block eventually "wins" because enough miners saw my block first and added onto it first, then I have just made a deposit and withdrawal, and I lose nothing.

If my block eventually "loses", then the deposit is invalidated.  If the deposit tx was not one of the inputs to the withdrawal transaction, then the withdrawal is still valid.

+1 vector76. You posted exactly what I was going to say.

[vector76]

+1 for vector76's hypothesis from me as well.

This seems a lot more likely than my double block mining hypothesis.  This would also be harder to protect against.

Anyone have ideas about how to stop this sort of attack?

When the block chain forks, the "true" chain is ambiguous by design.  The algorithm only promises that it will resolve eventually.

There might be ways of reducing the likelihood of this attack, but it is inherent in the system.  You stop it by waiting for several confirmations.

[willphase]

also keeping the ip address of your bitcoin node private protects you from this attack to some extent, because it's harder to relay invalid blocks across multiple nodes.  But just to be absolutely clear, this is merely 'security through obscurity' - the best way is to wait for multiple confirmations.  Perhaps if more bitcoin services published their source then there would be more peer review and people might spot this stuff (or maybe people would just find vulnerabilities and exploit them...?  who knows... seems to work for Linux?)

Will

[Silverpike]

+1 for vector76's hypothesis from me as well.

This seems a lot more likely than my double block mining hypothesis.  This would also be harder to protect against.

Anyone have ideas about how to stop this sort of attack?

When the block chain forks, the "true" chain is ambiguous by design.  The algorithm only promises that it will resolve eventually.

Wait, I thought this statement isn't true.  My understanding is that potential forks in the chain are resolved according to whichever winning hash has the lowest absolute value (highest difficulty).  This scheme is at least deterministic.

Is this correct?

[RaTTuS]

mybitcoin was killed by the owner taking all the coins - sent to them
no hacking of the blockchain is needed,
in my opinion ...
lots of stuff has been said about how who and why but Occam's razor probably covers it.

[film2240]

Look. My intentions are sincere. To test this exploit out on my own e-wallet (bitcoin debit cards). I am not trying to hack anyone. Please only respond if you want to help me perform the exploit on my own site (do not attempt it yourself  ), I believe I have it soundproof, but I want to protect the coins from the people who hacked mybitcoin and others. I need to test it myself, and find a way to prevent it.

Hang on a minute,this sounds similar to this:http://www.youtube.com/watch?v=-UyoWDDbOcI However with version 0.3.24 of the Official Bitcoin client,this hole has been fixed.If I'm right or wrong on this,I'd like to hear from you,so I can protect my 3 systems from the hack.

[AssemblY]

You should stop saying "what happened with mybitcoin" because in all honesty YOU DON'T KNOW!

All we can do is throw around suspicions. All we have is the dude saying that someone faked transactions with their shopping cart interface, but i bet he would prefer to say that if he wanted to run away with the coins.

Even if that was what happened, i bet the error was with mybitcoin and had nothing to do with the blockchain.

If you account for some informer that dropped by #bitcoin-police, it was because of a bug mybitcoin had in their code that wasn't calculating stuff right.

Like i said, all suppositions, no answers!

I agree, are just suppositions. He could have simply stolen the coins, and invented this story. 

[etotheipi]

I really like vector76's hypothesis, and I recognize it's only speculation.  But it sounds like feasible, targeted attack.   It would also explain why there was no evidence on any others' systems of a forked blockchain.  MyBitcoin was one the only node that directly received this invalid block, and most other nodes probably had the soon-to-be-real block before MyBitcoin could forward it to peers.

Let's assume this is what happend.  My question is, how did the attacker receive his "goods" for the "fake coins" that he sent.  I presume it was a BTC withdrawal from MyBitcoin.  If so, then MyBitcoin had to construct the transaction while it was on the invalid blockchain.   I am assuming that other nodes receiving the transaction don't know what blockchain MyBitcoin thinks is the current one, they only care whether the TxOuts referenced are valid.  But there will be a problem if MBC uses outputs from the transaction it just received.

For instance:  If MBC only has 1000 BTC total in it's accounts.  The attacker deposits 5000 BTC using this attack, and then immediately withdraws it at 1 confirmation... there is no way for MyBitcoin to process the withdrawal request without using outputs of the transaction that will ultimately be invalid.  Then when the first transaction becomes invalid, so will the withdrawal.  The attacker gains nothing.

I presume that "standard logic" was being used to select TxOuts for withdrawals/transfers.  Probably used the oldest coins available, which most definitely wouldn't be the coins that MyBitcoin just received.  As long as the attack is for fewer bitcoins than MyBitcoin started with, the attack would be successful.  The defense against this (besides just making people wait for 6 confirmations), would be to "quarantine" TxOuts of new transactions until they are at X confirmations.  Any withdrawal requests made by the same user would be processed with only his own TxOuts.  Therefore, if his deposit was a invalidated, so will his withdrawal. 

Of course, this only passes on the problem to other members if they process transfers.  MyBitcoin would be safe from losing money, but the recipient of the money would ultimately get screwed by the double-spend.  The attacker deposits N btc, then MBC sends N btc to another member with the TxOuts from the first.  Of course, ethically speaking, MBC would still be "liable" for the missing coins, but they could just hypocritcally claim that the recipient should've waited for 6 confirmations before acting on the transaction.

[gmaxwell]

I really like vector76's hypothesis, and I recognize it's only speculation.  But it sounds like feasible, targeted attack.   It would also explain why there was no evidence on any others' systems of a forked blockchain.  MyBitcoin was one the only node that directly received this invalid block, and most other nodes probably had the soon-to-be-real block before MyBitcoin could forward it to peers.

This still leaves evidence: Mybitcoin could provide a copy of their blocks file, which would still contain the orphan block even if no one had it.

It's evidence which could be faked, but only at non-trivial cost.