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

4 minute read

Posted by: iBurnEZ </a></span> August 21, 2014

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.

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

</div>

Updated: 2014-08-21