Paid Advertising
web application security lab

Subversive JS for FileSharing

It’s been a long week but it’s not for naught. Lots to talk about, but not a lot of time to write it all. So let’s start with something I’ve been toying with for the last few days. Dan Kaminksy is one of those guys who is always looking for ways to build bit torrent with whatever technologies are available. It suddenly occurred to me that it’s actually possible under some very specific circumstances with existing technologies and a little trickery to use someone’s browser as a seeder in a convoluted scenario where you need to transfer a file to many people at the same time but bandwidth is at a premium.

So, welcome to building subversive file sharing with client side applications. The first question id asked me was if I was going to build it and speak about it at Blackhat or something. The answer is emphatically no way. It would take quite a bit of work to build it in any sort of reliable way (it’s not above the readers of this site, I’m sure, but it’s well outside of the time I have to devote to something like this). Anyway, in case anyone was wondering, yes, you can build file sharing in JavaScript. Painful, yes, but definitely possible.

8 Responses to “Subversive JS for FileSharing”

  1. EWSec Says:

    Ok, so the main problem here is that the roles of sharing “server” and “client” are reversed. The logistics of partial data requests from “servers” demand that one client asks from many servers. Here we have one server (basically Cathy, hijacked by Alice), and many clients that require the data.

    The only way I can see it done is that after each package sent from Alice through Cathy, Bob and Zack update Alice with new ranges they require. Alice then sends new range through another or same (but on next request) victim.

    How efficient is this? Especially with larger files considered. Teh number of hijacked Cathys would have to be substantial.

  2. RSnake Says:

    @EWSec - I know - pretty complex topic, and yes, they would have to update Alice with the next chunks required, either through Cathy as a proxy or directly. I doubt it is efficient at _all_ in reality as compared to normal file sharing, but I do believe it would be possible under certain circumstances to substantially abuse Cathy. Pretty fun to think about anyway.

    And yes, the more Cathys the better!

  3. EWSec Says:

    In light of that… I wonder if there’s a /dev/null kind of server on the net that will simply accept all POSTed input, no questions asked. :)

    Although, technically, webservers usually accept everything sent via POST protocol, leaving to the application to deal with it. So a list of sites that accept large POSTed content can be used to abuse Cathy.

    Gah! Yet another DDoS vector revealed…

  4. RSnake Says:

    Maaaybe - I would think smaller chunks would be better though, because it would reduce the chance of total failure (quite a bit more error checking involved, but I think that’s not a terrible price to pay). A few megs at a time seems like a pretty decent sized chunk to be dealing with. That way you don’t have to wait for a four gig DVD to be uploaded through Cathy’s connection, just many small chunks. And if she surfs away, no big deal, you can just use another Cathy to pick up the next set of chunks of the file, and so on….

    That’s the theory anyway. I’d be interested to see it built.

  5. Wladimir Palant Says:

    Quite an interesting idea. Given that Bob doesn’t really have to run a web server but can use a simple Perl script for example - it could be made an application very similar to BitTorrent. Difference: leechers need a publicly accessible port that a seeder can connect to (meaning either no NAT or port forwarding), and we have more management tasks on the tracker (though some of it might be pushed out to the seeder).

    The system actually wouldn’t be too hard to build. You can even make the leecher redirect back to the tracker after processing the request - this will allow seeder’s client-side code to get some status information and maybe start another transmission without being commanded by the tracker.

  6. n00k Says:

    I’ve developed such an application that utilizes the browser to share files. It’s still in a pretty early state, but it does what it should. Those who are curious now, have a look at

  7. RSnake Says:

    @n00k, how incredibly cool! I’m actually really glad someone went ahead and built it. Like you said, Xdomain XHR will definitely lend a hand here, but you may be able to piggy back off of Flash’s crossdomain.xml stuff in the mean time if you don’t like the blind post version. Anyway, very cool!

  8. n00k Says:

    Yeah, I tried to start off with flash in the first place. But soon I realized I would have to learn how to develope with haxe and since I didn’t want to do everything in flash, the communication between javascript and flash seemed to be quite complicated, at least from javascript to flash, if I remember correctly. Then after some time this lay broke I just thought, why not do it completely in javascript :)