Archives For

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 3.4.7.42330 and BitTorrent 7.9.7.42331 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:
uTorrent 3.4.7.42330
BitTorrent 7.9.7.42331

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

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

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.

image00

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.

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

image02

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] https://bittorrent.gyre.wpengine.com/2010/05/21/%C2%B5tp-open-source-implementation/
[4] https://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] https://www.bittorrent.org/beps/bep_0010.html