P2P File-Sharing in Hell: Exploiting BitTorrent Vulnerabilities to Launch

Distributed Reflective DoS Attacks

Florian Adamsky

City University London

florian.adamsky.1@city.ac.uk

Syed Ali Khayam

PLUMgrid Inc.

akhayam@plumgrid.com

Rudolf Jäger

THM Friedberg

rudolf.jaeger@iem.thm.de

Muttukrishnan Rajarajan

City University London

r.muttukrishnan@city.ac.uk

Abstract

In this paper, we demonstrate that the BitTorrent proto-

col family is vulnerable to distributed reflective denial-

of-service (DRDoS) attacks. Specifically, we show

that an attacker can exploit BitTorrent protocols (Mi-

cro Transport Protocol (uTP) [32], Distributed Hash Ta-

ble (DHT) [30], Message Stream Encryption (MSE) [8])

and BitTorrent Sync (BTSync) [6] to reflect and amplify

traffic from peers. We validate the efficiency, robustness

and evadability of the exposed BitTorrent vulnerabilities

in a P2P lab testbed. We further substantiate the lab

results by crawling more than 2.1 million IP addresses

over Mainline DHT (MLDHT) and analyzing more than

10,000 BitTorrent handshakes. Our experiments reveal

that an attacker is able to exploit BitTorrent peers to am-

plify the traffic up to a factor of 50 times and in case of

BTSync up to 120 times. Additionally, we observe that

the most popular BitTorrent clients are the most vulnera-

ble ones.

1 Introduction

DDoS attacks continue to become increasingly devastat-

ing, despite widespread adoption of mechanisms to cir-

cumvent IP spoofing1. In 2013, CloudFlare registered

a DDoS bandwidth record by an attack which gener-

ated nearly 300 Gbps traffic [36]. A year later, a new

record was established by a DDoS attack that generated

400 Gbps [37]. Both these record-setting attacks be-

longed to a category of DoS attacks where the attacker

does not send traffic directly to the victim; traffic is in-

stead sent to reflectors (with spoofed source IP of the vic-

tim) which in turn flood the victim with responses. Such

a DRDoS attack becomes particularly potent if the re-

flectors send higher volumes of traffic to the victim than

1According to the Spoofer project [9], more than 70 % of the pub-

lic networks implement BCP 38 [18] to circumvent IP source address

spoofing.

what they received from the attacker—i.e. the reflectors

act as amplifiers.

The impact of a DRDoS attack is proportional to the

adoption of the protocol that it is exploiting, as wide

adoption makes it easier to find and scale-out the ampli-

fier population. The two attacks mentioned above were

particularly devastating because they exploited DNS and

NTP, both of which are widely-used protocols in the In-

ternet today.

In this paper, we show that BitTorrent, one of the most

popular P2P file sharing protocols2, can also be exploited

to launch DRDoS attacks. BitTorrent and BTSync make

use of UDP protocols. Since these protocols do not in-

clude mechanisms to prevent IP source address spoofing,

an attacker can use peer-discovery techniques like track-

ers, DHT or Peer Exchange (PEX) [7] to collect millions

of possible amplifiers.

We use the following three criteria to understand the

impact of the vulnerabilities exposed in this work:

1. Efficiency: defined in terms of Bandwidth Amplifi-

cation Factor (BAF) [39] and ease of amplifier iden-

tification;

2. Robustness: defined in terms of attack resilience un-

der amplifier churn; and

3. Evadability: in terms of difficulty of attack circum-

vention (at amplifiers and victims) and ease of eva-

sion.

We evaluate the detected vulnerabilities on the above

criteria. Experiments are first performed on a custom

testbed with 33 peers. We further substantiate our find-

ings by crawling 2.1 million IP addresses over MLDHT

and analyzing more than 10,000 BitTorrent handshakes.

Our experiments demonstrate that BitTorrent has a

bandwidth amplification factor (BAF) of 50 times and

2According to some recent measurements, BitTorrent comprises

3.35 % of the worldwide bandwidth [35].

1

PA

Attacker

PA

PA

PA

Amplifiers

PV

Victim

BA

BA

BA

BV

BV

BV

Figure 1: Schematic diagram of the threat model of a

DRDoS attack.

in case of BTSync up to 120 times. Moreover, we ob-

serve that the most widely-used BitTorrent clients like

uTorrent, Mainline and Vuze are also the most vulner-

able ones. We also show that a possible attack is quite

robust under amplifier churn as the BitTorrent protocol

is widely-adopted and new amplifiers can be discovered

quite quickly using standard peer discovery mechanisms.

Finally, we show that due to its use of dynamic port

ranges and encryption during handshake (in terms of

MSE), a DRDoS attack that exploits BitTorrent cannot

be detected using a standard firewall, and would instead

require Deep Packet Inspection (DPI) to be detected.

2 Background

In this section, we provide a brief overview of DRDoS

attacks and the BitTorrent protocol family. While dis-

cussing BitTorrent, we highlight the vulnerabilities that

can be exploited.

2.1 Distributed Reflective Denial-of-

Service (DRDoS) Attacks

An attacker which initiates a DRDoS does not send the

traffic directly to the victim; instead he/she sends it to

amplifiers which reflect the traffic to the victim. The at-

tacker does this by exploiting network protocols which

are vulnerable to IP spoofing. A DRDoS attack results in

a distributed attack which can be initiated by one or mul-

tiple attacker nodes. Figure 1 outlines the threat model

of a DRDoS attack.

The attacker PA in Figure 1 needs to identify am-

plifiers before initiating the attack. This step is depen-

dent on the protocol which the attacker wants to exploit.

Internet-wide scanning tools like ZMap [17] can help to

identify possible amplifiers. The speed and ease of iden-

tifying new amplifier is fundamentally important to all

the criteria (attack efficiency, robustness under amplifier

churn, and evadability at amplifiers and victims) that we

used as a efficacy benchmark throughout this paper.

After the attacker has identified amplifiers, PA initi-

ates the attack by sending small packets BA to the am-

plifiers PA. Instead of using its own socket address, the

attacker spoofs the address in the packet BA from the vic-

tim PV . The amplifiers respond to the victim PV with a

larger packet BV . This type of attack has several advan-

tages:

• the attacker hides his own identity, since the attacks

uses IP spoofing (evadability advantage);

• it can be initiated by a single computer, but results

in a distributed attack (efficiency advantage); and

• the amplifiers send a larger packet to the victim

and therefore increase the impact of the attack (effi-

ciency advantage).

The ratio of the smaller and larger packet is known as

BAF [39]:

BAF =

jBvj

jBaj ; (1)

where the payload to the victim is denoted as jBvj and the

amplified payload from the victim as jBaj. For instance,

a BAF of 5 times means, that an attacker with 1 Gbps

upload capacity can send 5 Gbps of traffic to the victim.

Similar to BAF, a Packet Amplification Factor (PAF) is

defined as the ratio of the number of packets sent from

the amplifier to the victim and the number of packets sent

from the attacker to the amplifier.

2.2 BitTorrent Protocol Family

In this section, we first introduce the BitTorrent termi-

nology which we used throughout this paper. We then

briefly discuss the different protocols.

Node: A physical or virtual machine with an IP stack.

Peer: A node that runs a BitTorrent client.

Swarm: All the peers sharing a torrent.

Torrent: A file that contains metadata about the BitTor-

rent swarm and the distributed files.

Info-hash: SHA-1 hash (160 bit) from the .torrent file

which identifies a swarm.

2

Peer-id: Unique ID which identifies a single peer which

is chosen at random.

Seeder: A peer that has downloaded the complete con-

tent and shares it with other peers.

Leecher: A peer which is downloading content of the

torrent.

BitTorrent is the most commonly-used P2P protocol

of the world today3. The novelty of this protocol is, that

it provides solutions for the free riding problem [11] and

the last piece problem [23]. To overcome the first prob-

lem, BitTorrent uses an incentive mechanism called the

choking algorithm [13] which results in a tit-for-tat-ish

way of sharing. BitTorrent solves the second problem by

introducing the rarest piece first algorithm [28].

Similar to all P2P systems, BitTorrent also has to over-

come the bootstrapping problem: how can a new peer

join the network when there is no central contact point?

The original BitTorrent specification introduces the con-

cept of a tracker, which is a server that registers all par-

ticipating peers. Before a newly-joined peer can partic-

ipate, it requests the tracker for contact information of

other peers.

Over time, a number of extensions to the BitTorrent

protocol have been proposed to avoid a central (tracker)

contract point; see, for instance, DHT [30], PEX [7] and

Local Peer Discovery (LPD) [33]. If the new peer has a

number of peers, it starts to connect to them and sends a

special BitTorrent handshake.

Originally, TCP was the default protocol for hand-

shake and all subsequent communications with peers.

TCP, however, has some disadvantages when used in a

P2P environment, as it distributes the available band-

width evenly across all connections. Since a P2P applica-

tion uses multiple connections, it always gets more band-

width than other applications. As a consequence, BitTor-

rent, which is usually meant to run in the background,

ends up interfering with the foreground traffic (like web

surfing or emails). This is why BitTorrent invented a new

transport protocol called uTP.

2.3 Micro Transport Protocol (uTP)

BitTorrent Inc. announced in December 2008 that uTor-

rent will switch its default transport protocol from TCP

to uTP [21]. This protocol sits on top of UDP and imple-

ments a novel congestion control called Low Extra Delay

Background Transport (LEDBAT) [24]. This congestion

control detects foreground traffic by using one way delay

3BitTorrent’s bandwidth usage is geographically disparate [35]; e.g.

in Europe, it comprises 31.8 % of all upstream traffic and 12.1 % of

downstream traffic during peak hours [42].

connection established

Initiator Receiver

SYN_SENT

CONNECTED

ST_SYN

CONNECTED

ST_STATE

Figure 2: Two-way handshake to initiate a connection

between two uTP nodes. The text on the outer edge re-

flects the state of the protocol.

measurements. If the difference between the measure-

ments increases, the sender automatically throttles back.

uTP [32] adopts a few ideas from TCP. It controls the

flow with a sliding window, verifies data integrity with

sequence numbers and initiates a connection with a hand-

shake. Unlike TCP, uTP uses a two-way handshake in-

stead of a three-way handshake. Figure 2 depicts the

message flow to establish a connection between two uTP

nodes.

It can be seen that the initiator sends a ST_SYN packet

to the receiver to initiate a connection. This is similar to

the SYN packet in TCP. The receiver acknowledges the

ST_SYN packet with a ST_STATE packet. After receiving

that packet, the bidirectional connection is successfully

established.

Most of the present BitTorrent clients now implement

uTP as the default transport option. In the next section

we will show how an attacker can exploit uTP to start an

amplification attack.

3 Amplification Vulnerabilities in uTP

In this section, we reveal amplification vulnerabilities in-

troduced by three popular BitTorrent protocols: BitTor-

rent [14], BTSync [6], and uTP [21].

3.1 Two-way handshake of uTP

As described briefly in Section 2.3, uTP establishes a

connection with a two-way handshake. This allows an

attacker to establish a connection with an amplifier us-

ing a spoofed IP address, as the receiver does not check

whether the initiator has received the acknowledgment.

We first tested this idea with the uTP test program ucat

which is attached to libutp4. This program is the coun-

terpart of netcat but uses uTP instead.

We setup a receiver that provides an arbitrary binary

file when responding to ST_DATA. The attacker sends

4https://github.com/bittorrent/libutp

3

Attacker Amplifier Victim

ST_SYN a)

ST_DATA (Handshake) c) ST_STATE

b) ST_DATA (Handshake)

d)

ST_DATA (Handshake)

ST_DATA (Handshake)

Figure 3: In uTP the initiator sends a ST_SYN packet

to the receiver. The receiver acknowledgs this with a

ST_STATE packet. After that, the connection is estab-

lished (two-way handshake).

a forged ST_DATA to this receiver with the spoofed IP

address of the victim. The receiver believes that the

source IP address in that packet is valid and sends the first

ST_DATA packet to the spoofed address. Since the forged

address has not expected that packet, it does not send

an acknowledgment back. The receiver runs into timeout

and retransmits the lost ST_DATA packet. If 4 consecutive

transmissions have timed out, uTP kills the connection.

In this experiment, the receiver has sent 5 packets with

a payload size of 1402 bytes, which results in 7030 sent

bytes. According to Equation (1), this results in a BAF

of 351.5 times, since the initiator only sends a ST_SYN

packet with a size of 20 bytes.

uTP does not send more packets because it implements

a slow-start mechanism. The max_window starts with

1382 bytes and increases for every acknowledgment it

receives. When it is not receiving acknowledgments, it

remains at that value. To the best of our knowledge, uTP

is only used by BitTorrent so far. TOR project, however,

thought about replacing TCP with uTP [29], but came to

the conclusion that it is not trivial to replace it.

Let us now highlight how an attacker can exploit the

two-way handshake of uTP with BitTorrent.

3.2 Exploiting BitTorrent Handshake via

uTP

After the connection is established BitTorrent requires a

handshake as its first message. It contains reserved bytes

for extensions, info-hash and the peer-id. If a client re-

ceives a handshake with an info-hash that it does not par-

ticipate, the client drops the connection immediately. An

attacker can use the BitTorrent handshake to initiate an

amplification attack based on the two-way handshake of

uTP. Figure 3 outlines such an attack scenario.

The attacker initiates a connection with a spoofed

ST_SYN packet to the amplifier in a). The amplifier re-

sponds in b) with an acknowledgment via a ST_STATE

packet to the victim. This packet does not contain use-

ful information, because uTP only supports the two-way

handshake. In step c), the attacker sends an ST_DATA

packet with a BitTorrent handshake in the payload.

This handshake needs an info-hash (20 bytes) of an

active torrent of the amplifier. The handshake has a min-

imum size of 88 bytes. If the amplifier participates in that

torrent, it will respond in d) with its own handshake. The

handshake in d) is bigger than the packet which the at-

tacker has sent, since the clients put additional messages

in the uTP packet.

In our tests, nearly all clients either sent either a

BITFIELD or multiple HAVE messages within the first

uTP data packet. If and how many HAVE messages are

sent with the handshake, depends on the client imple-

mentation. The size of the BITFIELD message depends

on the size of the shared files. Since the handshake from

d) does not get acknowledged, the amplifier thinks the

packet is lost and retransmits the handshake again. In

our tests, all clients retransmitted the handshake from 3–

4 times until the connection gets terminated.

BitTorrent provides Libtorrent Extension Proto-

col (LTEP) to add new extensions without interfering

with the default protocol. If an attacker signals that it

supports the LTEP, that is specified in BEP 10 [34], it

can further amplify the attack without increasing the

size of the handshake in c); i.e. efficiency of the attack is

only enhanced as LTEP it is a simple bit that is set in the

extension byte. With that extension, the peers exchange

peer information with each other. All tested clients send

these messages together with the handshake. This is

because one uTP packet can contain multiple BitTorrent

messages. We refer to this vulnerability as BitTorrent

Handshake (BTH).

The BAF of BTH is as follows:

BAFBTH(p;n) =

20+20+ p(n+1)

20+88

; (2)

where p denotes the payload size, n denotes the num-

ber of retransmissions, and all numbers are in bytes. The

number of retransmissions n gets incremented by one,

since the first regular packet does not belong to the re-

transmissions. The 20 bytes on the denominator belongs

to the ST_SYN packet and the 88 bytes belongs to the

ST_DATA packet that contains the BitTorrent handshake.

The 40 bytes on the numerator are the acknowledge-

ments of two sent packets.

In the next subsections, we evaluate the BAFBTH for

the five most commonly-used BitTorrent clients [41],

namely uTorrent (48 % market share), Vuze (22 %), Bit-

Torrent mainline client (13 %), Transmission (7 %) and

LibTorrent (1 %).

4

3.2.1 Mainline and uTorrent clients

We have tested uTorrent 3.4.2 (built 35702) and main-

line BitTorrent 7.9.2 (built 35144) on Windows 7. Since

mainline BitTorrent version 6.0 is uTorrent with a re-

branded GUI, we handle both clients together. In our

tests, both clients sent not only the BitTorrent handshake,

but also one BITFIELD, multiple HAVE messages and one

PORT message. The number of HAVE messages that the

client sends depends on the protocol state of the client. If

the client is in leech state, it sends the number of pieces

that it has already downloaded, but not more than 24.

In seed state, the client always sends 24 HAVE messages,

thus resulting in a BAF of 27.5 times.

If the attacker sets the LTEP bit in the handshake

and the amplifier also supports it, the amplifier sends

an additional extension message handshake in the first

packet. This handshake is a bencoded dictionary that

contains meta information about the peer (e.g. version of

client) and also a list of extensions that the peer supports.

We observed that in both clients the LTEP handshake is

larger compared to other clients. This is because they

put more meta information in that packet. Both clients

also support more extensions which are not public, like

ut_holepunch and ut_comment. This additional hand-

shake increases the BAF up to 39.6 times.

3.2.2 Vuze

Vuze is the most commonly-used BitTorrent client. We

have tested Vuze 5.4.0.0/4 (formerly Azureus) on Win-

dows 7. Without signaling any extensions, Vuze re-

sponds only with the BitTorrent handshake and a com-

plete BITFIELD message. Vuze sends the uTP packet

four times. This results in a BAF of 13.9 times. Vuze

does not only support LTEP, but it has also designed its

own extension protocol called Azureus Message Proto-

col (AMP) [3].

If an attacker signals that it supports LTEP and the

amplifier also supports it, the amplifier adds the addi-

tional extension handshake. Compared with uTorrent,

the handshake is smaller, because Vuze does not support

the proprietary extensions from uTorrent. The BAF in-

creases through LTEP up to 18.7 times. An attacker can

increase the BAF if it signals that it supports the AMP.

Vuze uses AMP to transmit BitTorrent messages,

Azureus messages and other communications like chat

messages. If the AMP bit is set in the client hand-

shake, a Vuze amplifier adds the following messages

to the packet: AZ_HANDSHAKE, AZ_PEER_EXCHANGE,

AZ_REQUEST_HINT, AZ_STAT_REQ and AZ_HAVE. This

increases the handshake up to 1165 bytes, which in-

creases the BAF to 54.3 times. This value can be even

higher, since the BITFIELD message depends on the

size of the shared files. In our analysis we used the

Ubuntu 14.10 image that has a size of 1.2 GByte.

3.2.3 Transmission and LibTorrent

We tested with Transmission 2.84 (built 14307) on

Ubuntu 14.04.1. Transmission supports both LTEP

and AMP. However, Transmission does not add any

other BitTorrent message in the first uTP data packet

than the handshake. It does not matter which extension

is activated, Transmission only sends 88 bytes in a

BitTorrent handshake and resends a lost packet three

times. According to this, an attacker can only achieve a

BAF of 4.0 if the amplifier uses the Transmission client.

Libtorrent is a BitTorrent library written in C++ which

is used by over 25 different BitTorrent clients. We have

tested libtorrent 1.0.2 on Ubuntu 12.04. Like Transmis-

sion, libtorrent does not add any other BitTorrent mes-

sage to the first uTP data packet, except the handshake.

Where libtorrent is different, compared to Transmission

is the number of retransmissions. Libtorrent resends a

lost packet six times, which increases the BAF up to 5.2

times. If a peer wants to obfuscate its BitTorrent traf-

fic, it starts with MSE handshake instead of a BitTorrent

handshake.

3.3 Exploiting Message Stream Encryp-

tion (MSE) Handshake

The aim of MSE [8] is to obfuscate BitTorrent traffic to

avoid shaping, rather than to encrypt the traffic securely.

In addition to that MSE encrypts the traffic and provides

confidentiality. The first objective of MSE, however, was

to obfuscate the traffic to avoid traffic shaping by ISPs.

Brumley and Valkonen showed in their paper [12] that

MSE has a number of serious weaknesses. It is imple-

mented by most of the BitTorrent clients like uTorrent,

BitTorrent mainline, Vuze, Transmission, libtorrent, Bit-

Comet, etc.

The protocol starts with a Diffie-Hellman key ex-

change (DH), where each peer generates a 768 bit pub-

lic key. To avoid having fixed length packets, each peer

generates random data r with a length of 0–512 bytes

and adds it to the public key. After the key exchange,

the packets are RC4 encrypted. The transport protocol of

these messages are based on uTP. One advantage of this

method is that an attacker does not have to know a valid

info-hash from the amplifier.

An attacker can send a spoofed MSE handshake that

includes 768 bit public key without random data. A

client which supports MSE responds with its public key

and random data. Hence, the BAF for a client with MSE

is.

5

BAFMSE(r;n) =

(116+r)(n+1)

116

; (3)

where r is the length of the random data with interval

0 bytes r 512 bytes and n the number of retransmis-

sions n = f4;5;6g. According to Equation (3), BAFMSE

ranges from 4–32.5 times.

The results of this section demonstrates that an at-

tacker who exploits MSE can significantly enhance the

efficiency of the BTH attack. Furthermore, note that the

encrypted payload of BA and BV packets generated using

MSE have a high entropy and are therefore hard to detect

and to block with Stateful Packet Inspection (SPI) or DPI

firewalls. Statistical measurements, however, show good

results to detect MSE [22, 25], but are not widespread

used. Hence, use of MSE also helps in making the attack

difficult to detect and circumvent, hence contributing to

the evadability of the attack. To avoid a central tracker,

BitTorrent included the DHT protocol to the BitTorrent

protocol family.

3.4 Exploiting DHT Messages

The DHT implementation in BitTorrent clients is di-

vided into two protocols: MLDHT [30] and Vuze DHT

(VDHT) [5]. The MLDHT is by far the biggest overlay

network with users of around 15–27 million [43] per day.

Both protocols are not compatible with each other. DHT

is used to find peers that share the same torrent. The

MLDHT implementation is discussed in the next subsec-

tion.

3.4.1 Mainline DHT

The MLDHT supports the following queries: ping,

find_node, get_peers and announce_peer. The

ping query is the most basic one and tries to find out

if a peer is available via DHT. The request contains the

command ping and peer-id which consists of a 20 byte

string. Together with the RPC protocol, a ping request

has a size of 56 bytes. The response only contains the

peer-id of the responding peer, therefore the response

packet has a size of 47 bytes. The ping query does not

amplify the bandwidth.

The find_node query tries to find the k closest peers

for a specific peer-id. The request contains both the

peer-id of the requesting and sought peer. Together

with the RPC overhead, the payload of a request packet

has a size of 95 bytes. A peer responds with a list

of k peers, whereby BitTorrent Enhancement Proposal

(BEP) 05 [30] sets k = 8. According to this, the response

varies from 283–332 bytes, depending on the implemen-

tation. In our tests we found two DHT peers5 which set

5router.utorrent.com and router.bittorrent.com

Table 1: Amplification factors of the different MLDHT

queries.

Description BAF

ping 0.8

find_node with K = 8 3.1

get_peers with 100 peers (IPv4) 11.9

get_peers with 100 peers (IPv6) 24.5

get_peers with scrapes 13.4

k = 16. These peers are the bootstrapping peers for most

BitTorrent clients. This results in a BAF of 5.2 times.

get_peer query is much more interesting, as it re-

turns a list of peers for a given info-hash. If the peer does

not have peers for that info-hash, it will return a list of k

peers, similar to the find_node query. This means, only

peers which are involved in a swarm are able to send a

list of participating peers back. BEP 05 does not say any-

thing about a limit for the peers. In our tests, we found

peers which send a list of 100 peers back which results

in a BAF of 11.9 times. If a peer would only return IPv6

addresses, this would increase the BAF up to 24.5 times.

With an additional extension, we can increase the pay-

load of the response even further.

BEP 33 [4] describes an extension to DHT called DHT

scrapes. Scrapes are statistics of a swarm like the num-

ber of seeders, leechers and complete downloads. It

is a method to assess the state of a swarm which is

based on bloom filters. To request scrapes a peer has

to send a get_peer request that contains the dictionary

entry scrape. If the responding peer has database en-

tries for a particular info-hash, it returns the statistics in

the get_peer response. With that request, we were able

to increase this value up to 13.4 times. The BAF of all

queries from the MLDHT is summarized in Table 1.

3.4.2 Vuze DHT

The Vuze ping query without any special flags is similar

to the results from the mainline DHT. The value of BAF

is 0.8 times. Vuze, however, supports the Internet co-

ordinate system Vivaldi [15, 40] which aims to estimate

the round trip time of other peers without testing it. If

the protocol version is >= 10, then the amplifier adds

Vivaldi network coordinates to the ping packet. This

increases the ping reply packet up to an BAF of 14.9

times.

3.5 Exploiting BitTorrent Sync

BTSync is a proprietary protocol that makes use of uTP

to synchronize files in a P2P way. This protocol cur-

rently has 1 million users [38] which makes it an in-

teresting target for amplification attacks. We investi-

6

gated three BTSync messages which can be exploited:

tracker request, BTSync handshake and a ping message.

For all messages, an attacker needs a valid BTSync se-

cret. There are, however, a number of public websites

like [1, 2] where BTSync users publish their secrets. An

attacker can use these secrets to run an amplification at-

tack. The first message is the tracker request.

By default, BTSync will contact a tracker to request

peers for a specific secret. The tracker is run by Bit-

Torrent Inc. and uses the domain t.usyncapp.com. A

DNS request resolves this domain to four IP addresses

which are hosted by Amazon’s EC2 cloud. The tracker

request starts with a uTP ST_SYN packet followed by a

ST_DATA packet that contains a bencoded payload which

includes the peer-id, secret, local address and local port.

The tracker responses with a list of peers. The response

is bigger than the request. It depends, however, highly on

the number of peers the trackers sends. The next message

is the BTSync handshake.

The BTSync handshake is similar compared to BitTor-

rent. The ST_DATA packet contains a bencoded packet

with the secret and a 16 bytes nonce value which can be

random. The peer responses with a 160 bytes public key

and a 16 bytes salt value. This yields to a BAF of 10.8

times.

The ping is a normal UDP packet that starts with the

string BSYNC followed by a zero byte and a bencoded

dictionary. The dictionary contains the command ping,

20 bytes long secret and 20 bytes long peer-id. The

UDP payload of this packet is altogether with the over-

head of the dictionary 76 bytes. The other side also re-

sponds with a ping message. But not just one—it sends

117 ping messages and 12 uTP ST_SYN packets to the re-

quester. This yields to a BAF of 120.2 and a PAF of 129.

This happens with BTSync versions 1.4 and 2.0.105.

3.6 Discussion

As a summary, we have listed all the BAF values in Ta-

ble 2. Our protocol analysis shows that BitTorrent is

highly vulnerable to DRDoS attacks. An attacker is able

to amplify the traffic beginning from 4–54.3 times. If

an attacker knows the peer-id from the amplifier, he/she

is able to predict the BitTorrent client and start a target-

oriented attack. This is possible through the peer-id con-

vention which is defined in BEP 20 [20]. Even if a client

does not support uTP, an attacker can still exploit DHT

or MSE with a lower BAF value. This means that nearly

every client can be exploited, which makes such an at-

tack very efficient and robust against peer churn. The

next section will focus on the experimental evaluation of

these exploits.

Table 2: Amplification Factors of the different BitTorrent

clients with a BitTorrent handshake with uTP.

Description BAF PAF

ucat 351.5 6

uTorrent w/o extensions 27.6 3.5

Mainline w/o extensions 27.8 3.5

uTorrent with LTEP 39.6 3

Mainline with LTEP 39.6 3

Vuze w/o extensions 13.9 2

Vuze with LTEP 18.7 2

Vuze with AMP 54.3 3.5

Transmission w/o extensions 4.0 3.5

Transmission with LTEP 4.0 3.5

Transmission with AMP 4.0 3.5

Libtorrent w/o extensions 5.2 4

Libtorrent with LTEP 5.2 4

4 Experimental Evaluation

In this section, we show that the attacks presented in this

paper are efficient, robust and difficult to circumvent.

4.1 Efficiency

We perform experiments in our testbed system consist-

ing of 33 nodes: 1 attacker, 1 victim and 31 ampli-

fiers. All nodes are desktop machines which are running

Ubuntu 12.04.02 LTS.We installed uTorrent server V3.3

on all amplifiers with a private torrent of 1 GByte in seed

mode.

The attacker in our experiment runs a scapy6 script

that sends forged uTP packets to the amplifier. It first

sends 31 uTP ST_SYN packets then it waits for 1 second

and sends 31 uTP ST_DATA packets which contain a Bit-

Torrent handshake. The script waits then for 120 sec-

onds, since otherwise the amplifiers would just termi-

nate the connection with a ST_FIN packet. The attacker

script does not need to save the state for each peer, which

makes it quite efficient. An I/O graph can be seen in Fig-

ure 4.

It can be seen that after the attacker sends the forged

packet, the amplifiers sends the traffic to the victim. The

first peak is the highest, since both, the acknowledge-

ment for the first SYN and the handshake arrive together

at the victim. The following peaks are the retransmis-

sions of the handshake and acknowledgement. During

our experiments we noticed that uTorrent for Linux be-

haves differently compared to the Windows client. The

attack had an amplification factor of 14.6 times.

6http://www.secdev.org/projects/scapy/1

7

0 100 200 300 400 500 600

0

0:5

1

1:5

2

104

Time in seconds (s)

Payload size in bytes

Figure 4: Amplification attack with 1 attacker, 31 am-

plifiers and 1 victim. The blue line shows the payload

size that the attacker sends to the amplifier. The red line

shows the payload size that the amplifier sends to the vic-

tim.

4.2 Robustness

To evaluate the robustness of our detected vulnerabili-

ties against amplifier churn in a real-world attack, we

wrote two BitTorrent crawlers. The first one searched

the MLDHT network and the second one used the results

from the MLDHT network to start a BitTorrent hand-

shake via uTP. We tracked 9.6 million possible am-

plifiers where 2.1 million peers were responding to our

DHT requests. First we describe our crawler architecture

and then we present our results for the DHT network and

the handshake requests.

4.2.1 Architecture

We programmed our crawler in the programming lan-

guage Elixir, which is a functional and concurrent lan-

guage built on top of the Erlang Virtual Machine (EVM).

Our crawler is open source and can be found on GitHub7.

At first we filled a database table “torrents” with the

complete magnet database from Piratebay from 13th

February 2012. This database comprised 1.6 million

info-hashes. Each DHT harvester process takes an info-

hash and sends a find_node request to a bootstrapping

node. This node returns 20 peers, which the harvester

saves in our database. At that time, the requester takes

peers from our databases and sends find_node requests

to it. Additionally, we save meta informations from the

responses e.g. payload size, version of the BitTorrent

client, number of nodes and so on. The harvester stops

when it has requested 1000 peers.

7https://github.com/cit/bt_crawler

0 500 1;000 1;500 2;000 2;500 3;000

0

2

4

104

1.0

3.1

5.3

7.4 9.5 11.6

Payload size in bytes

Number of received packets

Figure 5: Histogram of the payload size from the DHT

responses which are caused by get_peers requests. The

numbers on top of the bars are the average BAF values.

The peer requester uses the results from the DHT har-

vester and sends a ST_SYN packet to that peer. If the peer

sends us a ST_STATE packet, we respond with a BitTor-

rent handshake that has all extensions enabled. Then this

process waits for a reply and saves all responses to our

database.

4.2.2 Mainline DHT Network

We collected overall 9.6 million peers via MLDHT

beginning from 1st January 2015 until 1st February

2015. From those peers, 2.1 million responded to our

get_peers request, which corresponds to 21.9 %. From

these responding peers 67.8 thousand peers included par-

ticipating peers, which corresponds to 3.2 %. The rest

were only returning k neighbors. Figure 5 shows a distri-

bution of the payload size of all responses.g

The mean of all received packets is 665.6 bytes which

results in a BAF of 7 times. The max value is 3344 bytes

with a BAF of 35.2 times and the min value is 82 bytes

results in a BAF of 0.9 times. From the above data it

is clear that MLDHT can be exploited, but most of the

responses do not produce a high BAF value. Therefore,

we used the gathered peer information from the MLDHT

network to request a BitTorrent handshake to test the ef-

ficacy.

4.2.3 uTP distribution

In this section we analyze the responses from the uTP

requests. For every peer that participates in a torrent,

we send a uTP ST_SYN packet. If we get a ST_STATE

between 10 seconds we send a BitTorrent handshake to

that peer. Overall, we collected 10,417 handshakes via

8

400 600 800 1;000 1;200 1;400

0

100

200

300

BitTorrent Handshake size in bytes

Number of received packets

Figure 6: Histogram of the BitTorrent handshake size

from the uTP responses.

uTP. The first question that we answer is the following:

What is the distribution of the payload size of the first

data packet? Since this is crucial for the impact an ampli-

fication attack which can be seen in Equation 2. Figure 6

shows a histogram of the payload size of all received Bit-

Torrent handshakes.

The histogram shows clearly that there are three peaks

in the distribution of the payload size. The first peak

is the highest value of 665 bytes. This peak comprises

15.7 % of all handshakes and would result with a 5 times

retransmission of BAF of 31.2 times. The next peak is at

around 1000 bytes with a frequency of 2.2 %. This would

result a BAF of 46.7 times. The last peak is the highest

payload size of 1438 bytes. It comprises 3.9 % of all

handshakes and result in a BAF of 66.9 times. The mean

of all received packets is 810.8 bytes, the max value is

1438 bytes and the min value is 313 bytes. We calculated

BAF values above with a number of retransmissions of

4 packets (total of 5 packets), since this is the protocol

default.

We analyzed all LTEP message that were in the first

uTP data packet. A LTEP message contains a dictionary

entry with the exact client version. Table 3 shows the

evaluation of these messages.

It can be seen that the latest uTorrent and BitTorrent

version tops the list in Table 3. Only 0.1 % were un-

known, since they were not transmitting an LTEP mes-

sage. Since we only crawled the MLDHT network, Vuze

is not in our list. In the next subsection, we will discuss

how difficult it would be to circumvent an DRDoS attack

that exploits BitTorrent.

4.3 Evadability

DNS and NTP use well-known ports for their service. As

a consequence, the reflected traffic can easily be blocked

Table 3: Client software and version number of the in-

spected LTEP 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 4: Comparison of amplification vulnerabilities and

with which firewall technology it can be defended

DNS’13

NTP’14

BTH

MLDHT

VDHT

BTSync

MSE

SPI firwall X X

DPI firewall X X X X

by a SPI firewall. This is not possible with BitTorrent,

since it uses dynamic ports. The payload of the Bit-

Torrent handshake contains the character 19 followed by

the string “BitTorrent protocol”. In case of BTSync the

handshake contains the string “BTSYNC”. In both cases,

the victim needs DPI hardware to block an attack from

these protocols.

The situation looks different when an attacker exploits

MSE. The payload of a MSE handshake is completely

random. Table 4 shows comparison of the different pro-

tocols and with which firewall technology it can be de-

fended. In the next section, we will discuss the counter-

measures of the proposed attacks.

5 Countermeasures

In this section we will discuss countermeasures against

the presented vulnerabilities. The root cause of these at-

tacks is the IP source address spoofing. It has been seen

that the anti-spoofing filtering techniques like Ingress

address filtering and unicast reverse path are effective

against IP spoofing. In practice these techniques have

limits, especially in an ISP infrastructure. The Spoofer

project measures the susceptibility of IP spoofing around

the world since 2005 until now [9]. According to

their latest measurements from 2015, 26.1 % of all au-

tonomous systems allow spoofing and 15.5 % allowed

partial spoofing. We think a working countermeasure

must follow two parallel ways: global ISP coordination

to prevent IP spoofing and protocol defense mechanism

to avoid protocol exploitation.

9

5.1 Handshakes over uTP

The presented attacks are only possible, since uTP makes

use of the two-way handshake. Therefor it is possible for

an attacker to send a spoofed BitTorrent or MSE hand-

shake via uTP to an amplifier. We highly recommend

that uTP switches to the three-way handshake, like TCP.

It would prevent the presented attacks, since both nodes

do not send data until the last acknowledgment arrives,

like some TCP devices do [27]. The disadvantage of this

approach is that it is a significant change in the protocol.

An alternative that does not prevent the attack, but reduce

the impact, is to limit the messages in the first uTP packet

to one, like the clients in Section 3.2.3. This results in a

maximum BAF of 4–5 times.

5.2 DHT

UDP tracker, MLDHT an VDHT already have a counter-

measure against index poisoning attacks [31]. It prevents

an attacker to add other peers except from themself to the

DHT network with the announce_peer or STORE call. It

does this, by requiring a token that a peer has to request

from a previous get_peers or FIND_NODE query. This

token is valid for 10 minutes and prevents spoofing at-

tacks but only for the announce_peer or STORE query.

To prevent amplification attacks it would be necessary to

request the token in the ping query, since it is the one

with the smallest BAF value. All other queries need to

require this token. This would prevent any spoofing at-

tacks against DHT. The disadvantage of this mechanism

is that it always requires two DHT queries to request new

peers which slows down the bootstrapping time.

6 RelatedWork

In this Section we will discuss related work that has in-

fluenced and inspired our research.

6.1 Amplification Attacks

Rossow [39] did the first broad investigation of UDP

based protocols. They found 14 protocols that are vul-

nerable, including MLDHT, for which we reproduced

the same results. We, however, did a more thorough in-

vestigation of the BitTorrent family, which includes uTP,

MSE, BTSync, MLDHT and Vuze DHT with different

queries and different clients.

Kührer et al. [26] analyzed the amplifier magnitude

for DNS, SNMP, Simple Service Discovery Proto-

col (SSDP), Character Generator Protocol (CharGen),

Quote of the Day (QOTD), NTP and NetBIOS with

an Internet-wide scan. Additionally, they developed

a remote spoofer test to check if a network allows

IP spoofing. They found more than 2,000 networks

which were lacking of egress filtering. In a follow-up

work, Kührer et al. [27] investigated how vulnerable

TCP is. Despite its three-way handshake, there are

TCP/IP implementations that do not strictly follow the

standard. This means, the implementation sends data

before the three-way handshake is complete.

6.2 P2P DDoS attacks

A number of papers focused on BitTorrent tracker as

their target to run DDoS attacks. Harrington [19] ex-

ploited the fact that peers trust the tracker. They modified

a tracker which instead of distributing a list of participat-

ing peers, it distributes a list of victims. Every peer that

requests that tracker tries to connect to the victims. An

attacker, however, can inject the victim as a tracker it-

self, like presented by Defrawy [16]. Hereby, the victims

get all the tracker requests from peers which results in

a DDoS. We focused instead how vulnerable the BitTor-

rent protocol family is to IP source address spoofing.

In a previous research work [10], we did a security

analysis on uTP. LEDBAT, the congestion control in

uTP, only works with correct feedback from the receiver.

A misbehaving receiver which is not interested in data

integrity can increase the bandwidth consumption up to

five times. This can cause congestion collapse which re-

sults in a DOS attack.

7 Conclusion

BitTorrent and BTSync are vulnerable to DRDoS at-

tacks. We demonstrated that these attacks are efficient.

With peer-discovery techniques like trackers, DHT or

PEX, an attacker can collect millions of amplifiers. An

attacker only needs a valid info-hash or secret to exploit

the vulnerabilities. In that case, we have shown that

the most used BitTorrent clients, uTorrent, Mainline and

Vuze, are highly vulnerable and can be amplified up to a

factor of 50 times. With a single BTSync ping message,

an attacker can amplify the traffic up to 120 times. An

easier amplifier target is a MSE handshake, since an at-

tacker does not need an info-hash. The amplification fac-

tor of this attack ranges from 4–32.5 times. We showed

that a possible attack is robust against amplifier churn.

To validate the robustness of the attack, we wrote a Bit-

Torrent crawler which ran for one month and collected

more than 2.1 million IP addresses and analyzed more

than 10,000 BitTorrent handshakes. We showed that an

attack is quite difficult to circumvent, as the found vul-

nerabilities can only be defended with a DPI firewall. In

case of a MSE handshake, it is even harder to detect the

attack, since the packet contains a high entropy payload

with a public key and random data.

10

References

[1] Public Directory of BitTorrent Sync Keys. http://

btsynckeys.com/.

[2] Reddit: BitTorrent Sync Secrets. http://www.reddit.com/r/

btsecrets/.

[3] Azureus messaging protocol - VuzeWiki. https://wiki.

vuze.com/w/Azureus_messaging_protocol, Oct. 2010.

[4] BEP 33: DHT Scrapes. Tech. rep., BitTorrent Inc., Jan. 2010.

[5] Distributed hash table. https://wiki.vuze.com/w/

Distributed_hash_table, Oct. 2012.

[6] BitTorrent Sync. https://www.getsync.com/, Apr. 2013.

[7] BitTorrentPeerExchangeConventions - The-

ory.org Wiki. https://wiki.theory.org/

BitTorrentPeerExchangeConventions, Apr. 2014.

[8] Message Stream Encryption Format Specification Version 1.0.

http://wiki.vuze.com/w/Message_Stream_Encryption,

May 2014.

[9] Spoofer Project: State of IP Spoofing. http://spoofer.

cmand.org/summary.php, Jan. 2015.

[10] ADAMSKY, F., KHAYAM, S. A., JÄGER, R., AND RAJARA-

JAN, M. Security Analysis of the Micro Transport Protocol with

a Misbehaving Receiver. In Proceedings of the 2012 Interna-

tional Conference on Cyber-Enabled Distributed Computing and

Knowledge Discovery (Oct. 2012), IEEE, pp. 143–150.

[11] ADAR, E., AND HUBERMAN, B. A. Free Riding on Gnutella.

First Monday (2000).

[12] BRUMLEY, B. B., AND VALKONEN, J. Attacks on Message

Stream Encryption. In Proceedings of the 13th Nordic Work-

shop on Secure IT Systems (Copenhagen, Denmark, Oct. 2008),

pp. 163–173.

[13] COHEN, B. Incentives build robustness in BitTorrent. In Pro-

ceedings of 1st Workshop on Economics of Peer-to-Peer Systems

(2003), pp. 1–5.

[14] COHEN, B. BEP 03: The BitTorrent Protocol Specification.

Tech. rep., BitTorrent Inc., Nov. 2013.

[15] DABEK, F., COX, R., KAASHOEK, F., AND MORRIS, R. Vi-

valdi: a decentralized network coordinate system. In Proceedings

of the 2004 Conference on Applications, Technologies, Archi-

tectures, and Protocols for Computer Communications (2004),

ACM Press, pp. 15–26.

[16] DEFRAWY, K. E., GJOKA, M., AND MARKOPOULOU, A. Bot-

Torrent: misusing BitTorrent to launch DDoS attacks. In Pro-

ceedings of the 3rd USENIX Workshop on Steps to Reducing Un-

wanted Traffic on the Internet (June 2007), USENIX Association,

pp. 1–6.

[17] DURUMERIC, Z., WUSTROW, E., AND HALDERMAN, A. J.

ZMap: Fast Internet-wide Scanning and Its Security Applica-

tions. In Presented as part of the 22nd USENIX Security Sympo-

sium (USENIX Security 13) (Washington, Aug. 2013), pp. 605–

620.

[18] ERGUSON, P., AND SENIE, D. BCP 38: Network Ingress Fil-

tering: Defeating Denial of Service Attacks which employ IP

Source Address Spoofing. Tech. rep., Internet Engineering Task

Force (IETF), May 2000.

[19] HARRINGTON, J., KUWANOE, C., AND ZOU, C. C. A

BitTorrent-driven distributed. In Proceedings of the 3th Inter-

national Conference on Security and Privacy in Communications

Networks (2007), IEEE, pp. 261–268.

[20] HARRISON, D. BEP 20: Peer ID Conventions. Tech. rep., Bit-

Torrent Inc., Feb. 2008.

[21] HAZEL, G. Announcements: uTorrent 1.9 alpha 15380. https:

//goo.gl/4ThWLY, Dec. 2008.

[22] HJELMVIK, E., AND JOHN, W. Statistical protocol identification

with SPID: Preliminary results. In Proceedings of the Swedish

National Computer Networking Workshop (2009).

[23] KOSTÍC, D., BRAUD, R., KILLIAN, C., VANDEKIEFT, E., AN-

DERSON, J. W., SNOEREN, A. C., AND VAHDAT, A. Maintain-

ing high bandwidth under dynamic network conditions. In Pro-

ceedings of the annual conference on USENIX Annual Technical

Conference (2005), pp. 193–208.

[24] KUEHLEWIND, M., HAZEL, G., SHALUNOV, S., AND IYEN-

GAR, J. RFC 6817: Low Extra Delay Background Transport

(LEDBAT). http://tools.ietf.org/html/rfc6817, Dec.

2012.

[25] KÖHNEN, C., ÜBERALL, C., ADAMSKY, F., RAKOCEVIC, V.,

RAJARAJAN, M., AND JÄGER, R. Enhancements to Statis-

tical Protocol IDentification (SPID) for Self-Organised QoS in

LANs. In Proceedings of the 19th International Conference on

Computer Communications and Networks (ICCCN) (Aug. 2010),

IEEE, pp. 1–6.

[26] KÜHRER, M., HUPPERICH, T., ROSSOW, C., AND HOLZ, T.

Exit from Hell? Reducing the Impact of Amplification DDoS

Attacks. In 23rd USENIX Security Symposium (USENIX Security

14) (San Diego, CA, Aug. 2014).

[27] KÜHRER, M., HUPPERICH, T., ROSSOW, C., AND HOLZ, T.

Hell of a Handshake: Abusing TCP for Reflective Amplification

DDoS Attacks. In Proceedings of the 8th USENIX Workshop on

Offensive Technologies (San Diego, CA, Aug. 2014), USENIX

Association.

[28] LEGOUT, A., URVOY-KELLER, G., AND MICHIARDI, P. Rarest

first and choke algorithms are enough. In Proceedings of the 6th

ACM SIGCOMM conference on Internet measurement (2006),

ACM Press, pp. 203–216.

[29] LOESING, K., MURDOCH, S. J., AND JANSEN, R. Evaluation

of a libutp-based Tor Datagram Implementation. Tech. rep., Oct.

2013.

[30] LOEWENSTERN, A., AND NORBERG, A. BEP 05: DHT Proto-

col. Tech. rep., BitTorrent Inc., Mar. 2013.

[31] NAOUMOV, N., AND ROSS, K. Exploiting P2p systems for

DDoS attacks. In Proceedings of the International Workshop

on Peer-to-Peer Information Management (2006), ACM Press,

pp. 47–53.

[32] NORBERG, A. BEP 29: uTorrent transport protocol. Tech. rep.,

BitTorrent Inc., June 2009.

[33] NORBERG, A. uTorrent Forum: Local Peer Discovery Documen-

tation. http://goo.gl/jAgTlC, 2009.

[34] NORBERG, A., STRIGEUS, L., AND HAZEL, G. BEP 10: Ex-

tension Protocol. Tech. rep., BitTorrent Inc., Feb. 2008.

[35] PALOALTO NETWORKS. Application Usage Threat Re-

port. http://researchcenter.paloaltonetworks.com/

app-usage-risk-report-visualization/#sthash.

Lme8Q76M.dpbs, 2013.

[36] PRINCE, M. Deep Inside a DNS Amplification

DDoS Attack. http://blog.cloudflare.com/

deep-inside-a-dns-amplification-ddos-attack/,

Oct. 2012.

[37] PRINCE, M. Technical Details Behind a 400gbps NTP Amplifi-

cation DDoS Attack. https://goo.gl/l1vPTN, Feb. 2014.

[38] PROTALINSKI, E. BitTorrent Sync Passes 1 Million Users, Gets

iPad Support and API. http://goo.gl/p46p9y, May 2013.

11

[39] ROSSOW, C. Amplification Hell: Revisiting Network Protocols

for DDoS Abuse. In Proceedings of the Network and Distributed

System Security Symposium (NDSS 14) (2014), Internet Society,

pp. 1–5.

[40] STEINER, M., AND BIERSACK, E. W. Where Is My Peer? Eval-

uation of the Vivaldi Network Coordinate System in Azureus.

NETWORKING 2009 (2009).

[41] VAN DER SAR, E. uTorrent Keeps BitTorrent Lead, BitComet

Fades Away. https://goo.gl/EImuS, Sept. 2011.

[42] VAN DER SAR, E. BitTorrent Traffic Increases 40 https://

goo.gl/d4cGA, July 2012.

[43] WANG, L., AND KANGASHARJU, J. Measuring large-scale dis-

tributed systems: case of BitTorrent Mainline DHT. In Proceed-

ings of the 13th IEEE International Conference on Peer-to-Peer

Computing (Sept. 2013), IEEE, pp. 1–10.

BitTorrent协议漏洞的利用与防范

Florian Adamsky, Syed Ali Khayam and Rudolf

1) Vrije UniversiteitAmsterdam, The Netherlands

2) FORTH-ICS Heraklion, Crete, Greece

3) Columbia University New York, NY, USA

4) Vrije Universiteit Amsterdam, The Netherlands

5) Stevens Institute of Technology Hoboken, NJ, USA

摘  要该论文论证了用分布反射式拒绝服务（DRDoS）攻击能够影响BitTorrent比特流协议簇。此外，我们展示了一个攻击者能够利用比特流BitTorrent协议簇(Micro Transport Protocol (uTP) [32], Distributed Hash Table (DHT) [30]，从bt客户端反射和放大对端设备的流量。我们在一个P2P实验室对已知的BitTorrent漏洞的效率，健壮性，以及可回避性进行测试验证。通过使用超过210万个IP地址的主线DHT(MLDHT)并且分析了超过10，000个BitTorrent handshakes。在实验室测试环境中，研究人员可将流量平均放大50倍，如果利用BTSync，可放大至120倍。此外，我们注意到最流行的BT客户端是容易受到该漏洞影响的。

关键词网络攻击；DoS攻击；协议漏洞

1      介绍

尽管采取了大量的机制去规避IP欺骗，DDoS攻击任然越来越流行且具有极高攻击性。在2013年，CloudFlare注册DDoS带宽纪录产生近300 Gbps的攻击流量[36]。一年后，一个新的DDoS攻击达到400Gbps的流量[37]。这两个纪录的攻击属于一个类别的DoS攻击，这种攻击模式下攻击者不直接与受害者进行流量交互；流量（与受害者带有欺骗性的源IP地址）本来是要发送给reflectors，这个reflectors在对受害者进行相应的时候发送大量数据包。当reflector发送给受害者的流量超过reflector从攻击者那收到的流量的时候，这种DRDoS攻击就显得非常有效，也就是说，这个reflectors就充当了一个放大器的功能。

一次DRDoS攻击造成的影响与它所利用的协议的采纳是成正比的，因为广泛的接受程度使其更容易被找到并且进一步发展到放大流量。上面提到的两种攻击是尤其毁灭性的，就是因为他们利用了DNS和NTP协议这两种在今天的因特网中被广泛使用的协议。

在这篇论文中，我们展示了BitTorrent，时下最流行的P2P文件共享协议，也能被利用来发动DRDos攻击。BitTorrent和BTSync使用了UDP协议。因此这两个协议没有包含阻止伪造源IP地址的机制，攻击者可以使用类似trackes，DHT或者PEX等等的BT客户端节点发现技术去收集无数可能的放大器。

我们使用一下三条标准来理解在这项工作中所暴露出的脆弱性产生的影响：

1，效率：根据BAF和识别放大器轻松程度的标准来定义；

2，健壮性：根据放大器扰动环境下受到攻击的恢复能力来定义；

3，可规避性：依据攻击环境的困难性和躲避攻击的难易程度；

我们从以上标准评估所检测的脆弱程度。实验从一个涉及33个BT客户端节点的自定义测试开始，然后我们进一步通过使用MLDHT抓取210万IP地址并且分析超过10000次BitTorrent握手验证我们的发现（即最初的评估）。

我们的实验表明，BitTorrent有着50倍的流量放大因子（流量可被放大50倍）；在使用BTSync的情况下这个数字可以提高到120倍。此外，我们观察到类似uTorrent，Mainline和Vuse一样最广泛使用的BitTorrent客户端同时也是最容易受到攻击的。我们还展示了，随着BitTorrent协议的广泛采用并且使用基本的BT客户端节点发现机制可以非常迅速的找到新的放大器，一次可能出现的攻击将在放大器扰动的环境下变得非常顽固。最终，我们发现由于动态端口和握手过程加密技术的使用（依据MSE），利用了BitTorrent不能被标准防火墙侦测这一特点的DORDoS攻击，需要DPI才能被检测。

图1: DRDoS攻击的威胁模型。

2      背景

2.1    分布式反射拒绝服务（DRDoS）攻击

攻击者发起一个DRDoS攻击时并不会直接发送流量给受害者，而是把流量发送给一个扩大器，这个扩大器将流量反射给受害者。为实现这一目的，攻击者将利用网络协议的IP欺骗。DRDoS攻击会导致分布式攻击，分布式攻击能有一个或多个攻击者节点进行触发。图一概括了DRDoS攻击的威胁模型。

图片1中的攻击者pa在发起攻击前需要确认扩大器，这一步取决于于协议攻击者想要利用什么，电子扫描工具如ZMap[17]可以帮助识别可能的增强器。速度和易于识别新的放大器基本是对于我们在本文用作功效指标最重要的标准（这些标准包括进攻效率，在放大器搅动中的健壮性，放大器和受害者的可回避性）。

在攻击者确认放大器后，PA发起攻击通过发送给增强器PA，攻击者没有用自己的套接字地址，而是篡改了受害者pv数据包的地址。放大器对受害者pv的回应伴随一个更大的bv包。这种类型的攻击有几个优点：

•因攻击者使用IP欺骗(可规避的优势)，使其隐藏了自己的身份；

•能用一个电脑进行攻击，会导致分布式攻击（高效优势）；

•因为放大器会发送一个更大的数据包给受害者，因此增加了攻击的影响效果（高效优势）；

更小的包与更大的包之间的比率被称为BAF[39]:

|Bv|表示受害者的有效载荷，|Ba|表示从受害者来的放大器的有效载荷。例如，5倍的BAF意味着攻击者用1 Gbps上传容量可以发送5 Gbps的流量给受害者。与BAF相似，包放大系数(PAF)被定义为从放大器发送给受害者的数据包数量与攻击者发送给放大器的数据包数量之间的比率。

2.2    BitTorrent协议簇

这一部分首先介绍了这篇论文中使用的BitTorrent专业术语。随后简短介绍了不同的协议。

Node:一个物理或虚拟机的IP堆栈。

Peer:运行BitTorrent客户端的节点。

Swarm:共享torrent的多个peer。

Torrent:一个包含关于bt群和分布式元数据文件的文件。

Info-hash:识别一个swarm的.torrent文件的SHA-1哈希值（160字节）。

Peer-id:识别随机选中的peer的一个唯一ID。

Seeder:一个下载了完整文件并将文件进行共享的peer。

Leecher:正在下载文件的peer。

BitTorrent是目前最受欢迎的P2P协议。这个协议的新奇之处在于解决了free riding problem搭便车问题[11]以及last piece problem最后块问题[23]。解决第一个问题，BitTorrent使用一个叫做窒息的激励机制算法[13]，但使得分享过程冲突。bt解决第二个问题通过引入最少块优先算法[28]。

类似于所有P2P系统，bt还必须克服引导问题:当网络中没有中心接触点时，如何使新的peer加入网络。最初的bt规范介绍了跟踪器tracker的概念，这是一个注册了所有参与的peer的服务器。新加入的peer参与之前，它会请求跟踪器tracker给其发送其他peer的联系信息。

随着时间的推移，许多扩展bt协议提出了避免中央合同点(tracker跟踪器)，例如DHT[30]，PEX[7]和本地peer发现协议(LPD)[33]。如果一个新的peer发现很多peer，它开始连接他们并发送一个特殊的bt握手。

最初，TCP是握手的默认协议，也是与peer所有后续通信的协议。然而，在P2P环境中使用时TCP有一些缺陷，因为它将可用的带宽均匀分布在所有连接。由于P2P应用使用多个连接，它比其他应用程序总是更多的带宽。因此，bt通常在后台运行，最终干扰前景流量(如上网或邮件)。这就是为什么bt发明了一种新的叫做uTP的传输协议。

2.3    微传输协议(uTP)

bt公司2008年12月宣布uTorrent将其默认协议从TCP传输协议转换为uTP协议[21]。这个协议基于UDP之上，并实现了一种新型的拥塞控制，称为低额外延迟背景交通(LEDBAT)[24]。流量拥塞控制检测前景通过使用延迟测量的方式。如果测量数据之间的差异增加，发送方自动减少流量。

图2:用两次握手在两个uTP节点中建立连接。外缘边的文字表示了协议状态。

uTP[32]采用TCP的一些想法。它使用滑动窗口来控制数据流，使用序列号验证数据完整性并使用握手的方式发起连接。不像TCP的三次握手，uTP使用二次握手的方式。图2描述了两个uTP节点之间建立连接的消息流。

可以看出，发起者将ST_SYN数据包发送给接收者来启动连接。这类似于TCP的SYN数据包。接收者确认ST_SYN包后将ST_STATE数据包发送给链接请求方。链接请求方收到ST_STATE数据包后双向成功建立连接。

现在，bt的大多数客户使用uTP作为默认的运输协议。在下一节中我们将展示攻击者可以利用uTP实现一个放大性攻击。

3      uTP协议中的放大性漏洞

在本节中，我们揭示三种流行的bt协议BitTorrent[14]，BTSync[6]，uTP[21]所带来的放大性漏洞。

3.1    uTP协议的两种握手方式

如2.3节简要描述过的那样，uTP使用双向握手方式建立连接。因为接收方不检查发起者是否已收到确认，这允许攻击者使用虚构的IP地址与一个peer（放大器）建立连接。我们首先测试了相关的uTP程序ucat，这个程序与netcat对应，但使用uTP。

图3:在uTP中，发起者将ST_SYN包发送给接收者。接收者确认ST_STATE包，在这之后链接就建立了(双向握手)。

我们设置一个接收器，在接收ST_DATA数据包时由它提供一个任意的二进制文件。攻击者使用受害者的IP地址链接到接收器，并发送一个伪造的ST_DATA给该接收器。接收器认为数据包的源IP地址是有效的，然后发送第一个ST_DATA包给攻击者提供的IP地址。因为该地址的用户并未请求该包，所以它不发送应答。接收器以为遇到超时并重新传输认为丢失的ST_DATA数据包。如果连续4次传输超时，uTP将断开连接。在这个实验中，接收器发送载荷大小为1402字节的5个数据包，也就是一共给受害者发送了7030字节。根据方程(1)可知，攻击者只发送一个ST_SYN数据包就导致了351.5倍的BAF值。

因为uTP实现了一个缓慢的启动机制，所以uTP不用发送大量包。max_window始于1382字节并且在收到确认时就增加字节。当它不接收应答，它仍然保持该值。据我们所知，到目前为止只有bt使用uTP。TOR项目想用uTP[29]代替TCP，就目前看来还不太可能。

让我们着眼于攻击者如何利用BitTorret以及uTP的两次握手进行攻击。

3.2    通过 uTP协议利用bt流握手方式

在建立连接之后bt需要握手来作为第一次发送消息。它包含了用于扩展的info-hash和 peer id字节。如果客户端收到了包含info-hash的一次握手，而这个握手并不是自己期望的，客户端会立刻断开链接。攻击者可以利用bt流握手方式来发起一次基于两次握手协议的放大性攻击。图3就是这样的攻击形式。

攻击者利用一个虚构的ST_SYN 包对A中的放大器发起连接。B中的放大器将回应受害者，通过发送ST_STATE数据包的方式。这个包不包含有用的信息，因为uTP只支持两次握手。在步骤c中，攻击者发送一个在有效负载内的包含BitTorrent握手的ST_DATA数据包。

这个握手需要一个包含info-hash(20个字节)的，活跃的源放大器的流。握手的最小值为88字节。如果放大器参与这次流，它会回应自己的握手。如D.这次握手的包将会比攻击者发送的包大，因为客户端在uTP包中添加了额外的消息。

在我们的测试中，基本上所有的客户端在第一个uTP数据包中都是要么发送一个BITFIELD消息，要么发送多个HAVE消息。至于有多少HAVE消息应该在握手时发送就取决于客户端的实现了。BITFIELD消息的大小取决于共享文件的大小。 如果从D发出的握手没有得到响应，放大器会认为这个数据包丢失了，并会重新建立握手请求。在我们的测试中，客户端会重发这次握手3-4次直到这个链接被停止。

bt提供了Libtorrent扩展协议(LTEP)以供不干扰默认协议的情况下添加新的扩展。如果攻击者信号支持在BEP 10[34]中的LTEP，它可以进一步扩大攻击，且不必增加握手次数。也就是说，攻击效率的增强就像LTEP,一个简单的扩展字节位设置。有了这一扩展，peer就能相互交换信息。所有的测试的客户端通过握手来发送这些信息。因为一个uTP包可以包含多个bt流的信息。我们称这个漏洞为bt握手(BTH)。BTH的BAF如下：

p表示载荷大小，n表示发送的数和所有数据字节中的数字。重发的次数n随重发次数递增，第一次发送的数据包不属于重发。分母的20字节是ST_SYN包，88字节是bt握手的ST_DATA包，该包包含了bt握手数据。分子上的40个字节是两个发送数据包的确认。

在接下来的部分,我们会评估五个最常用的BAFBTH  BitTorrent客户端，即uTorrent (48 % 市场份额)， Vuze  (22 %)， Bit-Torrent mainline client (13 %)，  Transmission (7 %) 和 LibTorrent (1 %)。

3.2.1           主流的uTorrent客户端

              我们已经在Windows 7下测试了uTorrent 3.4.2(built 35702)和主流bt 7.9.2(built 35144)。由于主流的bt的6.0版本就是uTorrent，只是改了图形界面的名字而已，所以我们一起处理这两个客户端。在我们的测试中，这两个客户不仅发送bt流的握手消息，还发送一个BITFIELD消息，或多个HAVE消息以及一个端口信息。客户端发送的HAVE消息数量取决于客户端协议的状态。如果客户端保持水蛭态，客户端就发送不超过24个、已经下载的块的数量。在种子状态，客户端总是发送24个HAVE消息，从而导致27.5倍的BAF。

如果攻击者在握手时设置LTEP位，并且放大器也支持它，放大器就会在第一个包发送额外的扩展握手消息。这次握手消息是内部代码字典，包含了peer的元信息(例如客户端版本信息)以及peer支持的版本信息列表。我们注意到，在这两个客户端的LTEP握手数据包比其他客户更大。这是因为他们把更多的元信息放进数据包。这两个客户端也支持不常见的扩展版本，比如ut_holepunch和ut_comment。这些额外的握手就增加了39.6倍的BAF。

3.2.2           Vuze

Vuze是最常用的bt客户端。我们已经在Windows7下测试了Vuze5.4.0.0/4(原名Azureus)。Vuze的响应伴随着bt的握手和一个完整的BITFIELD信息，并没有显示任何扩展。Vuze发送四次uTP包。这导致了13.9倍的BAF。Vuze 不仅支持LTEP，它也设计自己的扩展协议称为Azureus消息协议(AMP)[3]。

如果攻击者发信号，表示它支持LTEP并且放大器也支持LTEP，那么放大器将添加扩展的握手。与uTorrent相比，握手是较小的，因为Vuze不支持uTorrent的私有扩展。通过LTEP BAF增加到18.7倍。如果信号支持AMP，攻击者可以增加BAF。

Vuze使用AMP传输比特流bt信息，Azureus消息和聊天信息等其他通信信息。如果已经设置了客户端握手的AMP位，Vuze放大器将会以下信息添加包:AZ_HANDSHAKE,AZ_PEER_EXCHANGE,AZ_REQUEST_HINT,AZ_STAT_REQ AZ_HAVE。这就增加了握手字节，使其最高可达1165个字节，这就增加了54.3倍的BAF。这个值可以更高，因为设置消息取决于共享文件的大小。在我们的分析我们使用Ubuntu 14.10的镜像，大小为1.2千兆字节。

3.2.3           Transmission and LibTorrent

              我们在Ubuntu 14.04.1下测试了Transmission 2.84(built 14307)。传输支持LTEP和AMP。然而与握手相比，传输不在第一次uTP数据包中添加任何其他bt消息。不管使用哪个扩展，Transmission只在bt握手时发送88字节并且丢包后只会重传三次。根据这个，如果放大器是Transmission客户端，攻击者只能达到4.0的BAF。

Libtorrent 是用c++编写的BitTorrent库，并且被25个不同的bt客户端使用。我们已经在Ubuntu12.04上测试了libtorrent 1.0.2 。对于Transmission，除了握手消息libtorrent不添加任何bt消息到第一个uTP数据包。libtorrent与Transmission不同的在于重发的数量。Libtorrent会重发六次丢失的包，这就增加了5.2倍的BAF。如果一个peer要打乱BitTorrent流量，就是在MSE握手开始，而不是bt握手。

3.3    利用消息流加密(MSE)的握手

MSE[8]的目标是扰乱BitTorrent流量避免流量的形成，而不是为了加密产生安全的流量。就MSE加密流量和提供机密性而言，MSE的首要目标是扰乱流量避免ISPs形成流量。Brumley和Valkonen在他们的论文[12]中提到MSE有许多严重的漏洞。它由大部分的bt客户端实现，如uTorrent,BitTorrent mainline,Vuze,Transmission,libtorrent,BitComet等。

协议开始于diffie - hellman密钥交换(DH)，其中每个peer生成一个768位的公钥。为了避免固定长度的数据包，每一个peer产生随机数据r，长度在0 - 512字节，并将其添加到公钥。密钥交换后，数据包以RC4进行加密。这些消息的传输协议是基于uTP的。这种方法的一个优点是攻击者并不需要知道放大器中一个有效的info-hash。

攻击者可以发送一个欺骗性MSE握手消息，包括了768位公钥且不包含随机数据。支持MSE的客户端响应它的公钥和随机数据。因此，客户端的有MSE的BAF。

它的r是随机数据的长度并且间隔为0< r < 512字节，n是发送的字节数，n = { 4，5，6}。根据方程式（3），BAFMSE范围在4-32.5倍。

本节的结果表明，利用MSE的攻击者能显著提高BTH攻击的效率。此外应注意，使用MSE产生BA和BV数据包加密的有效载荷具有较高的熵值，因此很难检测，且用Stateful Packet Inspection (SPI)或DPI防火墙很难阻止。然而，统计测量结果表明能检测MSE(22、25)，但不广泛使用。因此，使用MSE有助于使攻击很难被发现和规避。为了避免中央追踪，bt将DHT协议添加到bt协议家庭。

3.4    利用DHT消息

DHT实现在BitTorrent客户端，分为两个协议:MLDHT[30]和Vuze DHT(VDHT)[5]。MLDHT是迄今为止最大的覆盖网络，每天的用户约每天15-27百万[43]。这两个协议是不兼容的。DHT是用来发现共享相同torrent的peer。MLDHT实现将在下一节讨论。

3.4.1           Mainline DHT

MLDHT支持以下访问:ping、find_node,get_peers以及announce_peer。ping访问是最基本的一个，并能通过DHT找出可用的peer。请求包含ping命令和由20字节的字符串组成的peer-id。RPC协议一起的ping需要有56字节大小。响应只包含响应了的peer的peer-id，因此响应数据包的大小为47字节。ping访问不会放大带宽。

find_node为一个特定的peer-id试图寻找k的值。请求包含正在请求的peer，以及它的peer-id。伴随着RPC开销，请求数据包的有效载荷的大小为95字节。peer将用一列k值的peer进行回应，即数据流增强方案集(cep)05[30]中k = 8。

表1：不同MLDHT访问的放大系数。

因此，响应值在283 - 332字节之间，具体值取于具体实现。在我们的测试中，我们发现两个DHT peers的k = 16。这些peer引导了大部分的bt客户端。这导致了5.2倍的BAF。

get_peer询问有趣得多，它返回一个给定info-hash到peer的列表。如果对方没有peer接收info-hash，它将返回一个列表的k peer，类似于find_node访问。这意味着，只有在swarm中的peer能够回收参与peer的列表。BEP 05没有说任何peer的极限。在我们的测试中我们发现，发送给100个peer的peer导致了11.9倍的BAF。如果一个peer只返回IPv6地址，这将达到24.5倍的BAF。额外扩展，我们可以进一步增加响应的有效载荷。

BEP 33[4]描述的扩展DHT称为DHT scrapes。scrapes是记录数据分享的peer数量，预下载者数量，完成下载的数量的swarm的数量。这是来评估swarm状态的方法，这个swarm基于bloom过滤器。为了请求scrapes，peer必须发送get_peer请求，该请求包含整个scrape字典条目。对特定的info-hash回应的peer有整个数据库条目，它将返回get_peer响应的统计数据。根据这个请求，我们可以将这个值增加到13.4倍。MLDHT所有访问的BAF值总结在表1。

3.4.2           Vuze DHT

Vuze的ping查询没有任何特别的标志位，这与mainlineDHT的结果相似。BAF的值有0.8倍。然而，Vuze支持网络协调系统Vivaldi [15, 40]旨在估计其他peer往返时间，且不进行测试。如果协议版本> = 10，那么在放大器会在ping 数据包中加Vivaldi网络协调机制。这增加了ping应答数据包14.9倍的BAF。

3.5    利用bt同步

BTSync是一种专有协议，利用P2P方式的uTP同步文件。这个协议目前有100万用户[38]这也使得它成为一个有趣的放大器攻击目标。我们调查了三个可以利用的BTSync消息:跟踪请求,BTSync握手和ping消息。对所有信息，攻击者需要一个有效的BTSync机密。而大量的公共网站[1,2]像BTSync用户会发布自己的机密。攻击者可以利用这些秘密运行一个放大的攻击。第一个消息会是tracker发送的请求。

链接tracker以请求peer来得到一个特定的机密。tracker由bt公司发布，域名为t.usyncapp.com。DNS请求解决这个领域四个IP地址，这些IP地址由Amazon的EC2云运行。tracker请求始于uTP的ST_SYN包，该包后跟包含bencoded载荷的ST_DATA包，其中包含有peer-id,秘密,本地地址,本地端口。tracker响应一列表中的peer，且响应数据会大于请求数据。而这大部分取决于tracker发送的peer的数量。下一个消息是BTSync握手。

BTSync握手类似BitTorrent，ST_DATA包包含一个bencoded包的秘密信息和一个可随机的16字节nonce值。peer响应160字节的公钥和一个16字节salt值。这产生了10.8倍的BAF。

ping是一个正常的UDP数据包，该包从字符串BSYNC开始，后跟零字节和bencoded字典。字典包含ping命令，20个字节长秘密信息和20字节peer-id。UDP数据包负载与字典的开销一共76字节。另一边也发出平响应ping消息，不只一个发送117的ping消息和12个uTP的ST_SYN数据包给请求者。这导致了120.2的BAF以及129倍的PAF。这发生在1.4和2.0.105 BTSync版本。

3.6    讨论

根据总结，我们在表2列出了所有BAF值。我们的协议分析表明，bt面对DRDoS攻击显得非常脆弱。攻击者能够放大流量4-54.3倍。

表2：不同bt客户端在uTP下BitTorrent握手的放大系数。

如果攻击者从放大器知道peer-id，攻击者能够预测BitTorrent客户端并开始一个有目标的攻击。这可能通过peer-id公约定义在BEP20[20]。即使客户端不支持uTP，攻击者仍然可以利用BAF值较小的DHT或MSE。这意味着几乎每一个客户端可以被利用，这使得攻击peer超级强大有效。下一节将关注这些利用的实验评价。

4      实验评估

在本节中，我们展示了给出的攻击是有效的,健壮的,难以规避的。

4.1    效率

我们在测试平台系统进行实验，包括33个节点:1攻击者,受害者和31个放大器。所有节点都是运行Ubuntu12.04.02LTS的台式机。我们在所有放大器上安装uTorrent，使其成为服务器V3.31，该服务器的种子模式是1Gbyte的私有bt。

在我们的实验中攻击者运行一个scapy脚本发送伪造的uTP数据包给放大器。它首先发送31个uTP ST_SYN数据包，然后等待1秒并发送31个uTP ST_DATA数据包，其中含有bt握手消息。因为放大器会发送ST_FIN包来终止连接，所以脚本等待120秒。攻击者脚本不需要保存每个peer的状态，这使得它非常有效。一个I / O图如图4所示。

可以看出，攻击者发送伪造数据包后，放大器发送流量给受害者。第一个峰是最高的，因为第一次SYN数据包和握手确认消息同时发送给受害者。下面的山峰是握手的重发和确认。在我们的实验中我们注意到Linux下的uTorrent 与Windows客户端表现不同。

图4：1个攻击者的放大攻击，其中包括31个放大器和一个受害者。蓝线显示了攻击者发送给放大器的载荷大小。红线显示了放大器发送给受害者的负载大小。

图5:反应get_peers请求所引起的DHT载荷大小柱状图。图中最大值是BAF平均值。

4.2    健壮性

在真实的攻击中，为了评估放大器漏洞的健壮性，我们写了两个bt爬虫。第一个搜索MLDHT网络，第二个使用从MLDHT网络得出的结果通过uTP开始bt握手。我们追踪960万个可能的放大器，这些放大器源于210万个对我们的DHT请求进行响应的peer。首先，我们描述我们的爬虫架构，然后我们提出我们的DHT网络和握手请求的结果。

4.2.1           架构

我们用Elixir编写我们的爬虫程序，这个语言建立在ErlangVirtualMachine(EVM)上，具有功能性和并发性。我们的爬虫是开源的，可以在GitHub7上找到。

起初，我们2012年2月13日开始从Piratebay得到“torrents”数据库表的完整数据。这个数据库包含160万info-hashes数据。每个DHT收容程序需要一个infohash和引导节点发送一个find_node请求。这个节点返回20个peer，收割程序将其保存在我们的数据库中。在这个时候，请求者需要从我们的数据库取出peer信息并向peer发送find_node请求。此外，我们从响应数据中保存元信息，如载荷大小、bt客户端的版本，节点数量等等。收割程序请求1000个peer后停止。

peer请求者使用来自DHT收割程序的结果并发送ST_SYN包到peer。如果peer发送给我们ST_STATE数据包，我们回应一个支持所有扩展的BitTorrent握手。然后这个程序等待回复并保存所有的响应到我们的数据库。

4.2.2           DHT主线网

我们通过MLDHT收集了960万个peer，从2015年1月1日开始直到2015年2月1日。这些peer中有210万回应我们的get_peers请求，相当于21.9%。这些响应了的peer中有6.78万个peer正在响应，这对应于3.2%。剩下的只返回k。图5显示了一个分布载荷大小的响应。

所有收到的数据包平均是665.6字节，这导致了7倍BAF。最大值是3344个字节，35.2倍的BAF，最小值为82字节产生0.9倍的BAF。上面的数据明显看出，MLDHT可以利用，但大多数反应不产生较高的BAF值。因此，我们从MLDHT网络中提取了聚集在一起的peer信息，来请求一个bt握手以达到测试效果。

4.2.3           uTP分布

在本节中，我们分析了uTP请求的响应。为每个参与torrent交互的peer发送一个uTP ST_SYN数据包。如果我们在10秒内得到ST_STATE包，我们就发送一个bt握手给这个peer。总的来说，我们通过uTP收集了10417次握手。针对第一个问题我们的回答如下:什么是第一个数据包的有效载荷大小的分布?因为这个对于放大攻击的影响至关重要，从方程2中可以看出。图6显示了收到的bt握手的所有负载大小的柱状图。

图6：uTP响应的BitTorrent握手消息长度柱状图。

柱状图清楚地表明，关于分布载荷的大小有三个峰值。第一个高峰是最高值665字节。这个峰值占到所有握手的15.7%，并将重传5次，达到31.2倍的BAF。下一个高峰在1000字节，出现频率为2.2%。这将导致一个6.7倍的BAF。最后一个峰值是最高的负载大小，为1438字节，它包括3.9%的握手并导致66.9倍的BAF。所有收到的数据包平均是810.8字节，最大值为1438字节，最小值值是313个字节。针对发送4个包(共5包)我们计算了其BAF值，因为这是协议所默认的。

我们分析了第一个uTP数据包中所有LTEP消息。LTEP消息包含一个准确客户端版本的字典条目。

可以看出最近的uTorrent和bt版本在表3中位列榜首。只有0.1%是未知的，因为他们没有传输LTEP消息。因为我们只爬MLDHT网络，而Vuze并不在我们的列表。在下一小节，我们将讨论如何规避利用BitTorrent的DRDoS攻击。

4.3    可回避性

DNS和NTP使用众所周知的端口为他们服务。因此，流量的反映很容易被SPI防火墙阻挡。而bt比特流是不可能被阻挡的，因为它使用动态端口。bt握手的有效负载包含19个字符，之后是字符串“BitTorrent protocol”。为防BTSync，握手包中需包含字符串“BTSYNC”。在这两种情况下,受害者需要DPI硬件来阻止攻击这些协议。

表3：经过观察LTEP消息而得到的客户端软件及其版本的数量。

表4：对比放大器漏洞，并标出能被防火墙技术检测的协议。

当攻击者利用MSE时，情况情况就不同了。MSE握手的有效载荷是完全随机的。表4比较了可以抵抗这一攻击的不同协议和防火墙技术。在下一节中，我们将讨论针对出现的攻击提出策略。

5      策略

在本节中，我们将针对呈现的漏洞讨论对策。这些攻击的根源是IP源地址欺骗。通过欺骗过滤技术这已经能被检测到，比如入口地址过滤和单播反向路径对IP欺骗是有效的。在实践中这些技术有所限制，特别是在ISP的基础设施。自2005年以来直到现在[9]，诱骗设备工程测量了IP欺骗的易感性。根据他们从2015年最新的测量显示，26.1%的自治系统允许欺骗且15.5%允许部分欺骗。我们认为一个工作策略必须遵循两条平行的方式:全球ISP协调以防止IP欺骗和协议防御机制，以避免利用协议。

5.1    uTP下的握手

因为uTP利用双向握手，所以提出的攻击只是理论上可能。因此攻击者有可能发送一个假的bt或通过uTP发送MSE握手消息给一个放大器。我们强烈建议uTP使用三次握手，像TCP那样。使用三次握手可以防止攻击，因为到最后确认数据到达之前，两个节点不发送数据，像一些TCP设备那样[27]。这种方法的缺点在于这是协议的一个重大改变。另一种虽然无法阻止攻击但减少影响的方法是限制第一个uTP包的消息，将其限制到一个。像3.2.3节提出的客户端那样，这导致了4-5倍的BAF。

5.2    DHT

UDPtracker,MLDHTVDHT已经对指数中毒攻击[31]有了应对策略。它可以防止攻击者添加除了自己以外的其他peer以及announce_peer或者STORE调用到DHT网络。这样做要求peer从先前的get_peers或FIND_NODE查询中请求一个令牌。这个令牌有效期为10分钟，能防止欺骗攻击但也只针对announce_peer或STORE查询。防止放大攻击需要在ping查询中请求令牌，因为它有最小的BAF值。其他所有查询需要带上这个令牌。这将防止任何针对DHT的欺骗攻击。这种机制的缺点是，要请求新的peer时它总是需要两个DHT查询请求，这使得引导时间变得缓慢。

6      相关工作

在这一部分，我们将讲述影响和启发到这一研究的相关工作。

6.1    放大器攻击

Rossow[39]做了第一个基于UDP协议的广泛调查。他们发现14个有漏洞的协议其中包括MLDHT，我们复制了相同的结果。而我们基于不同的查询和不同的客户端，做了一个更彻底的bt协议家庭的调查其中包括uTP,MSE,BTSync,MLDHT以及Vuze DHT。

Kührer et al. [26]用广域网扫描了DNS，SNMP，Simple Service Discovery Proto-col (SSDP), Character Generator Protocol (CharGen),Quote of the Day (QOTD), NTP 以及 NetBIOS，分析出了放大器级别。此外，他们进行了一个远程诱骗设备测试，来确定一个网络是否允许IP欺骗。他们发现超过2，000个网络缺少出口过滤机制。在后续工作中Kührer et al. [27]研究了TCP有多脆弱。尽管有三次握手，TCP/IP的实现仍然不严格遵循标准。这意味着在三方握手完成之前就开始发送数据了。

6.2    P2P DDoS 攻击

有大量论文专注于bt比特流跟踪器tracker，基于此来进行DDoS攻击。哈林顿[19]利用peer信任tracker这一事实，他们修改tracker而不分配参与的peer列表，它分发至一系列受害者。每一个请求tracker的oeer试图连接到受害者。然而，攻击者可以作为一个跟踪器本身来注入受害者，就像由Defrawy[16]呈现的那样。因此，受害者得到peer的所有tracker发送的请求，这就导致了DDoS攻击。相反，我们专注对IP源地址欺骗而言，bt协议簇是多么的脆弱。

在先前的研究工作[10]，我们做了一个在uTP上的安全分析。在uTP上的拥塞控制LEDBAT仅适用于正确的接收者的反馈。一个行为不端的对数据完整性不感兴趣的接收者可以增加五倍的带宽消耗。这可能会导致拥塞崩溃，从而造成DOS攻击。

7      结论

BitTorrent和BTSync在DRDoS攻击面前非常脆弱。我们说明了这些攻击是很有效率的。使用诸如trackers，DHT或者PEX等BIT客户端节点发现技术，攻击者可以收集到成千上万的放大器。攻击者只需要一个合法的信息散列或者加密文件来利用这一脆弱性。在上述案例中，我们展示了广泛被使用的BitTorrent客户端如uTorrent,Mainline,Vuze等是非常容易被攻击的，并且流量会被放大至50倍。当使用一个单一的BTSync ping信息时，攻击者可以把流量放大至120倍。自从攻击者不需要信息散列后，一个相对简单的放大器目标就是一次MSE握手。这种攻击扩大的范围是4倍到32.5倍。我们说明了一次可能的攻击在防范放大器干扰方面是健壮的。为了证明攻击的健壮性，我们编写了一个BitTorrent爬行器，运行了一个月收集到超过210万IP地址并且分析了超过10000次BitTorrent握手。我们发现该攻击是非常难以被绕过的，因此被发现的这种脆弱性只有DPI防火墙才能保护。如果在一次MSE握手中，侦测到这种攻击会变得更加困难，因为分组中包含一组含有一个关键码和一些随机数据的高加密有效载荷代码。

参 考 文 献

[1] ABADI, M., BUDIU, M., ERLINGSSON, U., AND LIGATTI, J.Control-flow integrity. In Proc. of the 12th ACM CCS (2005).

[2] ANDERSEN, S., AND ABELLA, V. Changes tofunctionalityinMicrosoft Windows XP Service Pack 2, part 3: Memory protection technologies, DataExecutionPrevention.MicrosoftTechNetLibrary,September2004.http://technet.microsoft.com/en-us/library/bb457155.aspx.

[3] BLETSCH,T.,JIANG, X., FREEH, V. W., AND LIANG, Z.Jump-oriented programming: a new class of code-reuse attack.In Proc. of the 6th ACM ASIACCS (2011).

[4] BOSMAN, E., AND BOS, H. We got signal. a return to portable.exploits. In Proc. of the 35th IEEE S&P (2014).

[5] BUCHANAN, E., ROEMER, R., SHACHAM, H., AND SAVAGE,S. Whengoodinstructionsgo bad: Generalizingreturn-orientedprogramming to RISC. In Proc. of the 15th ACM CCS (2008).

[6] CHECKOWAY, S., DAVI, L., DMITRIENKO, A., SADEGHI, A.-R., SHACHAM, H., AND WINANDY, M. Return-oriented programmingwithout returns. In Proc. of the 17th ACM CCS (2010).

[7] CHEN, P., XIAO, H., SHEN, X., YIN, X., MAO, B., ANDXIE, L.DROP: Detecting return-oriented programming maliciouscode. In Proc. of the 5th ICISS (2009).

[8] CHENG, Y., ZHOU, Z., YU, M., DING, X., AND DENG,R. H. ROPecker: A generic and practical approach for defendingagainst ROP attacks. In Proc. of the 21st NDSS (2014).

[9] COWAN, C., PU, C., MAIER, D., HINTON, H., WALPOLE, J.,BAKKE, P., BEATTIE, S., GRIER, A., WAGLE, P., ZHANG, Q.,ET AL. StackGuard: Automatic adaptive detection and preventionof buffer-overflowattacks. In Proc.of the 7th USENIX SecuritySymposium (1998).

[10] DARK SPYRIT. Win32 buffer overflows (location, exploitation,and prevention). Phrack magazine 9, 55 (1999).

[11] DARKREADING. Heap spraying: Attackers’ latestweapon of choice. http://www.darkreading.com/security/vulnerabilities/showArticle.jhtml?articleID=221901428, November 2009.

[12] DAVI, L., LEHMANN, D., SADEGHI, A.-R., AND MONROSE,F. Stitchingthegadgets:Onthe ineffectiveness of coarse-grainedcontrol-flow integrity protection. In Proc. of the 23rd USENIXSecurity Symposium (August 2014).

[13] DAVI, L., SADEGHI, A.-R., AND WINANDY, M. ROPdefender:A detection tool to defend against return-oriented programmingattacks. In Proc. of the 6th ACM ASIACCS (2011).

[14]DEMOTT,J.Bypassingemet4.1.http://bromiumlabs.files.wordpress.com/2014/02/bypassing-emet-4-1.pdf, February 2014.

[15]DISTORM.Powerfuldisassemblerlibraryforx86/AMD64.https://code.google.com/p/distorm/.

[16] GÖKTA ¸S, E., ATHANASOPOULOS, E., BOS, H., AND PORTOKALIDIS,G. Out of control: Overcoming control-flow integrity.In Proc. of the 35th IEEE S&P (May 2014).

[17] HISER, J., NGUYEN-TUONG, A., CO, M., HALL, M., ANDDAVIDSON, J. W. ILR: Where’d my gadgets go? In Proc. of the33rd IEEE S&P (2012).

[18] HITMANPRO. Real-time exploit mitigation and intrusiondetection. http://dl.surfright.nl/Alert-3/HitmanPro-Alert-3-Datasheet.pdf, February 2014.

[19] HUNT, G., AND BRUBACHER, D. Detours: Binary interceptionof Win32 functions. In Proc. of the 3rd Conference on USENIXWindows NT Symposium (1999).

[20] INTEL. Intel 64 and IA-32 architectures software developer’smanual, volume 3B: System programming guide, part 2. http://www.intel.com.

[21] LI, J., WANG, Z., JIANG, X., GRACE, M., AND BAHRAM,S. Defeating return-oriented rootkits with return-less kernels. InProc. of the 5th EuroSys (2010).

[22] LUK, C.-K., COHN, R., MUTH, R., PATIL, H., KLAUSER, A.,LOWNEY, G., WALLACE, S., REDDI, V. J., AND HAZELWOOD,K. Pin: Building Customized Program Analysis Tools with DynamicInstrumentation. In Proc. of the 26th PLDI (2005).

[23] ONARLIOGLU, K., BILGE, L., LANZI, A., BALZAROTTI, D.,AND KIRDA, E. G-Free: Defeating return-oriented programmingthrough gadget-less binaries. In Proc. of the 26th ACSAC (2010).

[24] PAPPAS, V., POLYCHRONAKIS, M., AND KEROMYTIS, A. D.Smashing the gadgets: Hindering return-oriented programmingusing in-place code randomization. In Proc. of the 33rd IEEES&P (2012).

[25] PAPPAS, V., POLYCHRONAKIS, M., AND KEROMYTIS, A. D.Transparent ROP exploit mitigation using indirect branch tracing.In Proc. of the 22nd USENIX Security Symposium (2013).

[26] PAX TEAM. Address Space Layout Randomization, 2003.http://pax.grsecurity.net/docs/aslr.txt.

[27] PELLETIER, A. Advanced exploitation of Internet Explorer heapoverflow (Pwn2Own 2012 exploit). VUPEN Vulnerability Researchteam(VRT)Blog,July2012.http://www.vupen.com/blog/20120710.Advanced_Exploitation_of_Internet_Explorer_HeapOv_CVE-2012-1876.php.

[28] PORTNOY, A. Bypassing all of the things. EXODUS INTELLIGENCE.https://www.exodusintel.com/files/Aaron_Portnoy-Bypassing_All_Of_The_Things.pdf.

[29] SCHUSTER, F., TENDYCK, T., PEWNY, J., MAASS, A., STEEGMANNS,M., CONTAG, M., AND HOLZ, T. Evaluating the effectivenessof current anti-ROP defenses. In Proc. of the International.Conference on RAID (September 2014). [30] SERNA, F. J. CVE-2012-0769, the case of the perfect infoleak. http://zhodiac.hispahack.com/my-stuff/security/Flash_ASLR_bypass.pdf.93–104, November 2000.

[31] SHACHAM, H. The geometry of innocent flesh onthebone:Return-into-libc without function calls (on the x86). In Proc. ofthe 14th ACM CCS (October 2007).

[32] SHACHAM, H., PAGE, M., PFAFF, B., GOH, E.-J.,MODADUGU, N., AND BONEH, D. On the effectiveness ofaddress-space randomization. In Proc. of the 11th ACM CCS(2004).

[33] SKOWYRA, R., CASTEEL, K., OKHRAVI, H., ZELDOVICH, N.,AND STREILEIN, W. Systematic analysis of defenses against return-oriented programming. In Proc. of the 16th RAID (2013).

[34] SNOW, K. Z., DAVI, L., DMITRIENKO, A., LIEBCHEN, C.,MONROSE, F., AND SADEGHI, A.-R. Just-in-time code reuse:On the effectiveness of fine-grained address space layout randomization.In Proc. of the 34th IEEE S&P (May 2013).

[35] SOTIROV, A. Heap feng shui in javascript. Black Hat Europe(2007).

[36] STRACKX, R., YOUNAN, Y., PHILIPPAERTS, P., PIESSENS, F.,LACHMUND, S., AND WALTER, T. Breaking the memory secrecyassumption. In Proc. of the 2nd EuroSec (2009).

[37] TRAN, M., ETHERIDGE, M., BLETSCH, T., JIANG, X., FREEH,V., AND NING, P. On the expressiveness of return-into-libc attacks.In Proc. of the 14th RAID (2011).

[38] WARTELL, R., MOHAN, V., HAMLEN, K. W., AND LIN, Z.Binary stirring: Self-randomizing instruction addresses of legacyx86 binary code. In Proc. of the 2012 ACM CCS (2012).

[39] ZHANG, C., WEI, T., CHEN, Z., DUAN, L., SZEKERES, L.,MCCAMANT, S., SONG, D., AND ZOU, W. Practical controlflow integrity and randomization for binary executables. In Proc.of the 34th IEEE S&P (2013).

[40] ZHANG, M., AND SEKAR, R. Control flow integrity for cotsbinaries. In 22nd USENIX Security Symposium (2013)