Message-ID: <4734A4C7.1050107@ush.it>
Date: Fri, 09 Nov 2007 19:19:51 +0100
From: s4tan <s4tan@....it>
To: full-disclosure@...ts.grok.org.uk
Subject: Canonicalization issues in Flash Cross-domain
	policy file request

=========================================================================
Canonicalization issues in Flash Cross-domain policy file request    
=========================================================================

Vendor:              Adobe (http://www.adobe.com)
Software Affected:       Macromedia Flash Player
Software Version:    Flash 9.0 r31

Impact (CVSSv2 score):     medium (6.4/10, vector:
AV:N/AC:L/Au:N/C:N/I:P/A:P)

Discovered by:       Antonio "s4tan" Parata

Discovery Date:        2007-05-18
Release Date:        2007-11-09
Last Update:        2007-11-09


1. Summary
==========

>>From the adobe web site: "A policy file is a simple XML file that gives
the Flash Player permission to access data from a given domain without
displaying a security dialog. When placed on a server, it tells the
Flash Player to allow direct access to data on that server, without
prompting the user grant access".

It is possible to alterate the url of the request which gets the
cross-domain policy file.


2. Vulnerability Analysis
=========================

2.1 Overview
------------

The policy file is usually placed in the document root of the web server
with the name crossdomain.xml, unless a different path is specified.

When a request to an external url is made, first of all flash requests
the content of the policy file at the external domain, and then (if the
policy permits it) the user request is made.

By adding some special chars in the url it is possible to modify the
path of the url request of the policy file.

Consider the following simple .mxmlc file:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">

<mx:HTTPService id="request" useProxy="false"></mx:HTTPService>
<mx:TextInput id="src" x="251" y="174"/>
<mx:Button label="Send!" x="430" y="174" id="sendButton"
click="clickSendButton(event)"/>

<mx:Script>
<![CDATA[

    import flash.events.MouseEvent;
     
    private function clickSendButton(event:MouseEvent):void {
    
        request.url = src.text;    
        request.send();
    }    

]]>
</mx:Script>

</mx:Application>

You can compile it with mxmlc.

If you enter in the text area the url
http://www.somesite.com/some/path/index.php,
before the request is done Flash makes a request to /crossdomain.xml to
retrieve the cross-domain policy file. If the policy permits the
request, another request to /some/path/index.php is made.

2.2 Attack example
------------------

On Firefox (v 2.0.0.3) if you insert the following url
http://www.somesite.com?http=,
the request to the policy file will be:

GET /?http=/crossdomain.xml HTTP/1.1

so instead of the policy file you retrieve the html of the homepage.
If you insert the url http://www.somesite.com?aaa=bbb&ccc=ddd#, the
request to the policy file will be:

GET /?aa=bbb&cc=ddd HTTP/1.1

On Internet Explorer 7, we have a lot more fun. Internet Explorer
automaticaly converts \ to /.

So if we insert the following url
http://www.somesite.it\path/to/wathever/index.php?param=value&cross=,
the request to the policy file will be:

GET /path/crossdomain.xml HTTP/1.1

Then if we insert as url the following
http://www.somesite.it\path\to\wathever\index.php?aaa=bbb&ccc=, the
request to the policy file will be:

GET /path/to/wathever/index.php?aaa=bbb&ccc=/crossdomain.xml HTTP/1.1

We can arbitrarily modify the path of the request for the cross-domain
policy file.

Not only the HTTPService object is vulnerable, but also the WebService
object (as an example try the url http://www.somesite.it?wsdl=WSDL).
It is not excluded that other functions that make remote requests are
vulnerable.

2.3 What a malicious attacker can do
------------------------------------

Modifying the path of the request an attacker can perform GET requests
to an arbitrary file on the web server (he can for example exploit a
CSRF vulnerability on a third web site).


3. Acknowledgments
==================

I would like to acknowledge Alberto "icesurfer" Revelli and Stefano "wisec"
Di Paola for helping me in writing the advisory.


4. Contact
==========

Antonio "s4tan" Parata - 2007
web site: http://www.ictsc.it
mail: s4tan@...sc.it, s4tan@....it


5. Disclaimer
=============

Copyright (c) 2007 Antonio Parata

The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.

6. Revision History
===================

2007-11-09: Initial release

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists