Haha, I had the same idea.
The since (valid) transactions are passed freely to all nodes in the Bitcoin network, one can just use the network as a signed messaging platform.
You don't need to query blockchain.info, all you need is a Bitcoin client that listens for incoming transactions.
I've been writing an implementation on and off for a while now.
The general idea is as follows:
The botnet client connects to "n" Bitcoin nodes. If the same transaction is relayed by ceil(n/2) nodes, then we say that transaction is "confirmed" and examines the transaction to see if it's sent from botmaster's address (in fact we don't even have to use the botmaster's address, with BIP-0032 (https://github.com/bitcoin/bips/blob/master/bip-0032.mediawi...), we can use related public keys)
You don't even have to use transactions ("tx" messages), you can use the block messages if you are willing to tolerate an (on average) 10 minute delay, this would drastically reduce the network traffic sent/received by the botnet client.
But these guys forced my hand, so I suppose I'll have to release what I have so far.
The current botcoin client (c++11 with boost::asio) connects to the network, and gets transactions.
Data extraction from transactions is unfinished.
The current problem I'm working on is making sure that people cannot easily scan the Blockchain to look for c&c transactions. This can easily be done by encrypting the messages with a client specific key.
However, I would like to have perfect forward secrecy, that is, suppose a sample client was obtained by researchers, past c&c messages should not be able to be decrypted (otherwise the blockchain contains a log of all of your C&C messages).
I'm not surprised that someone else had the idea. Honestly, the fact that it wasn't in the wild yet surprised me. Great code, I'll be looking over it in my free time!
Are you aware of Dave Dittrich's work at University of Washington? He wrote a nice overview on secured P2P C&C networks in Storm and Nugache that you might find interesting:
I cited one of his papers actually, I didn't know that site with all his works existed though. Thanks for the link, I'll read some more of his writings.
It seems that even DHT based botnets need to hard code initial peers. Using the Bitcoin network eliminates this completely (now you need just need Bitcoin's bootstrap nodes).
> You don't even have to use transactions ("tx" messages), you can use the block messages if you are willing to tolerate an (on average) 10 minute delay
Does this mean you can send messages without transfering bitcoin from one account to another?
I think the meaning is that you still post messages in transactions, but the difference is how the bots listen. Instead of listening for individual transactions (which would be a huge amount of traffic) only listen when a new block is found, every 10 minutes. The block will contain the transaction.
Author here! I'm surprised to see this up on HN, I checked the front page, and here it was. This was written for a computer security class, and definitely hasn't been proofread yet. If anyone has any questions, I can answer anything you like.
I'd like to schedule a time to discuss this with you further. I've written a framework which starts virtual instances based on payments. Here's the implementation: https://www.stackmonkey.com/. A control system for the network created by the framework based on your premises might be interesting, especially if the process were tied to a pegged sidechain.
Another similar idea (from back in 2008[1]) is to use the Bittorrent DHT as distributed storage for C&C commands. I have no idea anyone has implemented a real-life bonnet in the intervening six years, but it seems plausible enough.
The use of the blockchain here appears to be based on the fact shutting down the Bitcoin network is considered to be impossible, at least for the immediate purpose of stopping the control of a botnet. I assume a Sybil attack can still occur within a peer-to-peer network that uses signed messages because of the location and addresses of the nodes can't be signed as well. i.e. the node you are talking to may be repeating previously re-transmitted signed messages, or simply not sending messages at all. It's not as if the master can sign a message vouching for the entire network's current state...
So something I've been wondering about with all the talk around The Pirate Bay recently is why aren't people using the blockchain to store data needed to bootstrap your joining of a decentralised network.
It could be as simple as storing the magnet links themselves.
On the Bitcoin blockchain, you can't fit a magnet link in the very small amount of data you're allowed to include in a transaction. You could split them across multiple transactions, but that leads into the second problem: It's not entirely clear how you'd make a directory so people could actually find these torrents.
As more general-purpose blockchains come out (Ethereum, for one example), this will get easier.
"All problems in computer science can be solved by another level of indirection"
Since you can easily fit the Magnet hash in an OP_RETURN value, all required is to move the torrent's description (title, description, categories, magnet URL) into a torrent of its own. Indexers find the first hash via the blockchain, use it to fetch the full torrent description via DHT, which in turn allows it to find the torrent via the magnet URL (or alternatively, includes the .torrent file directly, but this trades network efficiency for hosting overhead)
To speed up bootstrapping new indexers, occasionally "rollup" descriptions could be published, which are just torrents that aggregate a large number of descriptions (bucketed say, by date, DHT swarm size, or similar). Add an identifier and public key to these roll-up releases, and you effectively have a trusted "channel" - one guy or group with editorial control over the index they publish, and magically you have something very close to ThePirateBay again.
FWIW, keybase.io do the same; they store the root of the merkle tree into the blockchain with a similar principle of throwaway addresses, making it the whole database they handle basically unforkable.
Here's the doc on that: https://keybase.io/docs/server_security/merkle_root_in_bitco... . Since users on Keybase append their "announcements" (proofs, username announcement, etc.) to a public signature chain which is verifiable, the Bitcoin merkle step is designed to prove that Keybase is (a) showing everyone in the world the same thing, and (b) not omitting anything from the ends of people's chains.
The main problem I see with this is that you would have to have each client in the botnet sync with the Bitcoin network. This is a lengthy task and results in gigs of data.
An expensive, slow, and extremely CPU and network intensive protocol is not what you want to use for stealthy malware communications. It could be done; you could also hammer a nail with a trout, but you'd look pretty foolish in the process.
Yes, I agree with you on the part that it is not the most efficient network protocol, but you're overlooking the fact that blockchain is almost impossible to take down and is censorship-free. Even if they manage to locate the C&C; they simply couldn't shut it down, since BC is decentralised and a distributed database.
There's also the disadvantage of having every communication between the malware and the controller publicly logged, and the fact that that every command issued would have a small transaction free.
It's not expensive because you only need to post a message when you are changing IPs, and it will only cost a fraction of a cent. If botnets used to work with hardcoded IP addresses, it's clear that changing IP addresses does not happen very often, and usually triggered by a government action which is very expensive for the government.
It does not need to be CPU or network intensive because it can basically use a light wallet implementation.
It is not. I wrote this for a computer security class, and the paper itself was (unfortunately) last minute. I posted it to reddit last night as an afterthought, found it here in the morning. I'm sorry if it isn't up to any sort of standards, this draft was rushed, and I wasn't expecting it to get any sort of traction.
I suspect it's a student project, maybe done for a class at UCSC. The two authors worked together on another project [1], as students at UCSC, in the Spring 2013 semester.
You suspected correctly. Christopher and I wrote this for a computer security class at UCSC (taught by Ethan Miller, who I expect will at some point read this), and I posted it to reddit to see what people thought. The paper was a bit rushed, and isn't proofread at all, if I had known it would pop up on HN, I would have polished it a bit more.
Some reasons why I think this would be a good idea (as a BACKUP comms channel), though I admit I am no experts in botnets:
1) It only requires a handful of outgoing TCP connections. This is fine if you are targeting windows consumer boxes
2) It is near-impossible to take down this communications channel. If your regular C&C server gets raided/taken down then you can broadcast the new connection details using this
3) You only have to spend anything to make a new broadcast. If this were to be used as a backup C&C channel that would rarely happen, and it's fine if that were to be slow too.
4) Regarding complexity, the client will already be complex if you're going to be implementing crypto to verify commands which you should do anyway. I don't really see why complexity is a bad thing here either if it works fine.
You're right that the evidence is not really ideal, but many other comms channels used in the past have had that property, such as twitter accounts.
> There are far better ways to get this sort of reliability without shooting yourself in the foot by accepting all the handicaps I mentioned.
>Because it's too visible, hard to get out of any sort of modern corporate network
Valid point
>depends on propagation therefore extremely slow
0 confirmation transactions are instant
>public evidence of communications
Sure, but if obfuscated who's going to look? Even if encrypted with a symmetric key on the client, you'll need to reverse engineer the client. Packers and obfuscators can make your life very hard indeed. However I'm sure there's a way to did it with perfect foward secrecy (or at least an reasonable amount).
>additional constraints in the form of money spent for transactions
You don't need to pay for a c&c server any more, that's money saved.
>increased complexity on the implant and so on and so forth.
Sure
>In fact, I can't think of a single good reason why this would make a practical malware comm protocol.
How about completely anonymous, no c&c server to take down, and cannot be killed without killing Bitcoin with it?
I'm still struggling to fully understand how bitcoin works.
I guess I can understand what the blockchain is, but I struggle to understand how the number of bitcoin can be stable, and how transactions are achieved. I guess I like drawings better.
You don't need to query blockchain.info, all you need is a Bitcoin client that listens for incoming transactions.
I've been writing an implementation on and off for a while now. The general idea is as follows:
The botnet client connects to "n" Bitcoin nodes. If the same transaction is relayed by ceil(n/2) nodes, then we say that transaction is "confirmed" and examines the transaction to see if it's sent from botmaster's address (in fact we don't even have to use the botmaster's address, with BIP-0032 (https://github.com/bitcoin/bips/blob/master/bip-0032.mediawi...), we can use related public keys)
You don't even have to use transactions ("tx" messages), you can use the block messages if you are willing to tolerate an (on average) 10 minute delay, this would drastically reduce the network traffic sent/received by the botnet client.
But these guys forced my hand, so I suppose I'll have to release what I have so far. The current botcoin client (c++11 with boost::asio) connects to the network, and gets transactions. Data extraction from transactions is unfinished. The current problem I'm working on is making sure that people cannot easily scan the Blockchain to look for c&c transactions. This can easily be done by encrypting the messages with a client specific key. However, I would like to have perfect forward secrecy, that is, suppose a sample client was obtained by researchers, past c&c messages should not be able to be decrypted (otherwise the blockchain contains a log of all of your C&C messages).
[link redacted]