Adopt OSS. A new initiative by OWASP Italy.

NibbleSec blog is a place for neat vulnerabilities, new security research and (hopefully) food for thought. In today's post, I want to take the opportunity to promote a new initiative by OWASP Italy.


Adopt OSS

In the wake of the Snowden revelations and recent OpenSSL vulnerabilities, ensuring the security of the technology that powers our daily life is vital for individuals’ security and privacy on the Internet. Despite the collaborative and transparent nature of open source software, security flaws are still frequently discovered in popular applications.

Given OWASP’s mission to help organizations with application security, the Italian Chapter of OWASP has established a new initiative to provide free, voluntary based support to open source software projectsBy building together open, free and secure systems, we can promote innovation and help building better software, resilient to modern threats.

Thanks to Adopt OSS​, security enthusiasts are paired with participating open source projects, thus gaining exposure to real-­life security engineering challenges and the opportunity for career growth. In turn, the participating projects are able to obtain free professional expertise to better improve their security posture, and ultimately build secure software. Examples of activities include, but are not limited to, thread modeling, performing security assessments, testing security patches, writing documentation on security topics, improving SDLC and vulnerability disclosure practices.

Over a six months period​, OWASP Italy will facilitate the effort by coordinating the initiative and
providing support when needed. The first edition of this initiative will take place between May and November 2015. At the end of the six months period, OWASP Italy will publish results and feedback from both volunteers and OSS maintainers.

Many OpenSource projects need help, and hopefully more security enthusiasts will contribute and create similar initiatives. If you have time to complain about something, then you have the time to do something about it.

CVE-2011-2461 is back - FAQ

After our presentation at Troopers 2015, we have received numerous replies in the form of comments on SlashdotReddit or emails. In this post, we want to provide more details and clarify some points.

Q: What's the exploit vector here?
A: We've now released all details of an actual attack flow. Please refer to the "Exploiting CVE-2011-2461 on Google.com" blog post to understand the nature of the attack. This should give sufficient technical details on how this vulnerability can be exploited.

Q: Patching all vulnerable SWF files isn't a realistic solution, is it?
A: Unless Adobe introduces an additional check in the player, we don't have many options.

Q: Why doesn't Adobe patch the Flash player?
A: The bug affects Adobe (now Apache) Flex SDK. As a result, it was properly corrected in the compiler. Having said that, Adobe could probably implement a check in the Flash player itself in order to mitigate this issue. Considering that vulnerable SWF files need to be recompiled or patched, it would be beneficial to have a solution that can be easily deployed by Internet users.

Q: I'd love to patch my hazardous SWF files, but the link on Adobe website goes to an error 404. Where can I find this file?
A: Fail. We notified Adobe last week and they have now restored the tool page. Last time we checked, the official patch tool was available for download. Alternatively, it is possible to recompile the entire SWF with a new version of the Flex SDK.


Q: Can you publish more details around the number of vulnerable sites/files?
A: Considering that we've enumerated all SWF files using search engine results only, our numbers may not be accurate and are certainly influenced by numerous factors. As mentioned, 3 out of the Top 10 Alexa sites were hosting at least one vulnerable SWF file. We're interested in collecting metrics around this bug, so please let us know if you have performed extensive scans using ParrotNG.

Q: Where can I find a vulnerable SWF file to test my detection tool?
A: We've created a vulnerable HelloWorld Flex app compiled with an old version of the Flex SDK. You can download the SWF test cases archive, which includes a vulnerable and a non-vulnerable version of the same file.

Brought to you by Mauro Gentile (@sneak_) & Luca Carettoni (@_ikki)

The old is new, again. CVE-2011-2461 is back!

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.


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.

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

After having identified all Flex SWF files compiled with a vulnerable version of the Adobe Flex SDK, there are three possibilities:
  • 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)