A fix for multiple vulnerabilities affecting all uTorrent, BitTorrent and uTorrent Web Windows users is now available for immediate download at the links below. We must stress that while this is a vulnerability that can be exploited to trigger unauthorized downloads to take place, BitTorrent Inc. is not aware of any incidents related to these vulnerabilities. As always, we highly encourage all of our customers to stay up to date. Android and Mac users are not affected by the reported vulnerabilities.

Download the latest builds:

uTorrent Stable
Bittorrent Stable
uTorrent Beta
uTorrent Web

The team began rolling out the update to beta uTorrent Windows users via the auto update mechanism on Feb 16, 2018. As of today, Feb 22, 2018, the rollout for beta users has concluded and the stable rollout has started. Included in the latest builds are fixes to the way uTorrent and uTorrent Web authenticate WebUI requests and generate session and authentication tokens. In addition to this, the updates clamp down on guest account access limits and enforce more checks on potentially malicious HTTP headers sent to the client.

Customers and developers of 3rd-party applications that rely on the default-open state of port 10000 should be aware that moving forward, clients will no longer be discoverable over port 10000. Pairing negotiation is now only allowed over a mutually agreed upon port. Customers can set this port manually by enabling WebUI functionality via Advanced->WebUI-> Enable Web UI and then specifying a port under the Connectivity section.


You can find the full changelog here:

uTorrent 3.5.3 For Windows (build 44358)

On Feb 1, 2016 we were informed about a DLL planting[1] vulnerability in uTorrent/BitTorrent by the team behind The Zero Day Initiative[2]. All versions of uTorrent prior to and BitTorrent are affected.

Older versions of uTorrent/BitTorrent would “pin” netprofm.dll at startup in an attempt to mitigate a (an old) crash due to premature DLL unloading. The “pinning” mechanism employed had the undesirable effect of allowing a local attacker to execute code during uTorrent/BitTorrent’s startup by dropping (or “planting”) a specially crafted DLL in the program’s working directory (or current directory at time of application launch)[3].

This explicit DLL load combined with the WebUI’s ability to download files to uTorrent/BitTorrent’s working directory, could have allowed an attacker to execute arbitrary code by instructing uTorrent/BitTorrent to download cleverly crafted .torrent through the WebUI.

To mitigate the vulnerability, the latest versions of uTorrent/BitTorrent:
– Will not pin netprofm.dll at startup. The DLL is loaded when required as any other DLL.
– Will not allow the WebUI to download files to uTorrent/BitTorrent’s working directory.

We ask all uTorrent/BitTorrent users to update to the latest stable versions linked below:

To stay up to date with upcoming changes in the next stable build follow our beta changelog here.

Thank you to The Zero Day Initiative for responsibly reporting this vulnerability.
– uTorrent/BitTorrent Team

[1] https://www.us-cert.gov/ncas/alerts/TA10-238A
[2] http://www.zerodayinitiative.com/
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/ff919712(v=vs.85).aspx

We’ve recently released a preview build of Sync IT, our upcoming product designed specifically for moving data in enterprise environments. We wanted to share a deeper dive into the technical improvements we’ve made at the protocol level for Sync IT.

Sync IT will introduce a new protocol that is dedicated to optimizing transfer speeds over WAN, satellite, or mobile networks. This new μTP2 protocol was designed to work over networks with high latency and some packet loss, which is crucial when moving data over the mixed infrastructure or fat pipes increasingly common for enterprise IT.
Continue Reading…

In our connected world, no one is safe from malware. All types of software are constantly under attack, making security a major issue for software developers everywhere, every day.

This week, the first ransomware on Mac was discovered in a release by the Transmission team. It’s understandable that this has made news, particularly given that this is the first direct malware attack to impact OS X users.

On behalf of our friends at Transmission, we would urge understanding and ask users to look at their body of work when judging them and not a single incident which they quickly and decisively handled.

By many accounts, this vulnerability for OS X has existed for some time. Every company, every website, is prone to vulnerabilities. There is no software vendor out there that has not done its fair share of firefighting. It is a credit to all the teams that can flag and address an issue quickly before it reaches consumers becomes widespread.

It was unfortunate that Transmission was the vector of this first attack, but kudos to the team for reacting quickly to release a fixed version that removes the malicious code. The issue was discovered on March 4th and addressed the next day. Having gone through a few of these fire drills myself, I understand what kind of effort it takes to react that quickly to an issue.  If you are reading this and you use Transmission, please download their latest version to remove the malware.

What is also important to note, and many news outlets have reported this correctly, is that the attack was not on the BitTorrent protocol nor on Transmission’s client. The attack does not affect other BitTorrent clients, nor does it affect the files you download via BitTorrent. This attack was directed at OS X itself via a packaged file within the installer tool used to download Transmission. Palo Alto Networks describes it here:

Attackers infected two installers of Transmission version 2.90 with KeRanger on the morning of March 4. When we identified the issue, the infected DMG files were still available for downloading from the Transmission site (hxxps://download.transmissionbt.com/files/Transmission-2.90[.]dmg) Transmission is an open source project. It’s possible that Transmission’s official website was compromised and the files were replaced by re-compiled malicious versions, but we can’t confirm how this infection occurred.

As developers of software used by millions of people, we have to be ever vigilant.  All of us take security seriously and try very hard to thwart attacks of any variety.  So once again, hats off to the Transmission team for dealing with this threat quickly.

On July 1st, 2015, the security team at BitTorrent received a report [1] from Florian Adamsky about Distributed Reflective Denial of Service (DRDoS) vulnerabilities affecting several BitTorrent products making use of UDP-based [2] protocols. uTorrent, BitTorrent and BitTorrent Sync use the Micro Transport Protocol (µTP) [3] implementation in libuTP [4] as the preferred transport backend running on top of UDP. While these vulnerabilities have been described before in other alerts [5] in this post we’ll discuss how an attacker can exploit a weakness in libuTP connection initiation allowing them to send BitTorrent handshake data to a third party.

UDP, Spoofing and Amplification

UDP, being a connectionless protocol, does not require peers to carry out handshakes before data is allowed to be transmitted; it is, by design, a send-and-forget protocol. By spoofing the source address in a UDP packet an attacker can trick an intermediate node into sending data to a third party. If an attacker can find a UDP protocol that sends responses larger than initial requests it can amplify the traffic directed at a victim. In fact, as recent as February 2014 attackers were able to do just this by leveraging public Network Time Protocol (NTP) [6] servers.


Attacker A can forge packet source addresses and send them to a set of reflection sources R1, R2..R4. The reflection sources will in turn direct their responses to a victim V.

The efficacy of this type of attack is commonly measured by how much traffic an attacker has to input into the attack vs. the traffic the victim observes. Using the diagram above, this simply means how many bytes an attacker, we’ll call “A,” has to send to R1, R2, … RN vs. how many bytes the reflectors at R1, R2, .. RN send to the victim we’ll call “V.” We call the ratio of these two the Bandwidth Amplification Factor (BAF). A high BAF indicates an efficient attack while low BAF indicates a low efficiency or high-effort attack.

Attacker A can initiate a µTP connection to reflector R1 with:

62 bytes for an initial SYN +
130 bytes for the BitTorrent Handshake.
(sizes include Ethernet, IP, UDP and libµTP headers)

If the attacker advertises it supports the extension protocol [7] the reflector can respond to the victim with up to:

62 bytes to acknowledge the first SYN +
62 bytes to acknowledge the BitTorrent Handshake +
366 bytes as a BitTorrent Handshake response

Since V does not acknowledge R1’s packets, R1 will be forced to retransmit the data up to 4 times before giving up further increasing the BAF.

libµTP: a vulnerability and a mitigation

Many BitTorrent products make use of libµTP because it can detect network congestion and automatically throttle itself. This self-throttling characteristic makes BitTorrent, µTorrent and BitTorrent Sync friendlier to home networks. However, a flaw in the way libµTP handles incoming connections may leave many clients vulnerable to become unknowing accomplices in amplification attacks as reflectors.

If we observe libµTP connection sequencing we’ll spot the flaw. Note that µTP makes use of sequence and acknowledgement numbers in much the same way as TCP does. In the example below we can see the attacker started the attack with a SYNchronize with sequence #209 and acknowledgement #0.


Snapshot of a theoretical attack against libuTP.

After the reflector has received the first packet from an attacker it transitions over to a connected state at (1). At this point the reflector has received the connection packet #209, and is expecting #210 next. It lets the victim, V, know of this fact by sending an acknowledgement packet with the next sequence number available to the reflector, for the example I’ve chosen #31.

Soon after, the attacker needs to send the first data payload, this will be the BitTorrent protocol header. To properly build the packet the attacker will need to provide the reflector with acknowledgement number of the last received packet at (2).

The flaw in libµTP would allow the reflector to accept any acknowledgement number at (3) allowing the attack to be carried out. A mitigation relies on the fact that it would be fairly difficult for an attacker to guess the acknowledgement number at (2) for a sufficiently large number of reflectors.

The intention of the change is to reduce the BAF to as low a value as possible making attacks like this very high-effort. While the attacker will still be able to initiate a connection to the reflector, by dropping the packet at (3) the victim sees only an acknowledgement packet at (2). The first few exchanges of the connection will now look like this:

Attacker sends the following to the reflector:

62 bytes for an initial SYN +
130 bytes for the BitTorrent Handshake

And the victim receives:

62 bytes to acknowledge the first SYN

As of August 4th, 2015 uTorrent (3.4.4 40911), BitTorrent (7.9.5 40912) and BitTorrent Sync (2.1.3) clients using libµTP will now only transition into a connection state if they receive valid acknowledgments from the connection initiators. This means that any packets falling outside of an allowed window will be dropped by a reflector and will never make it to a victim. Again referring to the diagram above, this means that (3) is dropped and (4), (5) and (6) never make it to the victim. Since the mitigation occurs at the libµTP level, other company protocols that can run over libµTP like Message Stream Encryption (MSE) are also serviced by the mitigation.

[1] https://www.usenix.org/system/files/conference/woot15/woot15-paper-adamsky.pdf
[2] https://en.wikipedia.org/wiki/User_Datagram_Protocol
[3] http://bittorrent.gyre.wpengine.com/2010/05/21/%C2%B5tp-open-source-implementation/
[4] http://www.bittorrent.org/beps/bep_0029.html
[5] https://www.us-cert.gov/ncas/alerts/TA14-017A
[6] https://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack/
[7] http://www.bittorrent.org/beps/bep_0010.html

Our initial implementation of asynchronous offline messaging in Bleep[1] used an encryption scheme which provided authentication and confidentiality, but not forward secrecy[2]. This meant that if the private key of Alice or Bob was compromised, Eve could use the key to decrypt any of their offline messages she had previously captured.

Providing forward secrecy for offline messages is not as straightforward as it is for messages sent when both Alice and Bob are online. For the latter, forward secrecy is provided as part of our encrypted tunnel protocol. If either Alice or Bob is offline a tunnel cannot be established. Thus for offline messages we must find an alternative method of providing forward secrecy.

A key element of forward secrecy is the use of ephemeral keys. Ephemeral keys are used for some short period of time then discarded. Once a key is discarded any data encrypted with it cannot be decrypted ever again. Our encrypted tunnel protocol generates new ephemeral keypairs for every connection and exchanges the public component of them as part of the handshake used to establish the connection. Of course this handshaking only works if Alice and Bob are both online, so how can they exchange ephemeral keys when one of them is offline?

Happily, the same DHT facility we use to exchange offline messages can also be used to exchange ephemeral keys. When Alice and Bob first add each other as contacts they generate ephemeral keypairs and publish the keys’ public components in the DHT, just as they would an offline message. Alice and Bob save each other’s offline ephemeral keys for future use. When Alice wants to send an offline message to Bob she uses their saved ephemeral keys to encrypt the message. When Bob receives the message he uses his copy of the ephemeral keys to decrypt it. After decrypting the message, Bob discards his ephemeral key and publishes a new one in the DHT. Once Alice sees Bob’s new ephemeral key she replaces the one she has stored for him.

One downside of this scheme is that the granularity with which messages are rendered indecipherable is larger than when using our encrypted tunnels. There are multiple factors which make this reduced granularity unavoidable. The structure of data stored in the DHT means that messages can only be received in last-in-first-out order. This means that if we were to ratchet the key between each message, as we do for encrypted tunnels, a recipient would not be able to decrypt a list of messages until the entire list was received. This would defeat the point of ratcheting so we do not use it for offline messages. Of course, the asynchronous nature of offline messages requires allowing Alice to encrypt any number of messages without receiving a new ephemeral key from Bob. For lack of a better option we simply reuse the same key for every message until a new ephemeral key is received. Thus forward secrecy is only maintained up to the last time Alice and Bob managed to exchange ephemeral keys via the DHT.

[1] http://engineering.gyre.wpengine.com/2014/12/22/bleep-now-supports-asynchronous-offline-messaging/
[2] http://engineering.gyre.wpengine.com/2014/12/11/authentication-and-forward-secrecy-in-bleep/

This post originally appeared on Jason’s blog, Codeabout

Coming from Python, for the most part, I felt right at home in the Clojure REPL. However, one of my trustiest old tricks in the Python interpreter didn’t work nearly as well in Clojure.
Continue Reading…

A Note on the DDoS Attacks

Adam Kelly —  January 29, 2015 — 3 Comments

Recently, several sites have noticed DDoS attacks from torrent clients in China. These attacks are not originating in the torrent ecosystem, but are caused by DNS servers returning incorrect IP addresses for well-known BitTorrent trackers.

While the identity of the perpetrators and the motivation remain unclear, we here at BitTorrent would like to share some of our expertise that may help website operators mitigate these attacks.

Torrent Trackers work similarly to a normal HTTP server, but in a more limited fashion. Torrent clients contact the server, and ask it information about the torrent and the swarm.

Because of this, the misdirected torrent clients will contact the victim HTTP server, and see what looks like a valid HTTP response (although not a valid “scrape reply”).

If you follow the link to Jamie’s blog, you will notice that that he suggests a configuration change for Apache similar to the one below:

[Credit Jamie Zawinski]

In our example above, we’ve changed the response code from 404 to 410. uTorrent, Bittorrent, and torrent clients based on the excellent libtorrent library will interpret this HTTP response code as “do not attempt to contact this tracker again”. That will cause the request traffic to fall off much faster.


This is the first of two posts. To read the second, on metadata for BitTorrent Bundles, click here.

If you’ve followed the news lately, you’ll have noticed that BitTorrent is on its way up in the music world. When we’re not busy launching an album for Radiohead’s Thom Yorke or boosting a Madonna movie, we’re helping smaller artists knock down the castle walls that have excluded them from success in the music business.
Continue Reading…