Slashdot Mirror
Ratio Vulnerability in BitTorrent Discovered
An anonymous reader writes "The "vulnerability" has been tested on all the major torrent trackers that use the torrentbits source code. The idea is that you will sniff your torrent info using the HTTP Analyzer and with Firefox you will update your stats to the tracker being identified as a client."
http://xyflar.blogspot.com.nyud.net:8090/
indeed, and in fact this "vulnerability" was always a well known flaw in any of the groups that run trackers i've been involved with. Saw someone exploiting it a good 8-9 months ago.
Seriously, I thought this was already widely known. All info from the client to the tracker is sent with basic HTTP GET requests. You could fake your ratio with a simple php script. Well, maybe even by just typing the info in your web browser, however I think the urlencoding would be a problem.
This is not a vulnerability .. it's by design.
The statistics reported to the tracker by the client were never meant to be used for things like enforcing ratios because they TRUST THE CLIENT. But there's simply no other way to collect statistics such as amount uploaded.. if the client lies to you (which is what this "vulerability" is exposing), there is little you can do to protect yourself.
It's TRIVIAL (a 1 line change, or if you want to make it a parameter, a 4 line change) to modify any python open source client such that it 'amplifies' the ammount you upload by 10x or 100x. Then you don't need to do any HTTP sniffing, your client can just lie for you.
Now, there is a way to block this author's method because he doesn't amplify the upload, he creates a step-change in the upload ammount (which can be caught on the server side.. if it's been the same ammount of time since the last check-in, but suddenly his cumulative upload ammounts tripled, you're likely being abused). However, using my 'amplifying' trick from above, this is much trickier to detect. Perhaps you measure the client's upload speed on the website and record it to the database, maybe even double it just to be safe.. so you KNOW this client can only do 60 k/sec or whatever. Then when the client reports in stats, you take the time since the last check-in and you calculate his approxomate 'instantenous' rate. If this rate is higher then the upload rate you previously decided was this client's ceiling, then he's lying to you.
The above method is not foolproof, but it would likely be better then the nothing we have now. It was really only a matter of time this surfaced.. and I'm amazed it took this long.
--kRYPT
(author of burst! and MakeTorrent)
DJ kRYPT's Free MP3s!
So please grow up and contribute to torrent communities, it's not difficult and it makes everything work better in the end.
This is nothing new, there's been client hacks for this for quite a while (http://www.00de.com/), there's also been ratio faking programs out for quite a while as well. So I really dont see anything additional that this 'xyflar' guy has added besides posting what's been known to pretty much every torrent user as well as pretty much every torrent site that uses ratios.
Your hair look like poop, Bob! - Wanker.
Anyone who has even so much as glanced at the protocol specification can see that the client is trusted to return an accurate count for how much it has uploaded. This wasn't a "disclosure" or a "vulnerability announcement"- it was a statement of the patently obvious.
The problem is not with BitTorrent. The problem is with BitTorrent trackers and sites which trust that value returned by the client. There are dozens of open-source clients, including the original- and all it takes is adding one operation that multiplies the real upload by whatever number you desire.
The functionality of BitTorrent depends on clients seeding copies of the file back into the network after having downloaded, and a vulnerability like this in a significant amount of trackers could easily cause serious damage to the operation of many torrents.
How did this pseudo-intellectual first-post get modded insightful? You clearly don't understand how the BitTorrent network is designed. Clients evaluate only how much data they receive directly from another client, and how fast. Nothing else factors into their decisions of who to upload. There is absolutely NO mechanism for the client to query the server to see how much you've uploaded, nor is there even a way to ask other clients. Why? Because both sources would be unreliable. Each client CAN only rely on direct "experience", unless they're engaging in a reputation system of their own hacking- if they are, best of luck to them, Bram wasn't an idiot for not trying that.
The "vulnerability" only affects trackers which "enforce" an upload ratio, and only to the extent of letting people bypass that ratio. Ratios is a concept that is pretty stupid with BitTorrent. The more you push back, the more you get, unless there is plenty of bandwidth. About the only "benefit" I see to ratios is that it might keep files available with seeds longer.
I hear a lot of crying about leechers on BitTorrent, but the network is self-regulating. Don't upload? You won't get much back. I think the perceived problem is also because reporting of the stats is unreliable- in the case of Azureus, for example, I can download a big file, upload 3x as much, and then if I get a connection error when my client stops, I "loose" all that uploading. I then look like a leecher, when it is exactly the opposite.
Please help metamoderate.
This only effects sites that use ratios for things like "VIP Status" or Auto-Bans, without hacking the client as well you wont be able to fool the other clients to send you data if you dont send them data.
Your hair look like poop, Bob! - Wanker.
I've been using Bittornado and Rufus for some time now, and with both, I get away with uploading at 3KBps and downloading as fast as I can manage. I have ADSL, so this means about 60KBps short of my 180KBps upper limit for downloading. But I've been known to download at 180KBps. (It's not that I'm a prick by nature, it's just that with my connection, I can only upload at around 12KBps, and the faster I upload, the slower I download.)
News for merdes. Shit that matters.
Ask me about my sig.
This kind of thing has been known for a long, long time now, though usually it's modified clients that simply lie about their stats, rather than some convoluted protocol sniffing thing. Many torrent sites that care about their ratios already check for obviously spoofed values.
If I have been able to see further than others, it is because I bought a pair of binoculars.
No, it wouldn't. The only thing this has any effects on, are tracker stats.
Bittorrent clients upload to who uploads most to them. And then they add a certain amount of randomness so that they get to try different peers. They don't care about the stats from the tracker, and neither should they, as they can be easily forged anyway (just change a line in your favourite bittorrent client and recompile).
If the bittorrent protocol was so brittle as to care about easily forged information, it would never have worked as open source software anyway.
So why do people care about trackers stats? Well, some people like to publish them (e.g. to make leechers ashamed). Some are nazis, and want to block leechers from their trackers. And some go beyond nazis, and want to block multi-tracker clients, etc, because it disturbs their tracker stats. This "vulnerability" is only a vulnerability to the two last groups...
I've always thought that the best way for the MPAA/RIAA to kill bittorrent would be to break the protocol such that cheaters could leach without giving much back.
If you look at other systems where the amount leechers far outstrip people giving back the system pretty much gets bogged down.
Bram had always said his system works because every client is out for it's own interest. Researchers who have tried to "improve" BT usually have done something to break this model.
If I were the RIAA/MPAA I'd hire a bunch of crack programmers to try and create a "cheat" and then release the source code to that people would get to download with little or no uploading. That would effetively KILL many bittorrent swarms
This cheat DOES work... but it's rather suspicious to the admins when you do it. Like a thirty-second leap from a terrible download-upload ratio to a godlike ratio won't go unnoticed... That said, I had no problem TESTING it, but I contacted the admins of my favorite tracker and told them what I did, why, and got them to reverse it. They'll be watching for it now and banning anyone who tries it.
use it on boxtorrents and we will ban your entire ISP for a month. we know about it, we know how to monitor for it.
It's very easy to detect cheating in a swarm. If a client reports that it's uploaded ten megabytes, but the remainder of the swarm has only downloaded one megabyte, there's obviously something askew. Of course, not everybody will get their stats counted accurately, due to disconnection and tracker outages, but things should average out reasonably (*). If these community-based ratio-monitoring sites simply count the number of times a given member is part of a swarm with a mismatched overall upload:download ratio, greedy leechers will be identified quickly. Can I recommend the paper "How to cheat BitTorrent, and why nobody does"? It's a lot older than this article. http://www.cs.unibo.it/pub/TR/UBLCS/2005/2005-12.p df
(*) Obviously I've never measured this or anything :)
This isn't a vulnerability; it's simply the way the protocol works. It doesn't take a client to act like one and send syntacically correct requests to a tracker. (In fact, that's how I test tracker code... with telnet and/or nc)
I will warning those wanting to "cheat" using this method... if you follow his instructions to the letter, you will be detectable like a road flare in a movie theater. (if anyone is actually looking.)
Mod this tripe down! This has been covered several times throughout this discussion. The only thing this affects are a set of numbers which have absolutely nothing to do with the functionality of the protocol itself.
I'll turn into a supernova and burn up everything. Well I'll turn into a black little hole and you'll turn into string.
For example, here in New Zealand, the fastest speed you can get is 2mbps ADSL, and depending on the plan you choose, when you hit 10GB of traffic (that's traffic in both directions added together), you either start paying excessive data charges designed to be so high as to force you to stop, or your bandwidth is reduced to 64kbps.
The latter option is obviously the one that the huge majority choose, and to the uninitiated, 64kbps seems like not such a bad idea. The problem is that the ISP acheives 64kbps by heavily dropping packets, and that results in much much worse performance than you would have got with a dialup modem connection.
I, for example, would be happy to leave BT running 24/7, seeding files, but I simply can't afford to do that, because at 2mbps, I can chew up 10GB in just 11 hours (actually less, because you have to include transmitted traffic too), and unless I want to have unusable internet access for the remaining 30.5 days of the month, I have to strictly control the amount of traffic I transmit and receive.