
A Novel Approach For Computer Worm Control Using Decentralized Data Structures - 666_howitzer
https://pdf.yt/d/E2ZwuLAVfC44kEQk
======
verroq
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...](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)),
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]

~~~
towelguy
> 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?

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

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

~~~
kordless
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/](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.

------
zrail
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](https://iseclab.org/papers/securecomm08_overbot.pdf)

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

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

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

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

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

~~~
_wmd
_" 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.

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

~~~
malgorithms
Here's the doc on that:
[https://keybase.io/docs/server_security/merkle_root_in_bitco...](https://keybase.io/docs/server_security/merkle_root_in_bitcoin_blockchain)
. 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.

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

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

------
kyrre
is this a published paper? O_o

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

~~~
666_howitzer
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.

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

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

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

