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)

Shellshock: a survey of Docker images

When I look at the whole Shellshock debacle I am mostly sad. Sad that one can exploit a bug in a piece of software from 1989 to hack internet-connected devices in 2014. I always have this naive hope that maybe, just maybe, not everything is hopelessly broken - which of course gets crushed every other week.

Enough ranting. This blog post is about a small research I've run last week on Docker and Shellshock. No, sorry, this is not yet another "product X is vulnerable to Shellshock if used in a dark night with a super moon" report. So, what is this about? To understand that, we need to do some homework.

Docker Images and you

One of the core concepts of Docker is the difference between an Image and a Container. The TL;DR;, slightly inaccurate version (I should not use Virtual Machine in this context but all readers will be familiars with VMs) can be broken down in two points:
  1. An Image is a "base", read only virtual machine template and a "Container" is a writable instance of that machine;
  2. Images can be chained in a hierarchy of inheritance where a Base image is modified generating a child image and so on. This is "the way" to build images, even though you can always build your own.
Here is an image deep linked from the Docker documentation, which should make things clearer.
As you can see the Debian Base Image has a couple of children before finally generating a writable container. The logic of Docker is such that you should not be "changing" the base image but rather "building on top" of it, adding new components. You surely can, but that would kill one of the key benefits of Docker - citing Red HatLightweight footprint and minimal overhead.

Another important piece of information is that Docker maintains its own repository of public images that anyone can download and use. Docker has some rather complicated concepts for indexes and registries but they don't help us here: suffice to say that in practice lots of users will download images from this "official" repository.

Some important implications for us security folks:

  • If a base image has a security bug, it is at least possible (if not likely) that all the children will inherit the same bug;
  • The logic with which developers most likely approach this model is "I won't have to worry about the base image". This has been somehow hinted at and while some experienced developers will take the need for updates into consideration, not everyone will;
  • People will download and build upon a set of images from Docker's repository. No, we will not hack that, stop being evil!

Yeah, OK. So, Shellshock and Docker?

Now that we have a shared passable understanding of how Images work in Docker, let's get to what I have done. Last week I wondered how many of the most popular Docker base images had been updated: Shellshock had significant press coverage, the kind of coverage that pushes my mum to ask me about "that problem they are talking about in the news", so I figured that most of the main images would have been updated by now. Have them?

To find out, I whipped together a small Python script (published on github) that downloads a list of Docker images in an host VM, downloads and runs a script on each one and then reports the results. Once I finally managed to get it working reliably (and I suspect Guido might have heard me cursing my inability with the language he designed as I longed for the forbidden PHP fruit) I run it against the 100 most popular Docker images published on Docker's repository. In a nutshell, my script simply downloads the image, runs bashcheck on it, and then reports back the results. Because of the way the integration is designed, it will only work on Debian based machines: this is an important point because it means that all my results are likely underestimating the actual numbers.

Many crashes of Virtual Box later, the results were back. 30 Images had at least one instance of the many bugs the Shellshock umbrella covered. The full results are in the repository with the script, and I'll summarize them later on, but a caveat first. There is no proof that containers using these images or derivates of those images can be exploited: the only thing my script detects is the lack of patching. Don't wear your tinfoil hats just yet.

Now, without further ado...

Things I have learnt scanning the 100 most popular Docker images

  • 30% of the top 100 images were still vulnerable to one of the shellshock bugs;
  • 4 of the top 30 were vulnerable, 1 in the top 10 - so around 10% of the really popular images;
  • None of the vulnerable images were "official, Docker maintained images", but some were based on them: those images were still vulnerable because they were not rebuilt after the patch had been applied on the base images. That is, using a base image that gets regularly updated is not enough;
  • Some of the vulnerable images have a consistent user base, or at least downloads. asher/remote_syslog has got almost 900.000 downloads;
  • Docker security team is really nice. I gave them an heads up (nothing for them to do here really, in terms of incident response, but a lot of long term work) and they were very direct about the issues and shared some nice insights. Thumbs up.
A synthetic summary of the shellshock related bugs I've found scanning on October 9th 2014

Things you should worry about

Pentesters never worry! If you are a pentester, you likely want to keep an eye out for usages of Docker images during a pentest. You might even want to ask container's configurations to discover vulnerabilities before you even start the test - it's wonderful to have bugs at day 0.

If you are on the other side of the security fence, though, Docker is coming for you: it's the new hotness and it's quite likely to pop up in your infrastructure in one form or another. The sooner you have a strategy in mind to update those containers, the better.

But wait, didn't we use to have the very same problem with virtual machines a few years ago? We still do. But we used to, too.
However I think there are some subtle but important differences here. As an admin or security person, you can't just SSH in the machine and "apt-get upgrade" it, then save a new snapshot. There is a whole chain of images that might get forked in various points, where some of the nodes might even be escaping your control. Updating images is a very real, known problem: the Docker security team told me they are looking into it so hopefully things are going to get better in the future, but for now you really want to have a story for managing updates. Possibly before the next Shellshock.

My humble view on things that could be improved

I should start by saying that I don't know nearly enough about Docker's infrastructure to have a complete view - and that making posts where you have to provide no solution to the problems you find is much easier. However, I think I realized two or three things while working on this:
  • Reporting bugs on Docker images is hard! Some of these images have tens of thousands of users but no bug tracker or no clear way to report security bugs. In some cases I've opened an issue in github and hoped for the best. Providing some kind of built-in bug reporting feature would be a nice to have in the registry, or maybe this could be brewed in Dockerfiles?
  • Old images are bad! When you look at an image in Docker's repository you have a clear indication of when it was built (or at least committed). Check out the Properties of itzg/minecraft-server: it has been built before the Shellshock bug was even discovered and it's based on an official base image. Now, given that we know what base images are vulnerable to bugs and when, it should be possible to simply assume that all the images that have been built before that as potentially vulnerable as well;
  • Custom images are a lot of work to maintain. On one of my bug reports the maintainer of the image just said "sure, I'll rebuild". Since he was using an official Debian build as a base image, it's not a lot of work on his side. Had he used a completely custom OS, he'd have to do a standard upgrade, which takes more and more time and effort as the image ages.

In conclusion...

A somewhat interesting percentage of images was found to be vulnerable during my tests, for a total of maybe a couple of millions downloads and thus potentially affected containers. The interesting takeaway for me, however, was that updating Docker images is subtly different and possibly more complex than updating VMs. I suspect this is something we'll have to deal with more and more in the future as containerized systems become widespread.

EDIT: I have been pointed this blog post which does a detailed analysis of some of the official Base Images - I have only pulled the Latest tag for each Image, so they got more coverage there. From a quick skim, none of the images I've found to be vulnerable were based on the images they flag in the article.