Bitcoin Forum

So, I understand that MyBitcoin was killed by someone who sent fake bitcoins, and confirmed them once somehow, and then made a withdraw of those coins. Of course those coins did not exist, so he actually withdrew other user's coins. My question is what are the technical details on this type of attack. I wanted to know how it is done, solely out of curiosity.

Thanks,
Joey.

Snake:  "Wallet Inspector!  Hand over your wallets!"
Suckers:  "OK sir, I believe this is all in order..." :::hands over wallets:::

I am serious. I want to understand how this is done so I can identify any type of exploit on my own site. http://www.bitcoindebit.co.cc (redirects to https://www.bitcoindebit.net)

What I am trying to do is perform this exploit on my own site and find a way to prevent it. I need to perform the exploit in the first place to see what actually occurs on my site.

Lol, solely out of curiosity my ass.

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.

I don't know how to program, unfortunately, or I'd probably hack everything  ;D

Short answer: mybitcoin waited for only 1 confirmation, instead of 6, to deposit bitcoins, or so they say.

Long answer: you will have to spend couple weeks reading available documentation and exploring source code to get full understanding of how it happened

Alright. So the source code sends the coins, but how did he force a single confirm on the transaction. Did he exploit something having to do with mining. What happened there?

honestly I don't know either, but I believe Theymos who originally posted about the possibility of such an attack said it would be trivial for anyone who can mine two blocks in a row.   So I assume yes it did have something to do with mining, I presume the attacker was a large miner and was able to mine two blocks in a row, adding his transactions of 'fake bitcoins' to the blockchain.  Eventually the 'real' blockchain took back over and his blocks weren't a part of the real blockchain anymore.

as long as you don't accept transactions from 1 confirmation, you should be safe from this attack.  The more confirmations, the more sure you can be that the transaction can't be reversed

the problem is, apparently, that nobody can find these supposed double spends on any reorgs: http://bitcointalk.org/index.php?topic=34770.msg434895#msg434895

You don't need to exploit to patch ... Simply wait 6 confirmation when people send funds into your wallet before releasing anything (goods / other currency etc) and you won't have the mybitcoin problem.

Do you think it is safe to allow people to use their bitcoins at 4 confirmations. Because I am an e-wallet, people want to use their coins the second they get them. Of course I cannot do that, but is 4 sufficient. Can someone really fake 4 whole confirmations?

Nobody can fake blocks, they can mine them in a row
I think even 3 confirmations should be enough

Sorry, that is what I meant to say. Fake Confirmations, by mining blocks in a row.
Okay. I'll be on the safe side and give no access to coins from transactions without 4 or more transactions.

Thanks,
Joey

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.

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

Wasn't Mtgox a fake bitcoin hack too? Not to the bitcoin client but to the trading program?

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. :P

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

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! ;)

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.

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.

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.

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

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

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

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

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.

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

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?

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.

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.

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

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.

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.

My understanding is that blocks that are not on the best chain are still relayed, otherwise people will get stuck on the wrong chain.  So even if the block were only sent to the target, the target should have relayed it and the rest of the network should have seen it.  The network does not know which fork will be extended next, so everyone will have to have both.

An "innocent" fork that occurs by pure chance should have the characteristic that all transactions in the abandoned block are included either in the "true" block of the same height, or in the next block.  I think reversing a transaction will require a transaction in an abandoned block to be invalidated in the "true" fork due to a double-spend.  It seems unlikely that such a transaction reversal could happen by accident.

In the case that there are two equal-difficulty-sum chains, the node processes whichever block it received first.  They won't discard the second block, but they won't be trying to extend it if they saw the other one first.   If MBC is behind Tor and the attacker studied the network latencies well, most miners will see the "legit" block first, and that "legit" chain will most definitely get extended first.  (I'm using "legit" here, because I don't know any other way to refer to the non-attacker chain... there is, of course, nothing wrong with the attacker's block except that that chain is unlikely to get extended)

If transactions carry over between from invalidated chains, then the attacker should send himself a small transaction using one of the outputs he used in the huge deposit transaction, to be included in the "legit" block while he waits for it.  By doing this, he guarantees that the large deposit is DOA on the new chain in case the nodes decide to carry it over.  Otherwise, it's possible that the deposit will be transferred to the new chain and the double-spend fails.