hola,

bug- flash cross domain policy

A cross-domain policy file ("crossdomain.xml" in Flash and "clientaccesspolicy.xml"

in Silverlight) defines a list of domains from which a server is allowed to make
cross-domain requests. When making a cross-domain request, the Flash or Silverlight
client will first look for the policy file on the target server. If it is found,
and the domain hosting the application is explicitly allowed to make requests, the
request is made.
Therefore, if a cross-domain policy file includes domains that should not be
trusted, such as when using wildcards, then the application could be attacked by
these untrusted domains.
An overly permissive policy file allows many of the same attacks seen in Cross-Site
Scripting (CWE-79). Once the user has executed a malicious Flash or Silverlight
application, they are vulnerable to a variety of attacks. The attacker could
transfer private information, such as cookies that may include session information,
from the victim's machine to the attacker. The attacker could send malicious
requests to a web site on behalf of the victim, which could be especially dangerous
to the site if the victim has administrator privileges to manage that site.
In many cases, the attack can be launched without the victim even being aware of
it.

The application publishes a Flash cross-domain policy which uses a wildcard to

specify allowed domains. Using a wildcard to specify allowed domains means that any
domain matching the wildcard expression can perform two-way interaction with this
application. You should only use this policy if you fully trust every possible web
site that may reside on a domain which matches the wildcard expression.

The Flash cross-domain policy controls whether Flash client components running on
other domains can perform two-way interaction with the domain that publishes the
policy. If another domain is allowed by the policy, then that domain can
potentially attack users of the application. If a user is logged in to the
application, and visits a domain allowed by the policy, then any malicious content
running on that domain can potentially gain full access to the application within
the security context of the logged in user.
Even if an allowed domain is not overtly malicious in itself, security
vulnerabilities within that domain could potentially be leveraged by a third-party
attacker to exploit the trust relationship and attack the application that allows
access. Any domains that are allowed by the Flash cross-domain policy should be
reviewed to determine whether it is appropriate for the application to fully trust
both their intentions and security posture.
Any inappropriate entries in the Flash cross-domain policy file should be removed.

step to reproduce

request

GET /crossdomain.xml HTTP/1.1

Host: admin.foxycart.com
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:78.0) Gecko/20100101
Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Cookie: PHPSESSID=uu4p4nsjl1ncksurlttdf526a0;
csrf_token=8ourOMPsTjFsqhOgqS4xZHV4n3kHrK7PSlJeaNYsPyI%3D;
optimizelyEndUserId=oeu1595152425693r0.3228238258062298; optimizelySegments=%7B
%22234346863%22%3A%22direct%22%2C%22234587425%22%3A%22false%22%2C%22234696064%22%3A
%22ff%22%7D; optimizelyBuckets=%7B%7D; optimizelyPendingLogEvents=%5B%5D;
__utma=91412365.448719536.1595152427.1595152427.1595152427.1;
__utmb=91412365.1.10.1595152427; __utmc=91412365;
__utmz=91412365.1595152427.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
__utmt=1; foxyio-_zldp=QOZUuxNcWyxo5jIXrhVjVSmZVon0ahW31DfDE9AH
%2F5%2B0qAL4THkNwf2s3jrCYykDodoRkLyJC2Y%3D; foxyio-_zldt=32f26e6f-3894-4454-a22e-
961d7e4e5629
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

response

HTTP/1.1 200 OK
Date: Sun, 19 Jul 2020 10:10:04 GMT
Content-Type: text/xml
Connection: close
Server: nginx
Last-Modified: Thu, 27 Aug 2015 22:17:13 GMT
Content-Length: 112

<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*.foxycart.com" />
</cross-domain-policy>

POC
These cross-domain policy files mean to allow Flash and Silverlight applications
hosted on other domains to access its data:

Flash crossdomain.xml (XML)

<cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFile.xsd">
<allow-access-from domain="*.example.com"/>
<allow-access-from domain="*"/>
</cross-domain-policy>

Silverlight clientaccesspolicy.xml

<?xml version="1.0" encoding="utf-8"?>

<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="SOAPAction">
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
These entries are far too permissive, allowing any Flash or Silverlight application
to send requests. A malicious application hosted on any other web site will be able
to send requests on behalf of any user tricked into executing it.

impact
An attacker may be able to bypass the web browser's same-origin policy. An attacker
can exploit the weakness to manipulate or steal cookies, create requests that can
be mistaken for those of a valid user, compromise confidential information, or
execute malicious code on the end user systems for a variety of nefarious purposes.
Other damaging attacks include the disclosure of end user files, installation of
Trojan horse programs, redirecting the user to some other page or site, running
ActiveX controls (under Microsoft Internet Explorer) from sites that a user
perceives as trustworthy, and modifying presentation of content.