Slashdot Mirror
BitTorrent Clients Can Be Made To Participate In High-Volume DoS Attacks
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.
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?
...Steve
Just another spoofed source IP address attack.
No one's ever seen that before.
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.
Given media companies chasing people for illegal sharing on the basis the very lists that this exploit is manipulating I guess this could lead to false allegations of file sharing? I guess it could be used in countries like New Zealand to have victims force disconnected by their ISP for multiple instances of file sharing when they had in fact never shared anything?
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.
Am I the only one who immediately thought of DR-DOS, which was for a time the best and most useful version of DOS out there? Nostalgia, thine name is the BBS days. - HEX
Horror & SciFi Erotic Nudes
I would have thought all this lone DDOS attacker need was all those compromised Microsoft Windows computers out there on the Internet.
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 given system/node for the given socket, but is not the classic QoS packet parameter? That is, a web browser sets a lower QoS for its download manager so that a lengthy download doesn't slow down new http/html traffic. The OS's network stack layer uses this to prioritize requests, but this is purely internal (e.g. no packet gets a QoS value). In other words, it's not a protocol extension, just an OS network stack enhancement.
I've had cases where I'm downloading a lot of stuff (either in the browser's download manager or something external like fedora's yum reposync) and foreground web browsing slows to a crawl.
This is more akin to lowering a process scheduling priority below "normal". I use this if I'm running a heavy compute job in the background, but I still want my web browser, email, editor, etc. to have reasonable responsiveness.
The most efficient way to implement this would be through a socket option, which would require a kernel change.
Linux has a cgroup for something similar (/sys/fs/cgroup/net_prio) but creating a subdir under this and attaching a process to it usually requires root access. It's baroque. I tried to use the cgroup fs to implement a limit on a process resident set size because the syscall for RLIMIT_RSS isn't connected to anything. I got it to work, but the mechanism was far more complex than the equivalent for lowering process priority via setpriority. Hence, the "clean" solution for socket/connection priority would be a socket option.
Applications could do this with minimal system support by getting stats on all connections (e.g. via netstat, etc.), calculating what their load is, and throttling themselves if they see they're using more than X percentage of the current total usage. Torrent clients already have this (e.g. one can set a parameter that limits the upstream bitrate used by a given torrent). But, there is no global limit or mechanism that says "How much bandwidth am I hogging?" and do a backoff.
Like a good neighbor, fsck is there
Since this is basically a smurf attack through a different protocol, I think we should call it a "snork attack".
Maybe we deserve this world ?
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.