BitTorrent Clients Can Be Made To Participate In High-Volume DoS Attacks 47
An anonymous reader writes: A group of researchers have discovered some of the most popular BitTorrent applications, including uTorrent, Mainline, and Vuze are vulnerable to a newly discovered form of distributed denial of service attack that makes it easy for a single person to bring down large sites. The weaknesses allow an attacker to insert the target's IP address instead of their own in the malicious request. To mount a Distributed Reflective DoS (DRDoS) attack, an attacker sends this malformed requests to other BitTorrent users, which then act as reflectors and amplifiers and flood the intended victim with responses.
Interesting. (Score:5, Interesting)
I've wondered several times to myself if this was possible. I figured no, since the torrent clients / seeds participate in an ACK system of sorts (or, so I've reasoned), so the sending clients would not get a return and so wouldn't keep bothering. But then, this *IS* possible to a torrent client which clicks on a carefully formed link and always was. Ever click on a link that has 40,000+ peers and/or seeds on it?
Re: (Score:1)
Ever click on a link that has 40,000+ peers and/or seeds on it?
Found links that claimed 40,000 peers and 700 seeds. Turns out there were 8 peers, no seeds, and all 9 of us were waiting for the same little bit in the middle of the rar (because for some reason it's always rar when this sort of thing happens, never loose files, and for some reason never any of the other compression formats).
Re: (Score:2)
I've never understood why people bag on rar. In fact, it is one of the few programs that I have a volume license for because it winds up on every box and general purpose VM I own.
The main reason is that it is a stable archive format. I grab a stack of multi-part archives I burned on CDs 10 years ago, and I have an excellent chance of pulling a file off. Dead CD? I just put the media in with the recovery volume, and that is only if the error correction recovery record I added (usually 5-10%) didn't cut t
Re: (Score:2)
Actually in my own tests I've gotten better ratios with winrar.
Anyways torrents that use rar format don't bother me so long as it's ONE file instead of being broken up into over 96523481256712 files. That's usually a symptom of somebody taking a usenet release and torrenting it, which by the way rar is wonderful for usenet.
Re: (Score:1)
What's the recovery ratio?
Re: (Score:1)
100%. You do keep backups, right?
Re: (Score:2)
who cares? What's the last time you got a corrupted file? Filetransfers via the internet use checksums, they are "there or not there", so you need some faulty disk. floppys had its problems, but a bitflip on a harddrive? Not that often ...
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The question I'd have is why anyone who really wants to DoS a target would bother doing it this way. It would be far easier to upload a popular torrent with malware attached (hide it in a cracked .exe or something else that people would expect to show up as a false positive on a virus scanner as many cracked .exes tend to) and then use the resulting botnet to DoS a target. By the time someone finds out that the torrent contains malware, you've probably already got a sizeable botnet and have your goal accomp
Re: (Score:2)
I avoid using shady sources (torrent or otherwise) for executables, but I'm nowhere near as choosy when it comes to media files. I'm willing to run the risk that the file is actually Madonna yelling "what the fuck do you think you're doing?". (I didn't have a problem with it when she did that, it's just trolling.) I don't think I'm particularly unusual in this respect, either.
Spoofed Source IP (Score:2, Insightful)
Just another spoofed source IP address attack.
No one's ever seen that before.
Re: (Score:2, Interesting)
God forbid anyone do any sort of egress filtering on their end-user networks to make sure that any packets leaving it, claim to come from it.
You'd think this would have been solved aeons ago, what with ISPs cutting costs and refusing to upgrade infrastructure. Cutting off DOS attacks before they head out onto the upstream backbone that they've got to pay for seems like a no-brainer.
Re: (Score:2)
This has been a "best practice" for decades, and yet, many BIG NAME ISPs cannot be bothered to do it.
We shall call it... (Score:2)
Since this is basically a smurf attack through a different protocol, I think we should call it a "snork attack".
Re: (Score:2)
Exactly. I was reading research papers about similar DDoS attacks using unwitting BitTorrent clients back in 2007 and 2008. Not sure why this is noteworthy, since there were several different attacks back then that could be used to publish false IP addresses to the distributed hash table (DHT) as being sources for particular packets from the torrent, such that peers looking for that packet would try to repeatedly contact a server that wasn't even a part of the torrent swarm. There were also a variety of tec
Relatively Common Attack (Score:1)
I've seen this a few times against networks that I managed in the past couple years. Some of it is also due to root server DNS poisoning in China directing torrent clients to my web servers instead of "thepiratebay.org" which can cause a decent amount of amplification. It's easy enough to mitigate if you take a look at the HTTP communications coming in, because they definitely don't look right.
Could this lead to false sharing allegations? (Score:5, Interesting)
Re: (Score:1)
We all know BitTorrent is only for hackers, god forbid they are also running Linux.
Re: (Score:2)
https://wiki.theory.org/BitTor... [theory.org] is the protocol that has problems in it. the bit-torrent protocol
The things IP owners use to track people are DHT and public trackers which are an entirely different thing used only for discovery of peers.
Theoretically they should be spoofable too, using very similar technics(they too are built on top of udp(mostly)), but it's not related to this.
Re: (Score:3)
This Attack Vector Needs A Badass Name (Score:2)
Kind of analogous to a synchrotron for weaponized data...or wait, here's a good one: Focused Binary Multiplicative Scalar Informational Superfluity Generator. Torrentpedo? Rickroll of Damocles? These are all terrible.
Re: (Score:2)
Bit-gate
Re: (Score:2)
HiveChucker. Because it's a lot like throwing a beehive at somebody. Without knowing any better, a swarm attacks an innocent target.
Not to be confused with DR-DOS (Score:2)
BitTorrent and high-volume DoS attacks .. (Score:2)
use TCP with new type of internal QoS (Score:2)
The problem seems to be that uTP, which uses UDP instead of TCP, was created because when torrents used TCP, they had the same priority as TCP packets for things like web browsing. Going back to TCP would seem to ameliorate at least one form of attack mentioned. Why reinvent the wheel by enhancing uTP to the point where its virtually indistinguishable from TCP when the priority problem can be solved another way?
How about an "internal" QoS parameter, set as a socket option call, that sets a QoS within a gi
Re: (Score:2)
I do not have this problem and there are at least two ways to solve it:
The uTP protocol includes monitoring of the connection latency and is suppose to throttle itself if latency becomes excessive. Maybe this is set wrong on your bittorrent client.
Using a traffic shaper will also fix this problem.
Happened to me (Score:3)
In March, of this year, that's exactly what happened to my servers. It took a few hours to narrow down the traffic logs to find the excess load, and then it became quite obvious, based on the user agent, that it was nothing more than a bittorrent swarm.
The nice part is that it's easily blocked by user-agent -- which isn't something that the original attacker can control.