Bitcoin Transaction Malleability Theory in Practice – Blackhat USA 2014

***UPDATE: 10/17/2014

A demonstration of Bitcoing transaction malleability using PUSHDATA2 is now available:

The demonstration was created by Daniel Chechik, Rami Kogan and Ben Hayak.

***

This August we (Daniel Chechik and Ben Hayak) gave a talk at Blackhat USA 2014 about a known yet mysterious vulnerability in Bitcoin called "Transaction Malleability." In our session we first presented a brief overview of the Bitcoin concept and its structure, then proceeded to explain what we consider the most interesting Transaction Malleability technique. Finally we showed how to use it in practice by using a live demo.

In general, the Transaction Malleability vulnerability is about mutating transactions using their valid content with slight and "harmless" changes while keeping the transaction signature valid, and then relaying the mutated transaction back to the network. In the Bitcoin protocol every transaction is identified by a hash of all the transaction's content, so by mutating a transaction the modification will result in a different Transaction ID. Such modifications might affect websites or services that rely on the integrity of the transaction only by tracking the transaction ID. 

Questions & Answers

Here are some of the questions that came up after our talk that are worth mentioning:

Q: Is it still possible to use transaction malleability now that PUSHDATA opcodes are patched?

A: Yes. We presented a single transaction malleability technique that we considered to be the most interesting one. The technique we showed cannot be used with the patched PUSHDATA opcodes, but there might be other ways to perform transaction malleability.

Q: Was Transaction Malleability using PUSHDATA opcodes used to attack Mt.Gox?

A: According to Mt.Gox, the attackers used Transaction Malleability in the attack. After extracting data from the entire block chain, we found that attackers only massively exploited Transaction Malleability using the "PUSHDATA" technique after Mt.Gox halted all transaction withdrawals. This technique, however, is only one of the ways to exploit Transaction Malleability, so it is possible that Mt.Gox was exploited by another type of Transaction Malleability.

Q: What are possible countermeasures against a Transaction Malleability attack?

A: Tracing the Transaction ID might be the easiest way to ensure whether a transaction that has been sent by one system was delivered to its destination. In cases where the transaction has failed, however, it's important not to automatically re-generate a new transaction and to instead understand why the original transaction failed. In the case of Transaction Malleability, even though the original transaction failed, the Bitcoins were delivered successfully to the recipient.

 Additional Notes

During our session we showed a full live demo including a simulation of how to practically attack stock exchange websites using Transaction Malleability. We built our own personal Bitcoin network and a website which we created for the purpose of the presentation.  

 

We also wrote a tool for exploiting Transaction Malleability. One of the difficulties in achieving  successful exploitation is winning the race between the mutated and the original transactions. Once a new transaction is placed, it is broadcasted to the entire network. The mutated transaction has to be broadcasted before the original transaction in order to increase the chances of successful exploitation. In order to achieve this in our live demo, we exploited every step manually without a tool and ensured that the mutated transaction was the one that going to get mined instead of the original one. In a real scenario an attacker obviously will use a tool to exploit this attack by "listening" to the peer that broadcasted the original transaction and spreading the mutated transaction to as many peers as possible. This will result in much higher odds of winning the race. The tool we provided allows you to configure what peers you send the mutated transaction to using a "peers" file that should contain "important peers". An idea for increasing the success rates of an attack would be to send the mutated transaction to very powerful mining peers, since that makes it more likely that your mutated transaction will be included in the block chain.

Both the tool and the presentation can be found on the Blackhat website.

The latest version of the presentation can be downloaded from here.

Thanks for joining our talk!