1304714 - Same-origin policy bypass via Flash on partners.mozilla.org & events.mozilla.org

Status: RESOLVED FIXED

(Websites :: Other, defect)

Description

[arneswinnen]

Attachment: https://partners.mozilla.org/crossdomain.xml

The crossdomain.xml file in the root of the two affected domains contains a wildcard, effectively bypassing the normal same-origin policy implemented in browsers via Flash, as they have their own implementation based on the crossdomain.xml file instead. This is a serious issue, since these two domains contain authenticated zones. The files are equal for both affected domains and designate wildcard "*" as origin domains who can access their (authenticated) content (see also screenshots):

<cross-domain-policy>
<allow-access-from domain="*" to-ports="80,443,8100,8080"/>
<allow-http-request-headers-from domain="*" headers="SOAPAction,Authorization"/>
</cross-domain-policy>

The attack scenario is as follows: A victim logs in to one of these two domains, and then visits a website of the attacker in another browser tab. At that moment, the attacker can stealthily load an SWF file which will make hidden requests to the affected domains, and the browser will happily add session cookies to these requests. Now, the difference with a normal SOP implementation in the browser is that the attacker will actually be able to read the response of the requests made via the SWF file via a Flash-JavaScript bridge, which normally is prevented by the same-origin policy implemented in all modern browsers (including yours :-). The attacker can use this ability to read all authenticated content of the affected domains, and hence to both steal sensitive PII data from the authenticated victim, as well as to steal CSRF tokens from within the HTML pages. Thus, this issue also implies a global CSRF bypass for these websites through this vulnerability by design. Here's a step-by-step to reproduce the issue:

1. Browse to partners.mozilla.org and login
2. Open a second browser tab and browse to https://thehackerblog.com/crossdomain/index.html (great PoC made by Matthew Bryant (mandatory), not me!)
3. Enter https://bugzilla.mozilla.org/ as Target URL and hit the execute button. This should result in a "securityErrorHandler:" response, indicating that bugzilla.mozilla.org is not vulnerable to the issue.
4. Enter any page on partners.mozilla.org as Target URL, e.g. https://partners.mozilla.org/, and hit the execute button. Now, the response window on the right should show the HTML of the landing page. If interested, one could also put an intercepting proxy between the browser and the server to see that the SWF on thehackerblog.com actually makes a request to partners.mozilla.org, and that session cookies are transparently added by the browser. 

Of course, in a real attack, the attacker would not fetch the landing page, but pages containing sensitive data on partners.mozilla.org / events.mozilla.org, such as profile pages. However, I couldn't find a quick way to make myself a test partners account, so that's why I chose for this PoC instead. Additionally, the PoC SWF used here still requires to enter Target URIs, but there are more stealthier SWFs from the same person who allow to perform this stealthily via JavaScript: https://github.com/mandatoryprogrammer/FlashHTTPRequest

Recommendation: Remove the wildcard from the crossdomain.xml file in the root of the two affected subdomains, either completely or by a strict whitelist.

Regards,

Arne

Comment 1

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Verified the contents of crossdomain.xml's...

https://partners.mozilla.org/crossdomain.xml

<cross-domain-policy><allow-access-from domain="*" to-ports="80,443,8100,8080"/><allow-http-request-headers-from domain="*" headers="SOAPAction,Authorization"/></cross-domain-policy>

https://events.mozilla.org/crossdomain.xml

<cross-domain-policy><allow-access-from domain="*" to-ports="80,443,8100,8080"/><allow-http-request-headers-from domain="*" headers="SOAPAction,Authorization"/></cross-domain-policy>

Comment 2

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Reference: http://gursevkalra.blogspot.com/2013/08/bypassing-same-origin-policy-with-flash.html

Comment 3

[arneswinnen]

Hi,

I noticed you designated this as sec-low, which surprised me a bit. However, I don't really know the affected domains and their userbase, but just to make sure that we're on the same page here: Would an XSS/CSRF vulnerability on the authenticated zone of these domains also been designated as sec-low? The impact from this vulnerability is very similar: Confidentiality (sensitive data theft, e.g. via XSS) and Integrity (CSRF bypass, e.g. via CSRF token theft) are both compromised completely.

Cheers,

Arne
https://www.arneswinnen.net

PS: Here's another good reference on the crossdomain.xml subject, of the author of the SWF POC tool himself: https://thehackerblog.com/crossdomain-xml-proof-of-concept-tool/index.html

Comment 4

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

I'm looking into what is exactly on these sites, if it turns out to be more critical than at first glance I'll up the rating.

Comment 5

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Spoke to liz via IRC, she said Ty is the new admin for these.

Comment 6

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Ty: can you have a peek at this issue? I don't have credentials on this site, so it's hard to understand impact for context.

Comment 7

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Caught up with Ty on IRC to understand the context better...

partners.mozilla.org
- Site is externally hosted with a vendor NetX, used for images/artwork delivery for partners
- We believe the site is mostly inactive at this time
- Ty is double checking to make sure before we request the DNS be pulled
- Auth is local auth only (so we don't expect any pivoting risk here if a cred was snagged)

events.mozilla.org
- Site is externally hosted with a vendor NetX, used for images/artwork delivery
- It's possible it's inactive, but that is less clear than partners
- Ty is double checking to see if we can just decom it
- Auth is anonymous by default

Now knowing the above, I think the severity level of sec-low is still appropriate.

Comment 8

[arneswinnen]

Fully agreed - I didn't have any context, was hoping for a real juicy partner portal, full of PII and financial data of course :-). Thanks for investigating, much appreciated.

Arne

Comment 9

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Arne: thanks for all the submission, anytime we can identify a site that exists that is no longer being used, it's a big win (one less thing to secure).  Appreciated!

Comment 10

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Ty is having some auth issues right now, but asked me to make note that he's reached out to the vendor and asked them to remove the crossdomain.xml references.

Comment 11

[April King [:April]]

I'm marking this as sec-bounty-, due to a combination of its low impact, being a 3rd party site and not on our bug bounty list.

Nevertheless, thank you for reporting this to us, as always.  We really appreciate it, Arne!

Comment 12

[April King [:April]]

It appears that, at least at some point after this was filed, they removed these files.