Archives For Announcements

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] http://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] 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

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.

References:
http://furbo.org/2015/01/28/grass-mud-horse/
http://www.jwz.org/blog/2015/01/chinese-bittorrent-the-gift-that-keeps-on-giving/
http://blog.devops.co.il/post/108740168304/torrent-ddos-attack
http://www.bittorrent.org/beps/bep_0031.html

uTorrent

Our flagship torrent clients, uTorrent and BitTorrent, do many different things in the course of downloading content onto your computer faster than what’s physically possible with other protocols. There is a lot of functionality going on under the hood in the course of a download, which fall into three broad categories: networking, disk IO and user interface. We have written before about enhancements in the first two categories (uTP, DHT and multithreaded disk IO, for instance) and are now pleased to announce new improvements in how the user interface interacts with the rest of the system.

In addition to requesting and sharing pieces of files on the network and assembling them on disk, the client needs to convey these activities to the user by showing them on the screen. The logic which displays this information often interacted with the rest of the program in a coarse and intrusive way, requiring networking and/or disk IO to briefly halt while the information was gathered. For example, while viewing the list of files contained in a torrent and their relative download progress, the networking subsystem would be halted several times a second. However brief these pauses were, when multiplied by several UI elements and possibly large lists of torrents and their files, it was enough to slow overall performance.

As an analogy, consider a car’s speedometer as the user interface and the engine, transmission and wheels as the core subsystem doing the work. If the engine had to pause several times a second to update the state of the speedometer, performance would suffer.

To avoid these pauses, the layer between the UI and the rest of the system was made richer and less synchronous. Instead of pausing the subsystem to interrogate values, the UI first conveys broadly what it is interested in (which tab is visible, which torrent is selected), and the subsystem then asynchronously presents only the updated information relative to that state. The user interface layer is then free to present this information without holding up the other layers.

This is an exciting update for us to issue, as the entire engineering team is constantly refining products to try and provide the best user experience.

There’s always more to come on this front, so do stay tuned!

client-hero-torrents

3.4 is an exciting release for the uTorrent team.

3.4 is the first version to include a major change in the way that uTorrent chooses peers in a swarm. Designed by our own Arvid Norberg, Canonical Peer Priority is a way to help peers connect to the swarm faster, as well as reduce the average hop length from you to any other peer in the swarm.

When a bittorrent client joins a swarm, it needs a way to select which peers it connects to. If it chooses poorly, or if there are malicious actors in the swarm, the connections between clients are not well distributed through the swarm, leading to a large number of hops from node to node. That slows down the ability to each client to pass data on to the next.

You can read a more detailed technical discussion of the issues here, along with graphs and figures that drive home how bad the worst case can be. You can read more about graph connectivity here.

Perhaps one of the biggest changes, though, is one you cannot see. Our engineering team has been growing rapidly, and we have been busy changing our development and release processes. uTorrent 3.4 will mark the first release using improved processes that should allow us to release much more often, while keeping stability at the levels you have come to expect from the world’s fastest and lightest torrent client.

Our previous release cycle was slow. We followed the traditional alpha -> beta -> stable model that a lot of software development follows, for example large video games or operating systems. One of the problems with this style of development is as stabilization work continues on the features you just developed, new features are requested, or requirements change, and now you have to balance two lines of development in the same tree.

Also, with more developers, more changes can be made simultaneously … in theory. In reality, changes in unrelated modules (e.g. the installer) would impact when we could ship new code in other areas (e.g. the disk code), and of course, vice versa. This creates a vicious cycle, where each small problem creates a knock-on effect that impacts other features.

In a situation like this, instead of asking the business to “pick one thing and stick with it” the correct response is for the engineering team to change how they operate.

* On a small scale, picking one thing and sticking with it.
* On a larger scale Multiplexing the work into separate branches.

We needed a way to release changes fast and reliably. This implied quite a few things:
* Don’t mix changes
* Release fast, review results fast

This required us to build a few systems. Some of the larger ones:
* Our release system (code-named “Cherry”)
* Or automatic update system (code-named “The automatic update system”)

It also required programming policies into the smaller parts of the system that already existed
* The build server
* The version control system
* New test servers

These systems, working together, can now answer the question: Is this feature ready for release?
Will deploying this feature likely increase or decrease the crash rate?

We now build individual features in separate branches, which are automatically tested for stability before being integrated into the mainline. That gives us confidence that we won’t slow other engineers down, and that we won’t release a low-quality build to customers.

This effort would not have been possible without the support of the excellent engineering team at Bittorrent.

I look forward to covering these in detail in later posts.

From the uTorrent engineering team, and the rest of Bittorrent as a whole, Happy torrenting!

Update on BitTorrent Chat

Abe —  December 19, 2013 — 90 Comments

Inside BitTorrent’s approach to building serverless messaging apps.

121713-bt-chat-blog-2

First, a few words on Chat’s origins. Here at BitTorrent, we value privacy. With the news this year reminding us all of the susceptibility of the communications platforms we rely on to snooping, we found ourselves wanting something new, something secure, something private. We ultimately realized that we were uniquely qualified to build this platform.

The primary weakness that we see in the available communications platforms is that they all rely on some central server to route and store all of your communication. Even if your provider can deliver industry-standard security, they cannot provide you with any kind of assurance that your communication is private. All it takes is the right (or wrong) person gaining access to your provider’s central servers, and your privacy evaporates.

Enter BitTorrent Chat. We’re building a product that allows you to talk to your friends using peer-to-peer. No central authority required.

Continue Reading…

DHT Bootstrap Update

Arvid Norberg —  December 19, 2013 — 5 Comments

Arvid Norberg, chief architect for BitTorrent, Inc, introduces a new DHT bootstrap server. This latest version introduces Node ID enforcement as an important step in our development for BitTorrent Chat. It’s also now open source so that anyone can run their own bootstrap node.

The BitTorrent Distributed Hash Table (DHT) has a fundamental dependency on being introduced to some nodes that are already in the network. There are many sources of these nodes. For instance, your client is likely to save nodes on disk to retry them when you start back up again. Any BitTorrent peers are likely to be on the DHT as well, so those are also tried. However, if you just installed a BitTorrent client, and you don’t have any BitTorrent peers, you must rely on a bootstrap server.

BitTorrent Inc. runs ``router.bittorrent.com`` on port 8991 for this purpose.

We are now providing our DHT bootstrap server open source on github. You can now run your own DHT bootstrap node! Please play with it and contribute fixes, features, and performance improvements.

The DHT bootstrapper has some interesting properties. Up until 5 years ago or so, ``router.bittorrent.com`` was running just another DHT node, just like the one in µTorrent. This had some obvious problems. Since the default routing table size is 8 nodes per bucket, half of all requests to the bootstrap would get the same 8 nodes handed back to it. At several thousand requests per second, this would effectively DDoS any poor node that happened to end up in its routing table.

We rewrote the bootstrap server to have a flat array of nodes instead and to have two cursors, one for reading and one for writing new nodes into it. Every node that pings the bootstrap server is put in a queue and pulled out 15 minutes later to be pinged. If it is still alive, it is added to the node list.

This is still the case with the latest rewrite, with one addition: Node ID enforcement. We have been looking at securing the DHT, making it harder to attack (especially with sybils). One thing we’re implementing to support this is requiring DHT nodes to calculate their node ID based on their external IP, with some flexibility to support NATs and such. More info on Node ID enforcement can be found here.

The idea is that with Node ID enforcement sybil attacks, where one machine pretends to be thousands of nodes, will become impossible.

The new bootstrap server will still serve nodes with invalid node IDs (in fact, legitimate nodes just joining are not likely to know their external IP yet). However, it will not ping nor add these nodes to the node list for handing out.

This is one step in the preparations we’re making for BitTorrent Chat, which will rely on the DHT and benefits from having a DHT that’s harder to eavesdrop and scrape.

uT Linux Server
Good news!

We’ve just updated the µTorrent Server for Linux. It’s a pretty major refresh from the last version. What’s new? Here’s the rundown.

New features:

Touch based input option for Web UI: use your tablet or mobile phone to control your torrent client in the home network
Remote.utorrent.com integration: use your tablet, mobile phone or computer to control your torrent client from anywhere on the Internet. Either visit remote.utorrent.com or use the Android µTorrent Remote application.

Big improvements:

Performance enhancements to the Torrent engine: the faster just got faster.
Improved web UI: a modern rewrite of the UI for controlling the torrent client in the home network
□ Support for signed torrents
□ Updated RSS feed parser
□ Multiple bug fixes and enhancements

Give the new version a shot, and let us know what you think. Our forums are open. All questions, ideas, and feedback are welcome.

button-free-download

–Team BitTorrent