IN
DEGREE PROJECT
INFORMATION AND COMMUNICATION
TECHNOLOGY,
SECOND CYCLE, 30 CREDITS
,
STOCKHOLM SWEDEN 2016
Using Bitcoin for Fun and
Profit
Using Bitcoin For Fun And Profit
European Master in Distributed Computing Master Thesis
EREN YAGDIRAN
Stockholm 2016
Decleration
This thesis is an account of research undertaken between January 2016 and August 2016 at KTH, Stockholm, Sweden. I hereby certify that I have written this thesis independently and have only used the specified sources as indicated in the bibliography. Furthermore, all the implementation work has been done solely by myself.
Abstract
Botnets, in other means zombie computers that await for instructions to execute, are the greatest threat in the internet today. They are one of the leading sources of online crime. Criminals are able to take advantage of using botnets and threaten online businesses, organizations or any entity in the internet. Criminals design and implement botnets in a complex way in order to hide their identities. Most notably the fact that criminals build command-and-control (C&C) infrastructures to manage their botnets.
Table Of Contents
Decleration 1
Abstract 2
Introduction 6
Problem description . . . 7
Structure of the thesis . . . 7
Background 8 Bitcoin Overview . . . 8
Letter of Intent . . . 8
Using Serial Numbers For Unique Coins . . . 9
Making everyone collectively the bank . . . 9
Proof of Work . . . 11 Bitcoin Protocol . . . 14 OP_RETURN . . . 18 Related Work 21 Proof of Existence . . . 21 NameCoin . . . 21 DNS . . . 22 DGA . . . 23 TOR . . . 23 Methods 25 Goals . . . 25 Limitations . . . 25 Solution . . . 26 SPV clients . . . 27 Botnet operator . . . 27 Botnets . . . 28 Modules . . . 29 Ping . . . 29 Output . . . 29 Download . . . 30 Rent . . . 30 Workflow . . . 31
Experiments and Analysis 32 Botnets . . . 32
Response Time . . . 32
Bitcoin Network . . . 33
Number of Transactions . . . 34
Total Transaction Fees . . . 35
Median Confirmation Time . . . 37 Confirmation Time vs Fee . . . 38
Conclusions 40
Conclusion . . . 40 Future Work . . . 40
List of Figures
1 List of Transactions . . . 12
2 Hash Function . . . 12
3 Raw Transaction . . . 15
4 Multiple Party Transaction . . . 17
5 OP_RETURN . . . 20
6 General Architecture of Btc-botnet library . . . 27
7 Probability Distribution of Response Time . . . 33
8 Number of Transactions . . . 34
9 Total Transaction Fees . . . 35
10 Average Fee Per Day . . . 36
11 Median Confirmation Time . . . 37
12 Number Of Transactions By Fees . . . 38
Chapter 1
Introduction
It’s been eight years since famous “pandemic” botnet released into the wild and since then threads caused by botnets heat up [1]. Today, large botnets can get hold of millions of computers as infected machines. These machines which are also called as zombies or bots, can be used for illegal activities such as spam, information theft, ddos attacks, etc [2,27,30]. FBI lately approximated that 500 million computers are becoming a part of a botnet every year [3] which is causing $110 billion loss for global economy [5]. Botnet can not only infect computers but also any device that can connect to internet such as mobile devices, security cameras, etc [4]. Moreover, it is reported that botnets can also be used for mining cryptocurrencies.
One of the flaws for designing a C&C infrastructure is that centralized archi-tecture for internal communication among botnets. In this scenario, botnets connect to a centralized point such as botmaster to receive commands for process-ing. Authorities or any third parties can reverse engineer a botnet and extract relevant information about C&C network [6,7]. By this way, botmaster can be traced back to his original location or C&C network can be disrupted. The vast majority of operations against C&C networks have been done by using exploits or disrupting botmaster.
In this thesis, we discuss that Bitcoin can be used as an alternative way for building a C&C infrastructure [25]. Bitcoin provides great advantages over existing C&C mechanisms such as HTTP meeting points [8], DNS [9], TOR [10] or DGA [11]. By pushing botnet communications into the Bitcoin network, botmaster can drastically reduce the cost of setting up a C&C network from scratch. Secondly, botmaster can push botnet commands into Bitcoin network without revealing his identity. Therefore, it becomes harder to track botmaster. This anonymity can be enhanced through using VPN services or Tor network. Moreover, Bitcoin, by its nature, provides a consistent global state. Hence, botnets that connect to Bitcoin network from different nodes, will eventually reach the same state. This revokes the need for bot-to-bot communications. In addition, elimination of a bot does not reveal information about other bots in the C&C network. So, size of the botnet in terms of number cannot be estimated easily. Lastly, Bitcoin [12] is built upon an independent ideology so that it is against regulation. C&C communications over Bitcoin network cannot be erased or removed without disrupting legitimate Bitcoin users. External interferences which aim to regulate Bitcoin may be end of it [28].
1. We present btc-botnet, a mechanism for botmasters to manage their botnets by using Bitcoin.
2. We design and implement btc-botnet in a modular fashion so that functionality of botnets can be extended.
3. We develop and deploy btc-botnet in various locations and send C&C commands to bots over Bitcoin network. Our results show that C&C commands can be propagated in a 8-60 second window.
Problem description
The command and control infrastructure for botnets is a weak link as most of the architectures share a concept of centrality. Botnet operators can lose their botnets if the link is broken or their master servers are seized by any 3rd party organization. Furthermore, communication between botnet operator and botnets can be analyzed and reverse engineered with an ambitious effort so that botnets can be taken over. In order to regain access to botnets, botnet operator needs to broadcast an update including his new location. In most cases, this is impossible and ends up with losing all botnets.
This thesis introduces a novel approach, btc-botnet, for establishing command and control infrastructure by using Bitcoin. Btc-botnet revokes the need for a central point for communication between botnet operator and botnets and also offers an anonymous and indestructible way for command and control infrastructure.
Structure of the thesis
Chapter 2
Background
Specific knowledge about Bitcoin, as well as concepts behind the Bitcoin such as preventing double spending [17], transaction types and proof of work, is necessary for the reader to understand this thesis. The following subsections give a definition of the term Bitcoin and describe its core concepts. Afterwards, a short overview of Bitcoin protocol is given. Finally, OP_Return values are described in Bitcoin protocol and explained its importance for this thesis.
Bitcoin Overview
Bitcoin has been a popular topic since the first paper was published on the topic in 2010 [19]. It is an online and peer-to-peer currency used for exchanging monetary equivalents between peers without any central authority. In this overview, the core ideas behind Bitcoin will be described and analyzed for the reader in a clear way. There will be some principles and theoretical approaches for building the protocol from scratch, as well as plain texts that describe the protocol itself.
The Bitcoin protocol is very detailed and difficult to understand. To grasp the fundamentals of Bitcoin, one must be familiar with public key cryptography, digital signatures and hashing.
At its core, the Bitcoin protocol relies on cryptography. Since Bitcoin consists of peers, transactions and a secure network, cryptography is needed to secure these values. As of now, people who live in the world use banks, locks, and other types of mechanisms that let them feel that they are the owner of a property. Cryptography in Bitcoin enables this relationship between peers and transactions [13].
This overview part will describe Bitcoin on several levels. Each of these levels introduces a core concept behind Bitcoin. When each of the layers is combined, one can more fully understand Bitcoin protocol.
Letter of Intent
security for those bits. Even if everyone in the Bitcoin network has unique bits to identify ownership for their coins, there needs to be a mechanism to provide security for each peer in the network. Otherwise, peers in the network can steal bits from each other.
To overcome these two problems, cryptographic keys are introduced. Each peer in the network has a private key and a public key. When a peer wants to send money to another peer, a message that describes the transaction between the peers needs to be prepared. The sender peer has to sign that message with his private key and broadcast it to the Bitcoin network.
Any peer in the network can verify the signed message by using the public key of the sender peer. This leads to a confirmation that the signed message belongs to the sender peer. The signed message is unique throughout the network. If the confirmation is satisfied, no questions can be raised in this context. The sender peer can’t claim the opposite after the message is signed and broadcasted. This establishes the relationship between peers in the Bitcoin protocol.
Limited forgery can still be done in the context of a Letter of Intent. The sender peer can sign and broadcast the same bits over and over again, which will lead to an infinite money supply.
Using Serial Numbers For Unique Coins
The problem with a Letter of Intent is that the sender peer can sign and announce the same bits over and over, so the receiver peer can get multiple copies of the signed message. It is not clear whether a sender peer has announced the same message multiple times or if the signed message has been accidentally duplicated more than once. Therefore, there is a need to identify each Bitcoin. Transactions between peers in the network need a label or a serial number for each Bitcoin that is about to be transferred. Therefore, the receiver or any peer in the network can differentiate Bitcoins by using their serial number. A simple approach to solve this problem is to introduce a central authority for issuing serial numbers for each Bitcoin. This central authority can also track the ownership of Bitcoins. It can also be used for the verification of transactions between peers.
In this scenario, a sender peer can request transaction information from the central authority and then prepare his message. After the request is complete, the central authority is responsible for further steps to complete the transaction. Thus, the central authority can detect fraudulent transactions and ensure that every transaction is legitimate and secured.
Making everyone collectively the bank
authority entirely from its work flow. This is very different from the currency in common use today. More importantly, there is not a central authority that is responsible for the integrity of the transactions.
The major principle behind this decentralization [18] is that of making every peer in the network a bank. In other words, every single peer in the Bitcoin network is responsible for keeping a complete record of transactions that have been conducted between peers [16]. This can be outlined as a shared list replicated over all peers in the network [14]. In Bitcoin terminology, this is called a “Bitcoin Blockchain”.
In the blockchain scenario, a sender peer prepares a message for a transaction. He signs the message and broadcasts it to the network. A receiver peer receives the signed message and verifies the transaction with the sender’s public key and broadcasts another message for his acceptance. Other peers in the network can see this stack of messages and update their blockchain copy accordingly. A major drawback of this design is that it allows a sender to spend his coins more than once. A sender peer prepares a message to receiver peer 1 and broadcasts it. Later on, he can prepare another message to receiver peer 2 using the same Bitcoins. In this case, half of the network can update their blockchain copy by trusting receiver peer 1 and the other half can do the same by trusting receiver peer 2. This would compromise the integrity and allow Bitcoins to be spent more than once.
A simple solution for double spending is that, after the sender broadcasts his message for a transaction, he can wait a short period of time for the transaction that is about to spread.
Once every peer in the network confirms the validity of the transaction, receiver 2 or other receiver peers can be confident about their blockchain copy. This leads to a short period of time in which a sender can take advantage. However, even if the waiting time for each transaction appears quite short at first glance, this strategy is not scalable. For example, when millions of peers want to make a transaction, waiting times would increase exponentially. Another case is that a sender can also disrupt the communication channel between receiver 1 and receiver 2 peers. By slowing down any of the receiver peers, the sender can have more time to spread his fraudulent transaction.
blockchain copy. If they reach a consensus about the transaction’s validity, they will all insert that transaction into their blockchain copy.
One major question can be raised after introducing a consensus approach for the validation of transactions: Since the design depends on consensus, how can a sender peer be sure that a high enough number of peers are involved in confirming transactions? It’s obvious that an appropriate number of peers can’t be all the peers in the network, nor can it be represented by only a small fraction of the network.
Proof of Work
When a sender intends to spend his money more than once, he can do this by taking over the network. He can spawn an arbitrary number of malicious peers to create his own consensus. Therefore, third-party peers who are helping validate transactions can take malicious actions against receiver peers. After validating the transactions, each peer may feel that they received the Bitcoins from the sender in a legitimate way.
To avoid this problem, there is a concept called “proof of work.” The idea consists of two major concepts. The first is that validating transactions should be computationally costly for network peers [15]. Therefore, spawning an arbitrary number of peers for malicious purposes turns out to be very expensive in terms of operational costs. The second idea is rewarding other peers for their contribution in the network. Since validating transactions is a computationally expensive operation, the peers who are responsible for validating transactions need to cover their expenses and make a little profit on top. The advantage of making it computationally expensive is that the validation process cannot be disrupted by the number of malicious peers.
Peers in the network have a special queue for transactions that need to be validated. A sender broadcasts his signed message, and other peers push that transaction into the queue. Other peers need to do a sanity check operation. After the sanity check, other peers have to start the proof-of-work process. Since each peer in the network has a different queue, they have to solve a different puzzle for broadcasting the validity of those transactions. Without a solution to that puzzle, other peers in the network will not add those transactions into their blockchain.
L = { “Sender->Receiver,150”, “Sender->Receiver,250”, “Sender->Receiver,350”, “Sender->Receiver,450”, };
Figure 1: L as List of Transactions
H(L,X) = e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8 Figure 2: List and Nonce passing through a hash function
Each peer who wants to contribute to the network has to pass a special string to the globally-known hash function (H). The result of the hash operation clarifies the difficulty level of the puzzle. Bitcoin is currently using the number of zero characters at the start of a hash operation as a difficulty level. More zeroes at the start of a hash output means a harder puzzle that needs to be solved. Globally-known hash function is the key factor in making puzzles difficult to solve. Since each peer needs to find a proper nonce number in order to find a hash output that starts with zeroes, any modification that is applied on the nonce number will change the hash output completely from the previous one. Hence, finding a proper nonce number is a challenging problem that is difficult to solve.
The mining process or proof-of-work concept depends on computational power. The amount of computational power is roughly related to the mining peer’s chance of successfully solving a computing puzzle. When a mining peer offers more computational power, he is more likely to win the competition among the peers. Therefore, the key factor for winning the competition relies on the computational power that one or more peers can bring to the network. Under normal circumstances, a malicious peer can manipulate only a small fraction of the network.
A Bitcoin blockchain consists of separated blocks. Each block in the chain contains transactions between peers. Since the order between transactions is needed for integrity, each block in the blockchain has a point from the previous block to which it is connected. Without this ordering, it is impossible to track who owns Bitcoins at any given time. After all, the blockchain is a linear list of blocks that contains transactions that have been completed among peers. One of the drawbacks of this design is when two or more peers validate the proof of work at the same time. One half of the network can update their blockchain according to the first peer, while the other half can update their blockchain according to the second peer.
enough confirmations from the fork of the victim peer, the malicious peer can start his process to speed up solving the puzzles. If the malicious peer can build up solved blocks faster than the overall network, his fork will be longer than the fork of the victim peer. Eventually, all the other peers in the network will switch to the fraudulent fork. This case only makes sense when the malicious peer has more computational power than other peers in the network.
Bitcoin Protocol
Figure 3 illustrates the raw data for transactions in the network. It is a deserial-ized version of a transaction and the line numbers are added for ease of reference. Lastly, hashes and public keys are truncated from the sixth character due to long letters.
Line 2 represents the hash of the transaction. It is a unique identifier for all transactions.
Line 3 shows that this transaction is Version 1 in the Bitcoin protocol. Lines 4-5 tell that the transaction has one input and one output.
Line 6 specifies the value for “lock_time”. Generally, the lock_time property is set to 0. It means that the transaction needs to take place immediately. Line 7 contains the value for the size of the transaction.
Lines 8-20 describe the input value for the transaction. In Line 30, the prev_out property of a transaction points to the previous transaction that the value will be taken from. In Line 18, the script_property is the signature of the sending peer in the network. The number of the input and output fields solves the problem of changing money. If a sender peer wants to send one Bitcoin from his two Bitcoins, the sender peer needs to craft the transaction in a way that the input field should contain two Bitcoins and the output field needs to be filled by his address again by one Bitcoin. This is the mechanism for providing a change in the Bitcoin network.
Line 25 shows the output of the transaction. The value property of the output transaction specifies the amount of Bitcoin that needs to be sent.
Line 33 is a Bitcoin script language. The field contains a lot of information, such as the recipient address and/or other fields that can be used in the Bitcoin protocol.
1{ 2 "hash":"7c402505be883276b833d57168a048cfdf306a926484c0b58930f53d89d036f9", 3 "ver":1, 4 "vin_sz":1, 5 "vout_sz":1, 6 "lock_time":0, 7 "size":224, 8 "inputs":[ 9 { 10 "sequence":4294967295, 11 "prev_out":{ 12 "spent":true, 13 "tx_index":31421380, 14 "type":0, 15 "addr":"1AnLpMkAmf7jy2BNkP3oYw1phzhNuLws7M", 16 "value":32000000, 17 "n":0, 18 "script":"76a9146b4c646f6c129ad4f2436b05b5b6e1bdc248134688ac" 19 }, 20 "script":"483045..." 21 } 22 ], 23 "block_height":250399, 24 "relayed_by":"70.69.229.109", 25 "out":[ 26 { 27 "spent":true, 28 "tx_index":31422075, 29 "type":0, 30 "addr":"1GJYiog3ato17SSTFCCdkZ44H6LdkW9j1V", 31 "value":31900000, 32 "n":0, 33 "script":"76a914a7db6ff121871c65a8924b8e40f160d385515ad788ac" 34 } 35 ], 36 "size":224, 37 "double_spend":false, 38 "time":1375728314, 39 "tx_index":31422075 40}
Line 2 shows the hash of the transaction.
Line 3 tells the version information of the Bitcoin protocol.
Lines 4-5 imply that the transaction has three inputs and three outputs. Line 6 contains the value for the size of the transaction.
Lines 7-19 represent the input fields of the transaction. Each of the input fields maps to a different output field from a previous transaction.
Line 11 reveals the sender’s Bitcoin address and also script property in Line 18 contains the public key for the sender and additional flags for the Bitcoin protocol.
Lines 22-34 and 35-47 correspond to the second and third inputs, respectively. Lines 51-65 define two output addresses for the transaction.
The difference between input fields and output fields is that output fields contain a Bitcoin address for the recipient peer. In the Bitcoin protocol, in terms of a valid transaction, the sum of values in the input fields must be greater than or equal to the sum of the output fields. (Genesis blocks and coinbase transactions are exceptions to this case). Therefore, the sender peer can’t send any money that he doesn’t have. When the input values are greater than the output values in a transaction, the difference between the sum of the input values and the sum of the output values is paid as a fee to the winning peer of the proof-of-work puzzle. As an illustration of using multiple transactions in Bitcoin can be the principle of making change. When a sender peer wants to send a small fraction of his money to another peer, the output field in the transaction can be used as the amount (like giving change in traditional currency) that will be sent back to the sender peer.
OP_RETURN
The following figure illustrates a raw transaction that includes the OP_RETURN field in its out property.
1{ 2"hex" : "...", 3"txid" : "...", 4"version" : 1, 5"locktime" : 0, 6"vin" :... 7"vout" : [ 8 { 9 "value" : 0.00000000, 10 "n" : 0, 11 "scriptPubKey" : { 12 "asm" : "OP_RETURN", 13 "hex" : "6a1368657967757973656d6463726f636b73212121", 14 "type" : "nulldata" 15 } 16 }, 17 { 18 "value" : 0.00200000, 19 "n" : 1, 20 "scriptPubKey" : {
21 "asm" : "OP_DUP OP_HASH160 b8268ce4d481413c4e848ff353cd16104291c45b OP_EQUALVERIFY OP_CHECKSIG", 22 "hex" : "76a914b8268ce4d481413c4e848ff353cd16104291c45b88ac", 23 "reqSigs" : 1, 24 "type" : "pubkeyhash", 25 "addresses" : [ 26 "1HnhWpkMHMjgt167kvgcPyurMmsCQ2WPgg" 27 ] 28 } 29 } 30], 31"blockhash" : "000000000000000004c31376d7619bf0f0d65af6fb028d3b4a410ea39d22554c", 32"confirmations" : 2655, 33"time" : 1404107109, 34"blocktime" : 1404107109
Chapter 3
Related Work
Proof of Existence
Proof of Existence is a third-party service that uses a Bitcoin blockchain in order to anonymously and securely store online distributed proof of existence for any document. The service stores a data bundle about a document that needs to be stored. This data bundle includes a cryptographic hash of the document and the time of the submission. Therefore, it can be certified that the document actually existed at that time. The service is designed to allow anyone to publicly prove that a document exists without revealing the document or the owner of the document.
The key advantages of using this service are anonymity, privacy and a decentral-ized proof that can’t be removed or altered by third parties. The existence of the document is inserted into the Bitcoin blockchain. Therefore, it eliminates the need for centralized authority.
NameCoin
NameCoin is another cryptocurrency that is based on Bitcoin [21]. It is a fork of Bitcoin that has its own blockchain. NameCoin has many similarities to Bitcoin, such as the same mechanism for proof of work, coin cap, and the creation time for blocks. NameCoin is designed to replace DNS. The motivation for designing NameCoin is that central authorities, such as ICAAN, require too much trust and centrality in order to manage the domain-naming system. In some cases, the nature of central authorities can lead to a single point of failure.
There are many subspaces in NameCoin and each subspace corresponds to an application. The most popular subspace is “/d”, or in other words, “.bit” domains. The “/d” subspace is designed for DNS lookup. If a peer in the network wants to register an “example.bit” domain, the peer has to claim ownership for the “/dexample” key in the blockchain. The owner of the “/dexample” key must set its value in such a way that “.bit” compatible DNS servers can actually understand its rituals and return correspondent value to their clients.
There are number of ways to resolve “.bit” domains. The most popular way of using “.bit” domains is to use a local DNS provider, such as NM_Control, FreeSpeechMe and DNSChain. As opposed to these solutions, less secure options can also be used. OpenNic is an external DNS solution that provides “.bit” domain resolution. Since using an external DNS solution might not be trustworthy, users can also use a third-party proxy service, which also provides ease of configuration for connecting “bit” domains.
As of 2016, NameCoin has one-third the hash power of the Bitcoin blockchain. This makes it easier to perform a 51% attack on NameCoin. If a single entity or group of peers in the NameCoin network can control 51% of the hash power in general, they can manipulate the blockchain at their will. What makes this attack interesting is that it is theoretically possible. The NameCoin network is free and open to peers who would like to participate. Therefore, since there is no central authority to stop a group of peers with malicious intentions, an entity that has enough power to compensate the rest of the peers in the network can alter or even rewrite the blockchain from scratch.
DNS
routed to the nearest mirrored one transparently. Root servers are responsible for keeping records for each domain. If they can’t find a record for a requested domain name, they are also able to route the request to a proper root server. Therefore, the time needed for resolving a domain can vary unexpectedly. Even though DNS is coined as a distributed and fault-tolerant system, root servers can be a single point of failure [32]. Since each organization in ICANN is responsible for a root server, organizations are bound by the law in the country where they reside. If one takes into consideration that each country has a different system of laws, this reveals an ambiguity for organizations. Furthermore, governments or other responsible third parties can take advantage of the organizations and demand inconvenient actions for managing root servers. Eventually, those can result in severe drawbacks for anonymity and privacy [33].
DGA
Domain generation algorithms were invented to keep users connected, even though a problem exists in the root servers [35]. For example, if users would like to connect “abc.com” and the record for that domain is blocked in the root servers, they can’t reach their destination. Users have to reach the organization of “abc.com” in some other way and update the address in their client software. DGAs are an innovation for solving this problem. In this context, users don’t need to have any knowledge about the organization in advance. Users have to present the same algorithm for domain generation and the same seed number that triggers the algorithm from the same point for all users. Therefore, with the help of the seed number, all users are able to generate the same domain name and use it in their request.
DGAs can be used for sensitive communications over the Internet [24]. The-oretically, by using DGAs, it is impossible to stop clients from reaching their destination. When the destination address becomes unavailable, a client gen-erates a new address from the algorithm and uses it for the next destination. A botnet called “Conficker-C” used this technique to hide traces behind it. It generated 50,000 domain names that are distributed over the main root servers. Registering one of those randomly generated domain names in root servers is enough for the botnet to communicate and receive commands [29,34].
However, DGA algorithms can be reverse-engineered. Security researchers managed to take over a botnet network by analyzing its DGA. They managed to spot possible domain names for the next phase of its algorithm.
TOR
Internet, where connections between users are established directly, the Tor network builds its own connections on virtual links. Therefore, users in the Tor network can share information without revealing their identity. Tor is an effective tool against censorship that allows users to reach forbidden destinations and content. Not only users, but also developers, can take advantage of the Tor network. Developers can include Tor networks into their applications, rather than implementing their own custom solution to provide secure and anonymous communication.
Chapter 4
Methods
The goal of this thesis is to use Bitcoin blockchain as an underlying infrastructure for managing and control botnets. Therefore, botnets can be operated in an anonymous way. The hypothesis is that this can be achieved by using OP_RETURN values in Bitcoin transactions. It is assumed that this will provide an anonymity for botnet infrastructure and drastically reduce the chance of being blocked by central authorities. This will bring an innovative way for botnet operators to manage their botnets by assuming that Bitcoin blockchain cannot be disrupted by 3rd parties.
In order to validate the main part of the hypothesis, the need for developing a third party library is revealed. First, a library called btc-botnet is introduced. Testing and developing processes of the library are done under feature driven methodology. This methodology provides a smooth approach for developing each feature that takes place during transactions in the library. Therefore, it becomes easy to test and validate against the goals of this thesis.
Goals
The goals of this thesis are defined as follows.
• To find the possibility of using Bitcoin blockchain as underlying infrastructure for managing and to control botnets.
• To provide a transparent key solution as a 3rd party library for communication between botnet operator and botnets
• To offer an easy way for botnet operators to define custom instructions for his botnets
• To enable botnet operator to rent his botnets for a certain amount of time in contract with a tenant
• To understand feasibility of using Bitcoin blockchain as a com-mand and control mechanism for botnets in terms of response time, cost and confirmation time
Limitations
addition to that, existing libraries will be used for communication with Bitcoin blockchain.
Solution
To accomplish previously defined goals, an external library called btc-botnet, is developed in python language. This library is mainly responsible for interacting with the blockchain in Bitcoin and can also be integrated into any python appli-cation that wants to take advantage of using the blockchain as an infrastructure for storing arbitrary key/value pairs. Since it is our main priority to use external libraries as much as possible rather than implementing our own, python-pyspv library is used for parsing the blockchain of Bitcoin. This library can successfully parse and return necessary information from the blockchain. Bitcoin clients are separated into two major categories such as SPV clients and full clients. The difference between each client is that SPV clients don’t need to download all the blockchain with its transactions but only block headers. After synchronization process with the blockchain is done, SPV client overhead is observed that it requires around 10 megabytes in terms of storage. As opposed to this, full clients need to replicate all the blockchain along with its transactions. As of August 2016, it requires 70 gigabytes in storage. This huge distinction between the clients make SPV client favourable for this thesis. Therefore, the library that is implemented in this thesis, uses SPV clients in order to reduce space requirements.
Module based design approach is taken due to the fact that botnet operators might have different needs from their botnets such as capturing screenshot, ping, ddos, etc. Each module is defined in btc-botnet library with a specific id. Hence, each module can be identified and instead of sending whole module with its metadata to the transaction, using only module ids will be enough for consistent communication between botnet operators and botnets. In addition to unique id approach, each module needs to implement a certain interface. Therefore, each module can be classified and executed in the same manner. Another approach of using module based architecture is that lets other botnet operators to define their own modules. So, they can customize operations of botnets in respect to their needs.
Figure 6: General Architecture of Btc-botnet library
SPV clients
SPV is an abbreviation for Simplified Payment Verification. There is a possibility in Bitcoin protocol that client might not be involved in verification process of transactions. SPV clients might connect to trusted peers or strongly believes that verifying transactions by checking only block headers is enough.
SPV clients as described in Bitcoin paper, connect to a set of peers in Bitcoin network and download only block headers. They verify each block by chaining together. Since each block has a field pointing to previous block, constructing the chain from arbitrary number of blocks is a sufficient level of trust. After synchronization process, SPV clients create a filter that contains bitcoin addresses in order to refine related transactions from the blockchain.
Furthermore, the library python-pyspv that is being used in this thesis, offers an advanced optimization. It basically discards old enough blocks without calculating again. This reduces initial synchronization time for botnets.
Botnet operator
is nothing but simply converting string representation of command payload into hex one. Therefore, the data that needs to put nearby OP_RETURN is 3c313e3a3c353e3a3c7777772e676f6f676c652e636f6d3e.
After the payload is generated, botnet operator needs to sign the transaction with his public key and then it becomes ready to be sent. This whole process is done in SPV client. SPV client sends this transaction to one of its nodes that it trusts and waits for confirmations to show them botnet operator later on.
Botnets
Modules
Modules are essential part of creating a custom command. Each module needs to implement a certain type of an interface called module interface. This module interface forces each module implementation to contain set of methods. Therefore, each custom module can executed in the same manner. Each module has a unique id in order to differentiate each other. Id uniqueness also provides an alternative way to load modules into memory. This way provides that different modules can only be loaded once.
Ping
Ping module allows botnets to check that destination address is available to reach. This module is implemented by using an external x86 binary called “ping”. Most of the linux distributions has this library installed. Therefore, implementation of this module only includes an executing external library and saves the output of the operation.
Ping module executes an external library called ping and the binary start to send ICMP request to a destination server. Destination server replies back with ICMP Echo reply. Therefore, availability of destination server can be deduced. The binary can also reports errors, packet loss and also a summary that includes statistics about the request.
In order to use ping module, botnet operator needs to pass command id as 1. Other parameters are number of the ping request and hostname of the destination. After these parameters are set, module spawns another process, executes ping binary with provided parameters and listens for the output to send it to botnet operator.
Output
Output module is designed to collect the outputs of other module operations. Before using output module, botnet operator needs to setup a service that listens a certain port. Botnet operator combines command id with address of the service and its port number and puts this data into OP_RETURN value of the transaction. Botnets read the transaction and parse it. After parsing operation, botnet can use a service ip and a port number as an output destination. Since the module interface defines a generic method for sending output to a remote address and this generic method is called every after a module is executed, output module can update service ip and port number in a way that botnet operator can receive outputs successfully.
prefix calculated through a set of operations. First, it is using python’s platform module to list system information and combines that to generate a hash that is unique for each botnet in the network. Afterwards, this hash code, can be used an unique identifier as a prefix value to send outputs of executed modules. Therefore, since each botnet has a different prefix value, receiving server for the outputs of executed modules can differentiate or group the entries by reading that prefix value.
Download
Download module is a way to update botnets’ modules. Botnet operator needs to setup a service that is in charge of serving module content. By using download module, botnets can download and install new modules and execute them if they receive another command associated with newly installed module. Botnet operator has to spawn a service to distribute the contents of a module. For each connection of the service, the service needs to read contents of the module and send it over those connections and close them afterwards.
The default behaviour is to overwrite when botnets are instructed to download and install a module that already exists. Therefore, all modules even including download module can updated via download module.
Rent
Rent module allows botnet operator to rent entire botnet infrastructure to a temporary owner ,tenant, for a certain amount of time. Botnet operator is responsible for charging tenant for botnet service. Botnet operator needs to ask tenant’s bitcoin address in order to give him the control of botnets. When botnets receive an instruction for a rent command, they change the filtering address to Bitcoin address of tenant and also set a timer for switching back to botnet operator’s address. Eventually, botnets will filter tenant’s directives for a certain amount of time that is specified within a parameter in rent module. Tenant can also initiate his own transactions to control botnets. After time is up for the tenant, botnets will change its filtering address to botnet operator’s one. Hence, botnet operator can broadcast new commands or rent again to another tenant.
Workflow
Botnet operator needs to generate key pairs for using Bitcoin. These are public key (pk) and private key (sk). Botnet operator needs also a Bitcoin address that is generated through hash of his public key. In order to manage the botnets, Bitcoin address of the botnet operator needs to be embedded into botnets. Therefore, when botnets connect to the blockchain, they can filter transactions which include Bitcoin address of botnet operator. After filtering operation is completed, botnets can start to parse the transactions in order to decode commands sending from botnet operator.
Chapter 5
Experiments and Analysis
This section evaluates btc-botnet library by conducting experiments through the blockchain of Bitcoin. The experiments which were related to the communication between botnet operator and botnets were done by using DigitalOcean as a cloud provider. The instances that were used throughout the experiments had typically 2gb of ram, 1 core processor, 20gb of storage and 1tb of network traffic. To build a distributed architecture, 4000 botnet instances were deployed in multiple locations in the Europe, East Asia, United States. One instance as botnet operator was deployed in our school lab.
To analyse Bitcoin transactions in terms of its feasibility, another server is used with following configurations: AMD Opteron 2435 processors with 2 cores at 2.4GHz, 16GB of RAM and Python 3.2 installed on the 64-bit version of Ubuntu 11.04.
Botnets
Response Time
In order to observe the communication between botnet operator and botnets, we had to set up prerequisites for the experiment.
Firstly, a new key pair and hence a new Bitcoin address for botnet operator were generated. We transferred enough Bitcoins to that account. Bitcoin address of botnet operator was hard coded into botnets’ source code.
Secondly, we used Docker as a packaging and configuration tool to distribute the botnet. Docker images are guaranteed to run in any infrastructure where Docker host is installed. Therefore, we generated a Docker image to release our botnet application. In the Docker image, we added necessary dependencies to our botnet release. We used Docker-machine as a cluster management tool for our botnet infrastructure. Hence, we managed to deploy the Docker image to our remote locations by using Docker-machine.
In addition, we used a separate server to set up a full Bitcoin node and used that server as a operational base for botnet operator. We transferred pre generated key pairs to this machine in order to sign and send Bitcoin transactions. In this phase, we also developed a small python script that was responsible for crafting the transaction that contained encoded commands.
tcp server which listened to a certain port number. We encoded the output module, the server ip number and the port number into our first transaction and send that transaction through the full Bitcoin node. Later, we waited enough time for propagation of that transaction. Since we knew the number of botnets deployed in the wild, we counted each connection that was established through our endpoint of the output module in order to measure success rate of the module propagation.
Lastly, after hellomodule was successfully installed to the botnets, we initiated another transaction to run hellomodule in botnets. When we received only one confirmation about the transaction, we set a timer to calculate response time of each botnet. Botnets received the command for executing hellomodule and after that each response time from botnets were noted down.
Figure 7: Probability distribution of response time
Figure 7 shows that probability distribution of time that is taken during response time. %60 of botnets responded in 20 seconds and %95 of them in 40 seconds. Median response time was around 18 seconds.
Bitcoin Network
API. Since transactions are bundled with a block associated with them, our focus was to observe the blocks that contain transactions that were broadcasted through the full node.
To analyze how the transactions behave in Bitcoin network, we recorded all the blocks and associated transactions with in 60 days time slice. We analyzed number of transactions, total transaction fees, average fee per day and median confirmation time in order to reveal a relation between them.
Number of Transactions
Figure 8: Number of Transactions
Total Transaction Fees
Figure 9: Total transaction fees
Average Fee Per Day
To get average fee that is being spent on Bitcoin network per day basis, we used blockchain.info ‘s API. Therefore, without going through each transaction in the network, we managed to get average fee per day of the general network.
Figure 10: Average Fee Per Day
Median Confirmation Time
For each block, we wrote a custom query to find its initial announce time and time for its first confirmation by using the blockchain.info’s API. Therefore we managed to analyze the blocks in daily basis with the time was taken for the confirmation.
For each day, we categorized the blocks and took a median of confirmation time of all blocks that were done during that day.
Figure 11: Median confirmation time
Figure 11 shows median confirmation time in minutes of each block for 60 days time range.
Confirmation Time vs Fee
We set up another experiment to investigate transaction fees and confirmation time. In this experiment, we recorded all the transactions for 3 hours only. For all transactions, we categorized them by their fees. The unit of fees that we have measured is Satoshi which is equivalent to 0.00000001 Bitcoin.
Figure 12: Number of transactions by their fees
Fee in Satoshi Earliest Block Latest Block Earliest Time Latest Time
0.0 9 Infinite 70 Infinite 0.0 - 0.1 1 6 0 100 0.1 - 0.2 1 5 0 80 0.2 - 0.3 1 4 0 70 0.3 - 0.4 0 2 0 55 0.4 - 0.5 0 2 0 45 0.5 - 0.6 0 0 0 30 0.6 - 0.7 0 0 0 30 0.7 - 0.8 0 0 0 30 0.8 - 0.9 0 0 0 30 0.9 - 1.0 0 0 0 30 1.0 - 1.1 0 0 0 30 1.1 - 1.2 0 0 0 30 1.2 - 1.3 0 0 0 30 1.3+ 0 0 0 30
Table 1 shows the relation between fees and confirmation time. For example, transactions with 0 Satoshi fee may show up in the blockchain after 9 blocks at earliest or they may not be seen ever. If they show up, it will happen 70 minutes later at earliest.
Chapter 6
Conclusions
This chapter indicates the outcomes that were achieved during our work in this thesis. It concludes and evaluates our research goals. Lastly, suggestions for future work are given.
Conclusion
This thesis brings an alternative solution for building a C&C mechanism with anonymity for managing botnets. It is done by using Bitcoin blockchain as an underlying infrastructure. By pushing crafted transactions which include commands for botnets, we could manage to control arbitrary number of botnets which are distributed around the world. We also designed a module scheme to extend botnets’ functionality and offered a new way to monetize botnets securely through a custom rent module. Moreover, we came up with a library that offers these features for ease of development.
We were able to control botnets with the time frame of 20 seconds and 60 seconds.
The experiments that we conducted in Bitcoin network showed that a transaction not enough fee might not be propagated to entire network at all. To set a proper fee for a transaction requires an extensive analysis of various parameters.
Future Work
Bibliography
1. J. Leyden. Criminals ’may overwhelm the web’. The Register, Jan. 26 2007. http://www.theregister.co.uk/2007/01/26/botnet_threat/ [accessed 30-July-2016].
2. P. Amini. Kraken Botnet Infiltration. http://dvlabs.tippingpoint.com/blog/ 2008/04/28/kraken-botnet-infiltration, 2008.
3. D. Moore, G. Voelker, and S. Savage. Inferring Internet Denial of Service Activity. In Usenix Security Symposium, 2001. 4. D. Dagon, G. Gu, C. Lee, and W. Lee. A Taxonomy of Botnet
Structures. In Annual Computer Security Applications Confer-ence (ACSAC), 2007.
5. Finjan. How a cybergang operates a network of 1.9 mil-lion infected computers. http://www.finjan.com/ MCR-Cblog.aspx?EntryId=2237, 2009.
6. P. Barford and V. Yegneswaran. An inside look at botnets. In In Series: Advances in Information Security. Springer Verlag, 2006.
7. E. Cooke and F. Jahanian. The zombie roundup: Understand-ing, detectUnderstand-ing, and disrupting botnets. In Steps to Reducing Unwanted Traffic on the Internet Workshop (SRUTI ’05), 2005. 8. P. Porras, H. Saidi, and V. Yegneswaran. An Analysis of Con-ficker’s Logic and Rendezvous. http://mtc.sri.com/Conficker/, 2009
9. L. Bilge, E. Kirda, C. Kruegel, and M. Balduzzi. Exposure: Find-ing malicious domains usFind-ing passive dns analysis. In ProceedFind-ings of NDSS, 2011
10. D. Brown, Resilient Botnet Command and Control with Tor, http://www.defcon.org/images/defcon-18/dc- 18-presentations/D.Brown/DEFCON-18-Brown-TorCnC.pdf, DefCon 18, 2010
11. S. Yadav, A. Reddy, A. Reddy, and S. Ranja. Detecting al-gorithmically generated malicious domain names. In Proc. of the 10th ACM SIGCOMM Conference on Internet Measurement (IMC’10), Melbourne, Australia, pages 48–61. ACM, November
2010
13. T. Bamert, C. Decker, L. Elsen, R. Wattenhofer, and S. Welten. Have a snack, pay with Bitcoins. In IEEE P2P, 2013.
14. C. Decker and R. Wattenhofer. Information propagation in the bitcoin network. In IEEE P2P, 2013.
15. J. Garay, A. Kiayias, and N. Leonardos. The Bitcoin Backbone Protocol: Analysis and Applications. Cryptology ePrint Archive, Report 2014/765, 2014
16. J. A. D. Donet, C. Perez-Sola, and J. Herrera-Joancomartı. The ´ Bitcoin P2P network. In Workshop on Bitcoin Research, Jan. 2014
17. G. O. Karame, E. Androulaki, and S. Capkun. Double-spending fast payments in Bitcoin. In ACM CCS, 2012
18. A. Gervais, G. O. Karame, V. Capkun, and S. Capkun. Is bitcoin a decentralized currency? IEEE Security & Privacy, 12(3):54–60, 2014.
19. R. Grinberg. Bitcoin: An Innovative Alternative Digital Cur-rency, November 2011.
20. I. Bentov and R. Kumaresan. How to Use Bitcoin to Design Fair Protocols. In CRYPTO, 2014.
21. A. Loibl. Namecoin. namecoin.info, 2014.
22. Dingledine, R., Mathewson, N., Syverson, P.: Tor: The second-generation onion router. In: Proceedings of the 13th USENIX Security Symposium. (August 2004)
23. Øverlier, L., Syverson, P.: Locating hidden servers. In: Pro-ceedings of the 2006 IEEE Symposium on Security and Privacy, IEEE CS (May 2006)
24. S. Yadav, A. K. K. Reddy, A. N. Reddy, and S. Ranjan. De-tecting algorithmically generated malicious domain names. In Proceedings of the 10th annual Conference on Internet Mea-surement, IMC ’10, pages 48–61, New York, NY, USA, 2010. ACM
25. G. Gu, J. Zhang, and W. Lee. BotSniffer: Detecting botnet command and control channels in network traffic. In Network and Distributed System Security Symposium (NDSS), 2008 26. J. Matonis. The Bitcoin Mining Arms Race: GHash.io and the
51% Issue, July 2014
Denial-of-Service Attacks. In European Symposium on Research in Computer Security (ESORICS), 2005
28. M. Vasek, M. Thornton, and T. Moore. Empirical analysis of denial-of-service attacks in the Bitcoin ecosystem. In Workshop on Bitcoin Research, 2014.
29. T. Holz, C. Gorecki, K. Rieck, and F. Freiling. Measuring and Detecting Fast-Flux Service Networks. In Symposium on Network and Distributed System Security, 2008
30. E. Cooke, F. Jahanian, and D. McPherson. The zombie roundup: Understanding, detecting, and disrupting botnets. In Usenix Workshop on Steps to Reducing Unwanted Traffic on the Internet (SRUTI), 2006
31. R. Arends. Dns security introduction and requirements, rfc 4033. http://www.faqs.org/rfcs/rfc4033.html, 2005.
32. J. Oberheide, M. Karir, and Z. Mao. Characterizing dark dns behavior. In Fourth GI International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (DIMVA ’07), 2007
33. N. Provos, D. McNamee, P. Mavrommatis, K. Wang, and N. Modadugu. The Ghost in the Browser: Analysis of Web based Malware. In Usenix Hotbots 2007, April 2007.
34. M. Antonakakis, R. Perdisci, W. Lee, N. Vasiloglou, and D. Dagon. Detecting malware domains in the upper DNS hierar-chy. In the Proceedings of 20th USENIX Security Symposium (USENIX Security ’11), 2011
