To evaluate the amplifier churn and robustness of the detected vul- nerabilities in a real-world attack, I wrote a BitTorrent crawler which consists of two modules. The first module used theMLDHTnetwork to find new peers and the second module established a connection via
uTPto the find peers and exchange the BitTorrent handshake message. Overall, I found 9.6 million possible amplifiers when 2.1 million peers responded to the MLDHTrequests. The next subsection describes the
architecture of the BitTorrent crawler and presents the results from the use of this crawler.
7.5.2.1 Architecture of a BitTorrent Crawler
I programmed the BitTorrent crawler in the programming language
Elixir18, which is a functional, fault-tolerant and concurrent language
built on top of the Erlang Virtual Machine (EVM). Figure 7.6 shows
the architecture of this crawler.
Architecture of the BitTorrent Crawler
SuperVisor SuperVisor SuperVisor DB Worker DHT Harvester Peer Requester DB Internet 1:1 1: 1 1:1 1: 1 1:n 1:n
Figure 7.6: Architecture and supervision tree of the BitTorrent Crawler. Ev- ery rectangle is a process. DB denotes the database. Source: own representation.
The green rectangles in Figure7.6 are supervisors. Supervisors are processes that observe other processes. If an observed process crashes unexpectedly, the supervisor automatically restarts the process. The blue rectangles are workers. These perform the actual work. The DB (database) worker is a process which is connected to the study’s PostgreSQL database. The supervisors of the DHTharvester and the peer requester start n process each. I set n = 5 to completely fill the async-threads ofEVM.
Before I began the crawler, I filled a database table ‘torrents’ with the complete magnet database from Piratebay from 13th February
2012. This database comprised 1.6 million unique infohashes. Each
MLDHTharvester process selects an un-requested infohash and sends
a get_peers request with the infohash to a bootstrapping node. This node returns a list of nodes that are closer to the infohash which the harvester saves in the database. The requester then selects an un- requested node and sends it a get_peers request. Additionally, the harvester process saves meta information from the responses, includ- ing payload size, version of the BitTorrent client, and the number
7.5 experimental evaluation 119 of nodes. The harvester takes another infohash if it has requested
1000peers.
The peer requester selects peer information from the MLDHT har-
vester and sends a st_syn packet to a peer. If this peer responds within 10 seconds with a st_state packet, the crawler sends a Bit- Torrent handshake with all extensions enabled to that peer. This pro- cess then waits for a reply and saves all responses to the database.
7.5.2.2 Mainline Distributed Hash Table network
The BitTorrent crawler collected over 9.6 million peers via MLDHT
beginning from January 1st, 2015 and continuing until February 1st,
2015. Of these peers, 2.1 million responded to the get_peers re- quest. This corresponds 21.9 % of peers. Of these responsive peers, 67.8 thousand peers included participating peers, or 3.2 %. The rest returned only k neighbors. Figure7.7 shows a histogram of payload sizes fromMLDHTresponses.
Histogram of the Payload Size from theMLDHTResponses
0 500 1,000 1,500 2,000 2,500 3,000 0 1 2 3 4 5 ·104 1.0 3.1 5.3 7.4 9.5 11.6
Payload size in bytes
Number
of
receiv
ed
packets
Figure 7.7: Histogram of the payload size from the Distributed Hash Table responses which are caused by get_peers requests. The num- bers above the bars are the average Bandwidth Amplification Factor values. Source: own representation based on own survey. The mean of all received values is 665.6 bytes which results in aBAF
of 7. The biggest response had a size of 3344 bytes providing a BAF
BAF of 0.9. With such observations, the conclusion can be made, that MLDHT can be exploited but most responses do not produce a high
BAF value. Therefore, I used the peer information gathered from the MLDHTnetwork to request a BitTorrent handshake to test the efficacy. 7.5.2.3 Micro Transport Protocol Distribution
In this section, I analyze responses from BitTorrent handshake mes- sages. The BitTorrent crawler sent a st_syn packet to every partici- pating peer in the database. If a peer responded within 10 seconds, the crawler sent a BitTorrent handshake to this peer. I collected 10,417 handshakes viauTP. I first address the question of the distribution of the payload size of the first data packet because this is crucial for the impact of the amplification attack. Figure 7.8 shows the distribu- tion of the payload size from all BitTorrent handshakes which were received.
Histogram of the BitTorrent Handshake Size fromuTPResponses
400 600 800 1,000 1,200 1,400 0 100 200 300 31.2 (15.7 %) 46.7 (2.2 %) 66.9 (3.9 %)
BitTorrent Handshake size in bytes
Number
of
receiv
ed
packets
Figure 7.8: Numbers above the peaks are Bandwidth Amplification Factor (BAF) values; the numbers in brackets are the relative frequency. It can be observed that three packet sizes stand out: 665 bytes, 1000 bytes, and 1438 bytes. These three packet sizes would be the most often response in an amplification attack. Source: own representation based on own survey.
The histogram in Figure7.8 shows three peaks in the distribution. The first peak comprises 15.7 % of all handshakes and would result in a 665 bytes and a 5 times retransmission with aBAFof 31.2. The next
7.5 experimental evaluation 121 peak is around 1000 bytes with a frequency of 2.2 %. This results in a
BAFof 46.7. The third peak has the highest payload size of 1438 bytes and comprises 3.9 % of all handshakes. Retransmitted five times, this would result in aBAFof 66.9.
The mean of all received packets is 810.8 bytes. The maximum value is 1438 bytes and the min value is 313 bytes. AllBAFvalues are calculated with retransmission of 4 packets (total of 5 packets), be- cause this is the default foruTP. I also analyzed allLTEPmessage that
were in the firstuTPdata packet. ALTEPmessage contains a dictionary
entry with the client version. Table7.1evaluates these messages.
version count percentage
uTorrent 3.4.2 8616 82.7 BitTorrent 7.9.2 1641 15.8 uTorrent 3.4.1 107 1.0 uTorrent 3.4 27 0.3 BitTorrent 7.9.1 14 0.1 Unknown 9 0.1 BitTorrent 7.9 2 0.0
Table 7.1: Client software and version number of the inspected Libtorrent Extension Protocol messages. Source: own representation based on own survey.
It can be seen that the latest uTorrent and BitTorrent version where on top of the list in Table 7.1. Only 0.1 % of the BitTorrent clients were unknown, because they were not transmitting anLTEPmessage. Because I crawled only theMLDHTnetwork, Vuze is not in the list. In
the next subsection, I discuss the difficulty of circumventing aDRDoS
attack that exploits BitTorrent.