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.

Abusing Docker's Remote APIs

Forewords: is this post about a security vulnerability?

Ultimately it's not. This is a short note on how to exploit a somehow under-documented feature in the Docker remote APIs, since I did not manage to find clear guidance elsewhere and had to experiment with it myself. The reason for sharing is to save you time during the next pentest. That said, do I think this is bad? Yes, I do, as I will explain later on.

EDIT:  It turns out maybe I wasn't so wrong worrying about this.
See this announcement.

So, what is this about?

TL;DR; The Docker's Remote APIs trivially allow anyone with access to them to obtain access to the file system of the host, by design, and are unauthenticated (but disabled) by default.

Docker is a container-based platform for application "shipment", but to be fair, the official what is Docker page does a better job at explaining what this is all about. Docker is all the rage in these days and if you have never heard of it you should really look it up. It's quite likely to show up in one of your next penetration tests since companies seem to be experimenting with it quite extensively.

Docker is usually managed via a command line tool, which connects to the Docker server via a Unix socket. Access is restricted to the root user by default or to an aptly named Docker group, at least on the Ubuntu packages I've experimented with. So far, so good (sort of, but I don't really have strong arguments here).

This is of course not very convenient if you are working in any environment but your bedroom, so the helpful devs have provided a RESTful API which can be bound to any HTTP port. It is not enabled by default, which is something worth stressing, but can be turned on via a flag (-H tcp://IP_ADRESS:PORT). IANA has assigned ports 2375 and 2376 to the cleartext and SSL protected versions of the APIs respectively.

Looking at the API reference you'll see the APIs support all the operations you'd expect in a VM-management tool. By default there is no authentication so all you need is finding the target (which you can fingerprint by hitting the /version endpoint) - unless, of course, the admin has enabled some other kind of protection. The simplest way to do so is to use Docker's tlsverify feature, and everyone should do that. However, given the process does not work on OsX, guess how many programmer's laptops you are going to pop?

Accessing the host file system

The trick is ultimately quite simple: you just start a new container (think of it as a VM and you won't be far off) with a special configuration, then access it. First, create a container on the host (I'm trying to keep the call small here):

POST /containers/create?name=cont_name HTTP/1.1
Content-Type: application/json
    {
      "Cmd": ["/bin/bash"],
      "Image":"ubuntu",
    }

You'll get back an ID for your container. Now, start the container: note that in my experiment I was able to make these "Binds" only work once, the first time a container is started.

POST /containers/$ID/start
Content-Type: application/json

 {
  "Binds":["/:/tmp:rw"]
 }

Now you have a running container where the /tmp directory maps back to the / of the host. You have to login to the container to go wild on the host, but since you don't have direct access to said poor host, you need to have SSHd running on your container. The default Ubuntu image won't have SSHd up, so you'll have to use a different image (consider baseimage-docker) or tweak around with the cmd - this very last part is left as an exercise for the reader... or scream at me enough in the comments and I'll come up with something. Alternatively, you could be able to use the copy endpoint (documentation of the copy endpoint) but I've not experimented with that.

Why this is worth writing about, or why I don't like un-authed admin interfaces

As I said at the beginning of the post, this writeup is mostly a time saver for those dealing with Docker during a penetration test. However, there is something that I don't like in the way Docker has gone about designing these APIs: the lack of any default auth entirely.

There are of course various reasons why you would ship such a critical feature with no authentication to be seen: time to market, the fact that after all it is disabled by default, or more likely the will to attain segregation of duties. Designing a secure authentication system is complicated, error prone and difficult, and ultimately not the role of an API. Delegating it is a better idea than botching it, so that it is clear where things go wrong.

I beg to disagree, and I'd have expected better from a company that produced such a well thought discussion on the security issues with running SSH on a container. I'm going to argue that there is a huge gap between having a clearly horrible authentication system and nothing at all. The sad truth, as anyone who has done any pentest in his career will tell, is that the vast majority of the end users will run with whatever was shipped out of the box. Security people cheered when Oracle started to require users to set passwords during installation instead of setting default ones (ok ok, that's a long story), and the experience of the Internet Census tells us how easy it is to forget to change that password, or to setup that auth.

Of course, security minded admins will set up things correctly and invest all the time needed to configure a secure environment. But what about the others? Was it so difficult to require a Basic Auth-powered password at startup?

Friction (as in, anything that makes your product harder to use) is bad, but pwned users are worse.

Bonus: Here is a simple nmap probe for the Docker APIs.

##############################NEXT PROBE##############################
# Queries Docker APIs for the /version url containing version information.
#
Probe TCP docker q|GET /version HTTP/1.1\r\n\r\n|
rarity 7
ports 2375
sslports 2376

match docker m|.*{"ApiVersion":"(.*)","Arch".*"GitCommit":"(.*)","GoVersion".*"Os":"(.*)","Version":"(.*)"}.*| p/Docker remote API/ v/$1/ o/$3/ i/GitCommit:$2 DockerVersion:$4/