A Novel Approach For Computer Worm Control Using Decentralized Data Structures | Hacker News Reader

A Novel Approach For Computer Worm Control Using Decentralized Data Structures

pdf.yt

81 points666_howitzer39 comments

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).

[link redacted]

> 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.

The term is "address". There are no accounts in the Bitcoin network.

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!

(I'm one of the authors of the paper)

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:

http://staff.washington.edu/dittrich/writing.html

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).

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.

[1]: https://iseclab.org/papers/securecomm08_overbot.pdf

Can't worms simply relay to each other the message signed by the botnet master? No Sybil attack there.

The trend of throwing blockchains at problems for which they are totally uncalled for is profoundly annoying.

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...

You just timestamp the messages and give them a TTL. The worms can use ntp to sync.

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.

Ha! I just recently came across this discussion on the MaidSafe forums. There are talks of doing this to bootstrap the network: https://www.maidsafe.org/t/bootstrapping-the-safe-network-vi...

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.

Hardly inconspicuous.

But I like the idea.

You don't need the entire blockchain for this.

And new blocks are "only" ~400KB in size - at 1/10min, that's less than 700B/s. (Of course, it'll be more in practice. But still, not much.)

is this a published paper? O_o

No, it's not, and it's a pretty useless idea.

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.

On what basis are you saying this paper "isn't published"? Just curious.

"Published" papers are papers published in a scientific journal after peer review. This just appears to be an un-reviewed article.

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.

This would be the fallback com-channel, not the primary. If an ip or board gets taken down, no problem.

Yes. But many botnets nowadays do bitcoin mining, the overhead in those cases might be small.

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.

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.

[1] http://news.ucsc.edu/2013/06/entrepreneurship-showcase.html

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.

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.

really? a pdf with drop shadow on every word? if you didn't want me to read it, just say so.

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.

Reply on news.ycombinator.com