Attacking Docker exposed API

Riccardo Ancarani
Aug 10, 2018 · 6 min read

Original blog post:


Today we are going to explore some of the security risks associated with Docker, specifically we are going to examine the consequences of exposing the native Docker API to the external world.
By default when you install docker on a host, you can access the docker API only from the loopback interface. This is great but apparently for some reasons you might want to expose those APIs in order to use some external tool like Portainer.
Portainer is a lightweight docker management UI, you can run it locally attaching it to the docker socket or you can manage the containers hosted to a remote host.

In order to explain the attack I build a very simple lab:

  • The host machine: Ubuntu 16.04 LTS
  • The newest version of Docker CE installed on it
  • The debian container pulled into the host machine

The lab setup is very easy, I used Vagrant to spin up my Ubuntu VM and the docker commands are quite easy, so I’m not going explain them.

To replicate this attack, you’ll need to expose the docker API.
To do that I followed this tutorial.
All you have to do is create a file at with the following content:

then reload the unit files with:

and finally restarting the docker service:

now you should see the dockerd process listening on port 2376, to verify that:

Information Gathering & Enumeration

Now let’s assume the prospective of an attacker (the funny moment)
We don’t know anything about the host, so let’s begin with a port scan:

I had to scan more ports that the default top 1000 because the docker API port is not included :(
Ok then, what about service detection?

This confirm that we are dealing with Docker, nmap also discovered the exact version of Docker, if we want to confirm it manyally we can issue a GET request to the endpoint located at: http://<IP>:2376/version

NOTE: Claudio Criscione wrote a nmap script to do this (His GitHub page)

The last thing we want to do is to test the exposed API using the docker CLI (that you must have installed on your attacking box)
The syntax is quite easy:

Bingo, we can access the docker API with the docker CLI.

What to do from here

Let’s explore some of the possibilities we now have , what can we do with those APIs?

Gathering informations

Well, before attacking the host and the containers inside it we may want to gather some informations:

Are there some containers running?
docker -H ps

Are there some stopped containers?
docker -H ps -a

What are the images pulled on the host machine?
docker -H images

Inspect those images, there could be images with juicy infos, maybe you could run those images and access them.

In this scenario we found a running debian container:

Accessing the container

Spawning a shell inside a container is done via the exec command, in this case we may want to spawn a bash shell:

Why are we already root? Easy, the default user inside a container is root, quick win.
Once inside a container we can start digging for some useful information, the questions you have to answer are:

Is this container alone? Are there some other containers running? Was Compose used for the deploy?

What is this container’s purpose? A web app? A backend? A database?Depending on the purpose, you may want to look for configuration files with DB credentials and so on

Do you think that the sysadmin/devops used some kind of automatic configuration management tools like ansible, salt or anything like that?
If so, look for specific config files (google is your friend)
If you are lucky enough, you could own the entire app stack with few clicks!

Examine the code of the app inside the container if you can, can you determine if there are other interesting services like KV store, cache service?

Launching other containers

A funny thing that you can do is launch other containers, this is not very stealthy but can be useful.
Following the cryptomining trend, this blog post explains how to mine monero with docker:
You can have a look inside the Dockerfile at this link from DockerHub.
Easly you could launch a mining container with the following command:

voilà, mining with Docker.
Another option could be launch a botnet container, cheap zombies around the internet.

Is this a real threat?

You may think, who the hell leaves docker API exposed to the internet?
First, you could encounter this into an internal pentest, so this could be still useful.
Let’s ask our loyal fiend Shodan if this is a problem:

760 open Docker APIs. We could do some serious trouble.

Conclusions and further work

In this post we examined some of the threats associated with Docker.
Docker is a really powerful engine that saved lives of many developers (included me), but with a great power comes a great responsability.
Leaving Docker APIs exposed to the internet could lead to some troubles like data loss, cryptomining, botnet and so on.
I just started to dig into this world, in the future I will focus on other modern technologies like Kubernetes.
Software development changed, so pentesting should change and adapt too.
New technologies, new attacks, new threats, what a great time to be alive!

Have a nice hacking day!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store