FORWARD

I have been working on this article for a couple of weeks now and have not finished my research. However, given the latest developments I feel as though I should share my initial findings with you ASAP. I have my own Bitcoins (oops – that breaks one of my rules) and hope that the advice at the end of this post will help the Bitcoin community in general.

http://news.yahoo.com/s/afp/20110617/ts_alt_afp/usitcrimecomputersecurityinternetbitcoin

Firstly, let me say that I am not a hacker and that I have no intention of perusing any of this other than in an academic nature!

Given the “theft” this week of 25,000 Bitcoins ($500K) from someone’s wallet this week (http://thenextweb.com/industry/2011/06/15/close-to-us500k-stolen-in-first-major-bitcoin-theft/) I started to ask myself how secure is the Bitcoin system?

Lets work through some scenarios ….

Select a victim

The Bitcoin “Rich List” would seem like the logic starting point – http://bitcoinreport.appspot.com/

Here I select address “1GQnMbeEmUA9g6iypZYhUg4PKsZEswzAYy” as the notional victim as they seem to have 6592 lovely Bitcoins for me to steal!

THREAT 1: The open and distributed nature of Bitcoins means that everybody can read and analyse the block chain as does the Bitcoin Report. This is equivalent to banks giving out details (anonymously) of everybody’s current balance!

Identify the victim

Here I pick a pseudo random post from the Bitcoin forum (http://forum.bitcoin.org/) because:

They are a Hero member (and therefore should have quite a few Bitcoins)

They give me a Bitcoin address

They give me their nick name – “xf2_org”

They give me their real name

Given the above information a very quick bit of Google-ing provides further information about this person:

A website

A link to an email address

Another website

A contact number

Another email address

A Twitter address

23/06/2011

Additional information removed from original post as requested

As you can see I can quickly find a lot of information to tie with a Bitcoin address in order to launch a targeted attack.

I could take it further via email and Twitter tweets to try to get an IP address for the conversation, just in case they were running the Bitcoin client on the same machine as they interact with me. Let’s not forget that when you receive an email you receive more than just the message. An email comes with headers than contain information that can tell where the email was sent from and possibly the IP address of the sender.

THREAT 2: Bitcoin addresses and the Internet allow me to link real people to Bitcoin wallets. Yes, I know that you can have multiple addresses per Bitcoin client install but human nature means in reality that only 1 address will be used to receive transactions. With Bitcoins, this information is the equivalent of somebody’s bank account and sort code which we all know that real world hackers are very interested in ….

Using Block Explorer (http://blockexplorer.com) I can dig a bit more into a Bitcoin address and determine useful information such as the number of transactions, the amount of BTC sent and received, when the address what first and last used etc. etc. In the case of the address above:

First Seen: 2011-05-18 16:42:43

Received transactions: 5

Received BTC: 3.4601

Sent transactions: 3

Sent BTC: 0.4501

Last Used: Block 130904 (2011-06-15 03:30:05)

Note: While the last “balance” is the accurate number of bitcoins available to an address, it is likely not the balance available to this person (victim!). Every time a transaction is sent, some bitcoins are usually sent back at a new address makes the balance of a single address misleading.

What I also find are two sent transactions to two other Bitcoin addresses- I wonder if these addresses are being used for a deposit wallet? [See later]

THREAT 3: There is a lot of useful information that can be determined through analysis of the open block chain!

Locate the victim’s wallet(s)

Previously I mentioned one possible way to try to find the IP address of the machine where a Bitcoin client may be running (and hence where a wallet could be located) in order to launch a targeted attack.

However, the Bitcoin architecture is based on Peer to Peer (P2P) technology and all P2P networks have a bootstrapping problem since without central servers, nodes (Bitcoin clients) on the network need to be able to find each other.

Bitcoin solves it using three mechanisms (with some old discussion here – http://forum.bitcoin.org/?topic=84.0):

By default, Bitcoin clients join an Internet Relay Chat (IRC) channel and watch for the IP addresses and ports of other clients joining that channel

There is a list of “well known” Bitcoin nodes compiled into the software in case the IRC chat server is unreachable for some reason

You can manually add (via configuration file or command-line option) IP addresses of other machines running Bitcoin to connect to. Some people use the fallback node list here: https://en.bitcoin.it/wiki/Fallback_Nodes

Each Bitcoin client connects to IRC and stays connected. Using IRC messages the client connects to found peer IP addresses on port 8333.

Once connected to the Bitcoin network, other Bitcoin nodes (machines) send messages containing IP addresses (and ports) of other nodes they know about. Internally Bitcoin client communicate with each other and broadcast new nodes via the Bitcoin protocol on port 8333. However, they are always online in IRC.

An example of the IRC bootstrapping can be found in the “debug.log” file from the Bitcoin client:

The official Bitcoin source code is available here (https://github.com/bitcoin/bitcoin) and an open source Java client is available here (http://code.google.com/p/bitcoinj/).

Using a standard IRC client (mIRC, KVIrc, XChat, Colloquy etc.) it is very easy to connect the Bitcoin bootstrapping IRC channel. The bootstrapping IRC server is LFNet (irc.lfnet.org) and the channel is #bitcoin. The username and nickname are initially set to a random number prefixed with “x” e.g. “x781631660”. The nickname is later changed to an encoded IP address prefixed with “u” based on the client’s external IP address as seen by the IRC server prior to performing a “JOIN” then “WHO” on the #bitcoin channel. Of course the decode function is also available in the source code so we can turn any nickname back into an IP address. In fact, this is exactly what a Bitcoin client does – it sits there listening for “JOIN” and “WHO” messages and if the message relates to a nickname prefixed with “u” it decodes the nickname to get the external IP address of the Bitcoin client.

Alternatively, we can of course just send a “WHO” or “USERHOST” request to get IP address information using an IRC client:

THREAT 4: Based on the source code of the Bitcoin client I could create a “spoof” Bitcoin node which joins the network and then waits for connections from other (genuine) Bitcoin clients. Since the connection is two-way I am then effectively connected to a machine which in all probability also has a Bitcoin wallet stored on its hard disk. If I could exploit this connection in some way (like a good old fashioned TCP buffer overflow exploit – Intrusion.Win.NETAPI.buffer-overflow.exploit) I could take control of the machine and copy their wallet. This is a bit like the ATM network being connected via IRC!

But guess what – life is even easier for a thief who is trying to find the IP address of all machines where a Bitcoin client may be running (and hence where a wallet could be located). This is because each Bitcoin client stores the IP address of all previously discovered peers in a file named “addr.dat” and the chances are that Bitcoin will be running on each of these machines from time to time and listening on port 8333.

THREAT 5: Based on the source code of the Bitcoin client I could read all of the IP addresses stored in the address database and then sequentially try to connect to the Bitcoin client likely to be running on each machine using port 8333. IMHO it is only a matter of time before such an exploit becomes reality.

17/06/2011

I am still researching further into this. The JSON-RPC interface on port 8332 is the biggest threat since there is a “nice” method called “sendtoaddress”. The interface is secured in various ways and the TCP bind address is set to the loopback address unless the option “rpcallowip” is set. If it is set then the bind is on any IP address which means that a physical connection IS possible. There are additional checks behind it such as authentication (including deterring brute-forcing short passwords less than 15 characters) but BEFORE the authentication is checked, the HTTP headers are mapped.

The standard Bitcoin protocol port on 8333 is another threat and implicit in the P2P architecture. There could be the possiblity for SOCKET exploits here trying to either shell out to copy the wallet or even access the contents of the wallet in memory e.g. using Bitcoin commands “getdata”, “getblocks”, “getheaders” with invalid payloads to reveal the contents of the wallet and/or call “SendMoneyToBitcoinAddress”.

23/06/2011

Having been through the source code in some detail I have now convinced myself that the code is written in a very professional manner and that all reasonsable steps have been taken to protect the interfaces exposed by the Bitcoin client. This does not of course mean that bugs cannot introduce vulnerabilities in the future versions.

On the balance of probability I think that an exploit would be as the result of standard Remote Access Trojans (RAT) using the IP addresses exposed as an inherent part of the P2P network and the IRC bootstrapping process. Therefore, I would still recommend running with the “noirc=1” option and only connecting to trusted peers.

THREAT 6: Running the Bitcoin client permanently in the background is an inherent part of the Bitcoin Peer to Peer (P2P) architecture. There is a financial incentive to do so in terms of Transaction Fees. Therefore, many people leave the machine hosting their Bitcoin client (and also their wallet) running 24 hours a day. This is even more so if they are Bitcoin mining at the same time. This means that their wallet is also open to attack 24 hours a day ….

Please see the end of this post for ways to protect your self from the threats outlined above!

Access and steal the wallet(s)

THREAT 7: Everybody knows that the weak point in the system is an individual’s wallet which is stored unencrypted on the hard disk where the Bitcoin client is installed. On a Windows 7 install this is located in C:\Users\<user>\AppData\Roaming\Bitcoin\wallet.dat. Steal this file and steal the contents of the wallet.

http://news.yahoo.com/s/afp/20110617/ts_alt_afp/usitcrimecomputersecurityinternetbitcoin

THREAT 8: Although it is possible to have multiple wallets, human nature again means in reality most people only use a single Bitcoin wallet rather than keeping a separate, more secure and importantly offline deposit wallet which inherently is less prone to theft.

Access to copy (steal) the wallet can be achieved by getting the user to download and install some malicious application such as the notorious Bitcoin wallet backup utility or something guised as a Bitcoin Mining application ….

THREAT 9: In the rush for gold everybody is keen to download and install the latest and best Bitcoin miner software without even thinking twice as to whether it could contain a Trojan.

Alternatively, I could take remote control of the machine running the Bitcoin client software covertly using standard Remote Access Trojans (RAT).

THREAT 10: Anonymity. At the end of the day, as a decentralised network with no authority and no identities attached to the addresses used to send and receive Bitcoins, once Bitcoins are stolen they’re as good as gone. Although there is an alerts mechanism built into the Bitcoin client is does not seem to be used for much now.

And finally ….

THREAT 11: The Bitcoin network is open to attack in general. The longest block chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. Effectively, the majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. Proof-of-work is essentially one-CPU-one-vote.

Therefore, so long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they’ll generate the longest block chain and outpace attackers. Hence, the Bitcoin system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes. Given the vast amount of hardware being thrown into Bitcoin mining, what happens to this hardware once mining is no longer cost effective? Could this redundant hardware be pooled into an attack such that honest nodes are overrun by attacker nodes?

A Bitcoin whitepaper says:

“The incentive (to mine blocks and generate coins) may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments or using it to generate new coins. He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.”

Mmmm … if this ever did happen a lot of elements of (dare I say it) a Ponzi scheme (http://en.wikipedia.org/wiki/Ponzi_scheme) would come into play …

Hopefully this post has given you food for thought and you will now take the necessary actions to secure your wallet(s)!

My recommendations are:

Don’t go broadcasting one of you receiving Bitcoin addresses looking for donations. Make sure you use different Bitcoin address for different transactions

Be careful what you post on the forums

Run your Bitcoin client with your daily working wallet with options “noirc=1” and “nolisten=1” set. Also consider adding “ connect=” lines rather than “addnode=” lines so that you only connect to trusted Bitcoin peers. These settings will ensure that a) you do not broadcast your IP address and b) you do not accept connections from the outside

working wallet with options “noirc=1” and “nolisten=1” set. Also consider adding “ lines rather than “addnode=” lines so that you only connect to trusted Bitcoin peers. These settings will ensure that a) you do not broadcast your IP address and b) you do not accept connections from the outside DO NOT set the option “rpcallowip”

Keep an offline deposit wallet with the majority of your Bitcoins in it. Make sure that this is backed up somewhere safe

deposit wallet with the majority of your Bitcoins in it. Make sure that this is backed up somewhere safe Be very careful what software you download and install – especially for Bitcoin mining. Do not run mining software on any machine that any wallet is installed or accessible from

I hope this post has been of some use to you. If my blog has been hit by a DDoS attack you know I have been talking too close to the mark! Backup your wallet, sleep well and keep trading!

PS: Donations accepted to:

1L5GQ6JiUkSeLBgsdoy9e9wGKqbvn2mgUH

Yes I know this breaks one of my recommendations but I had already published this address! Don’t worry, only my daily working wallet is online.