Home » Articles » BTC Transaction Malleability Theory: What Happened to SR 2.0 and Mt.Gox
Click Here To Hide Tor

BTC Transaction Malleability Theory: What Happened to SR 2.0 and Mt.Gox

Before we get started I’d like to address the people who are about to flame the hell out of me for including Mt. Gox in the list of those affected by Bitcoin transaction malleability. The role this vulnerability played in the Mt. Gox shenanigans is debatable, but Trustwave researchers Ben Hayak and Daniel Chechik included Mt. Gox in their Black Hat presentation “Bitcoin Transaction Malleability Theory in Practice,” so I will also include it here.

Bitcoin transaction malleability is the bug responsible for the theft of 4,500 Bitcoins (approx. $2.6 million) from the SilkRoad2.0. Mt. Gox will go down as one of the largest robberies in history, someone relieved the Bitcoin exchange of 850,000 Bitcoins ($465 million+). Investigators were able to recover about 200,000 Bitcoins but 650,000 ($355 million+) remain unaccounted for.

The Bitcoin transaction malleability works in favor of the recipient of the transaction. As far as I’m aware this vulnerability has not been used in transaction between two private parties. The obvious targets were vulnerable Bitcoin exchanges and darkmarkets who store users Bitcoins in a central location. Attackers used Bitcoin transaction malleability to endlessly request Bitcoins from their accounts, eventually draining all of the Bitcoins from these targets.

To understand how hackers were able to exploit the Bitcoin transaction malleability you need to have a basic understanding of how Bitcoin transactions work.

A laymen’s overview of Bitcoin transactions:

Bitcoin transactions require the same basic information you would expect in any other transaction. The following information is considered critical, once a transaction has been initiated making a change to any of this information will invalidate the transaction.

  • Information identifying the sender (senders BTC wallet address)
  • Sender’s signature to verify consent (sender’s private key)
  • Amount of the transaction
  • Information identifying the recipient (recipients Bitcoin wallet address)
  • Recipient’s signature to verify their identity (recipient’s public key)

The above information is combined with other “peripheral” information and hashed to generate a unique transaction ID which is used to track the transaction in the block chain. This is a key point about the Bitcoin transaction process, when you input the exact same information into a hashing algorithm you will always receive the exact same output (transaction ID). Changing the input information even slightly will generate an entirely new transaction ID.

The critical information and transaction ID are then sent to the block chain (a historical ledger of all Bitcoin transactions) to be verified by Bitcoin miners. If all information is correct the transaction ID is verified and the funds are transferred. If any information is invalid the transaction ID will be rejected.

Bitcoin transaction malleability:

The theory behind Bitcoin transaction malleability is to intercept the transaction information before it reaches the block chain and make minor changes to the peripheral information that will generate a new transaction ID but not invalidate the transaction.

Peripheral information includes the byte length of the transaction which can be changed while still maintaining the integrity of the data. For example if the byte length of the transaction is 2 bytes, it could also be written 002 bytes. When the new information is hashed this slight change generates an entirely new transaction ID.

standard-mutated BTC

This creates a race condition between the two transaction IDs, the mutated transaction ID must arrive to the block chain first to invalidate the original transaction ID. The block chain treats these transactions as duplicates and validates the first transaction ID and rejects the second transaction ID. When the mutated transaction ID is verified the funds are transferred to the recipient.

The sender tracks the original transaction ID and has no idea a mutated transaction ID exists or it has been verified. The funds have been transferred from but there is no record of this activity from the senders account. Since original transaction ID has failed there is no reason to deduct anything from the balance of the senders account.

Hopefully you can see where this is going, using the Bitcoin transaction malleability someone can, and did, endlessly withdraw funds from their exchange or darkmarket accounts and the balance will never change.

The storage of Bitcoins in a central location is a fundamental flaw of Bitcoin exchanges and darkmarkets. Individual account balances are funded from the central Bitcoin cache, this allowed the attackers to drain the entire combined balance from a vulnerable target.

The fallout:

We must give credit where credit is due, Silk Road 2.0 made efforts to repay all users for the stolen Bitcoins by invoking a tax on all transactions. Essentially the community paid themselves back but the accounts affected by the theft were made whole.

As for the Mt. Gox the investigation continues, we may never know what really happened or the exact numbers involved with the theft.

Fortunatley, this particular bitcoin transaction malleability has been addressed and is no longer exploitable. But if there is one thing I learned at Black Hat this year is it is only a matter of time, nothing is secure, everything will be hacked, eventually.

The tools used by Ben Hayak and Daniel Chechik to demonstrate this vulnerability can be found in the Black Hat USA 2014 archives, or downloaded directly here.

https://www.blackhat.com/us-14/briefings.html#Bitcoin-transaction-malleability-theory-in-practice

http://blackhat.com/us-14/archives.html

http://blackhat.com/docs/us-14/materials/us-14-Chechik-Malleability-Tool-Tool.zip

3 comments

  1. http://arxiv.org/abs/1403.6676 seems to have debunked Mtgox’s claims about transaction malleability, and given Mtgox’s demonstrated incompetence, I don’t see much reason to credit any of their claims.

    Likewise, SR2 has backed off the transaction malleability explanation: http://motherboard.vice.com/read/how-silk-road-bounced-back-from-its-multimillion-dollar-hack

    > In the wake of Mt. Gox claiming that their Bitcoin exchange service had been the victim of a documented weakness in Bitcoin known as “transaction malleability,” it was thought Silk Road had suffered a similar attack. But after weeks of internal investigations, and with coveted members of the community offering to help, Defcon told me that staff concluded there was a vulnerability in the “Refresh Deposits” function of the site. Using this, the hacker was able to spam the link and exponentially credit their account with more and more bitcoins, taking them out of the section of Silk Road that stored the currency while it was being traded. A large stockpile of bitcoin was in transit at the time because of planned upgrades to the infrastructure of the site.

  2. a good theory on the SR2 hack is that it was infact an inside job planned by the administrators of SR2. The idea was to rather than take a small commissions over a long period of time, they wanted to build a large nest egg so if the feds or any other LE was on their tail they could simply disappear with a nice fortune rather than what ever they had in commission.

    They could easily make a statement that they would repay people with all future commissions because if, A) every one abandoned the site, they would still have their egg, B) if people continued to use the site after the hack they would be repaid any way. with the added benefit of people who never come back to reclaim.

    I find it hard to the excuse of transaction malleability was the case in SR2.0. it is possible it was part true for emptyGOX as it was a long ongoing thing that eventually meant their internal DB didnt match the wallets which is why they made it increasingly difficult/ stopped withdrawals but continued trading. The SR2 hack was announced instantaneously with no for-warning of an issue with the site

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Captcha: *