Overview
As part of an ongoing investigation on Adobe Flash SOP bypass techniques, we identified a vulnerability affecting old releases of the Adobe Flex SDK compiler. Further investigation traced the issue back to a known vulnerability (CVE-2011-2461), already patched by Adobe in apsb11-25.
Old vulnerability, bad luck, let's move on. Not this time.
The particularity of CVE-2011-2461 is that vulnerable Flex applications have to be recompiled or patched; even with the most recent Flash player, vulnerable Flex applications can be exploited. As long as the SWF file was compiled with a vulnerable Flex SDK, attackers can still use this vulnerability against the latest web browsers and Flash plugin.
As soon as we understood the potential risk, we conducted a large-scale analysis by locating SWFs hosted on popular websites and analyzing those files with a custom tool capable of detecting vulnerable code patterns. This research has led to the identification of numerous websites vulnerable to CVE-2011-2461, including 3 sites out of the Alexa Top 10.
Disclosure
We're back to the hotel after another amazing day at Troopers 2015, where we presented the results of our research. The information provided in this blog post, together with the slides of the conference (download from here), should be sufficient to detect and mitigate the risk. As soon as we feel that there is a general understanding of this flaw we will be publishing more details, including a real exploitation scenario.
Download the tool from https://github.com/ikkisoft/ParrotNG/
To use the command-line version, simply execute the following:
There are still many more websites that are hosting vulnerable SWF files out there. Please help us making the Internet a safer place by reporting vulnerable files to the respective website's owners.
After having identified all Flex SWF files compiled with a vulnerable version of the Adobe Flex SDK, there are three possibilities:
During the past months, we've done our best to privately disclose this issue to some of the largest websites, but we won't be able to reach a broader audience without publicly releasing the technical details. As suggested by the many vulnerable applications that we've encountered, it is clear that CVE-2011-2461 did not raise the adequate level of attention back in 2011. By explaining the potential impact and releasing a tool capable of identifying vulnerable SWF files, we hope to contribute towards eradicating this issue.
Impact
This vulnerability allows attackers to steal victims' data (via Same-Origin Request Forgery), or perform actions on behalf of the victim (via Cross-Site Request Forgery), by asking them to visit a malicious web page. Practically speaking, it is possible to force the affected Flash movies to perform Same-Origin requests and return the responses back to the attacker. Since HTTP requests contain cookies and are issued from the victim’s domain, HTTP responses may contain private information including anti-CSRF tokens and user's data.
Summarizing, hosting vulnerable SWF files leads to an "indirect" Same-Origin-Policy bypass in fully patched web browsers and plugins.
In practice, Flex applications compiled with SDK >= 3 support the following resource loading mechanism:
In Adobe Flex SDK between 3.x and 4.5.1, compiled SWF files do not properly validate the security domain of the resource module, leading to Same-Origin requests and potentially Flash XSS (in older versions of the Flash player). A detailed root cause analysis is included in our slides deck.
Vulnerable Component
Starting from Flex version 3, Adobe introduced runtime localizations. A new component in the Flex framework — the ResourceManager — allows access to localized resources at runtime. Any components that extend UIComponent, Formatter, or Validator have a ResourceManager property, which allows the SWF file to access the singleton instance of the resource manager. By using this new functionality, users can pass localization resources via a resourceModuleURLs FlashVar, instead of embedding all resources within the main SWF.In practice, Flex applications compiled with SDK >= 3 support the following resource loading mechanism:
In Adobe Flex SDK between 3.x and 4.5.1, compiled SWF files do not properly validate the security domain of the resource module, leading to Same-Origin requests and potentially Flash XSS (in older versions of the Flash player). A detailed root cause analysis is included in our slides deck.
Identifying vulnerable SWF files with ParrotNG
ParrotNG is a Java-based tool for automatically identifying vulnerable SWF files, built on top of swfdump. One JAR, two flavors: command line tool and Burp Pro Passive Scanner Plugin.Download the tool from https://github.com/ikkisoft/ParrotNG/
ParrotNG Burp Pro Plugin
ParrotNG Command Line
To use the command-line version, simply execute the following:$ java -jar parrotng_v0.2.jar <SWF File | Directory>To use ParrotNG Burp Pro Plugin, load parrotng_v0.2.jar from Burp's Extender Tab-->Add as a standard Java extension. With Passive Scanner enabled, all SWF files passing through Burp Suite are automatically analyzed. For more details, please refer to Burp's official documentation.
There are still many more websites that are hosting vulnerable SWF files out there. Please help us making the Internet a safer place by reporting vulnerable files to the respective website's owners.
Mitigations
- Recompile them with the latest Apache Flex SDK, including static libraries;
- Patch them with the official Adobe patch tool, as illustrated here. This seems to be sufficiently reliable, at least in our experience;
- Delete them, if not used anymore.
Brought to you by Mauro Gentile (@sneak_) & Luca Carettoni (@_ikki)
