-
How Default Settings Leave Your Containers Exposed
Over the past few years, Docker has taken the tech world by storm. Its ability to simplify app deployment, boost scalability, and keep developers happy has made containerization the go-to solution for businesses of all sizes. But as Docker adoption has skyrocketed, so have the security risks that come with running containers straight out of the box. At Shaka Cyber, we see it all the time: organizations riding the Docker wave, but overlooking the hidden dangers in default setups. If you’re using Docker—or thinking about it—now’s the time to make sure convenience doesn’t come at the expense of your security.
What is Docker?
Docker is a platform that packages applications and all their dependencies into lightweight, portable containers. This approach means your software runs the same way whether it’s on a laptop, server, or in the cloud, eliminating common setup and compatibility headaches. For administrators, Docker offers a powerful way to deploy, manage, and scale applications with ease—making it simple to launch new services, update existing ones, or move workloads between environments without extra hassle.
The Problem
A big part of Docker’s appeal is how quickly you can get containers running—but that speed can lead to risky shortcuts. One of the most dangerous is the widespread use of the
--privilegedflag, which is sometimes included by default in third-party scripts or quick-start guides. When a container runs with--privileged, it gains nearly unrestricted access to the host system, stripping away most of Docker’s built-in security barriers. Combine that with containers that aren’t locked down to localhost, and you have a recipe for disaster: attackers can remotely access exposed containers and, if they’re running privileged, use them as a launchpad to take over the entire server. It’s an all-access pass that’s often granted without a second thought.One look at Shodan shows that this is a widespread problem. Only looking at the default ports (2375 and 2376), there are more than 400 vulnerable instances that are internet facing. Imagine how many there are, hiding on internal networks:
-
How Default Settings Leave Your Containers Exposed
Over the past few years, Docker has taken the tech world by storm. Its ability to simplify app deployment, boost scalability, and keep developers happy has made containerization the go-to solution for businesses of all sizes. But as Docker adoption has skyrocketed, so have the security risks that come with running containers straight out of the box. At Shaka Cyber, we see it all the time: organizations riding the Docker wave, but overlooking the hidden dangers in default setups. If you’re using Docker—or thinking about it—now’s the time to make sure convenience doesn’t come at the expense of your security.
What is Docker?
Docker is a platform that packages applications and all their dependencies into lightweight, portable containers. This approach means your software runs the same way whether it’s on a laptop, server, or in the cloud, eliminating common setup and compatibility headaches. For administrators, Docker offers a powerful way to deploy, manage, and scale applications with ease—making it simple to launch new services, update existing ones, or move workloads between environments without extra hassle.
The Problem
A big part of Docker’s appeal is how quickly you can get containers running—but that speed can lead to risky shortcuts. One of the most dangerous is the widespread use of the
--privilegedflag, which is sometimes included by default in third-party scripts or quick-start guides. When a container runs with--privileged, it gains nearly unrestricted access to the host system, stripping away most of Docker’s built-in security barriers. Combine that with containers that aren’t locked down to localhost, and you have a recipe for disaster: attackers can remotely access exposed containers and, if they’re running privileged, use them as a launchpad to take over the entire server. It’s an all-access pass that’s often granted without a second thought.One look at Shodan shows that this is a widespread problem. Only looking at the default ports (2375 and 2376), there are more than 400 vulnerable instances that are internet facing. Imagine how many there are, hiding on internal networks:
-
How Default Settings Leave Your Containers Exposed
Over the past few years, Docker has taken the tech world by storm. Its ability to simplify app deployment, boost scalability, and keep developers happy has made containerization the go-to solution for businesses of all sizes. But as Docker adoption has skyrocketed, so have the security risks that come with running containers straight out of the box. At Shaka Cyber, we see it all the time: organizations riding the Docker wave, but overlooking the hidden dangers in default setups. If you’re using Docker—or thinking about it—now’s the time to make sure convenience doesn’t come at the expense of your security.
What is Docker?
Docker is a platform that packages applications and all their dependencies into lightweight, portable containers. This approach means your software runs the same way whether it’s on a laptop, server, or in the cloud, eliminating common setup and compatibility headaches. For administrators, Docker offers a powerful way to deploy, manage, and scale applications with ease—making it simple to launch new services, update existing ones, or move workloads between environments without extra hassle.
The Problem
A big part of Docker’s appeal is how quickly you can get containers running—but that speed can lead to risky shortcuts. One of the most dangerous is the widespread use of the
--privilegedflag, which is sometimes included by default in third-party scripts or quick-start guides. When a container runs with--privileged, it gains nearly unrestricted access to the host system, stripping away most of Docker’s built-in security barriers. Combine that with containers that aren’t locked down to localhost, and you have a recipe for disaster: attackers can remotely access exposed containers and, if they’re running privileged, use them as a launchpad to take over the entire server. It’s an all-access pass that’s often granted without a second thought.One look at Shodan shows that this is a widespread problem. Only looking at the default ports (2375 and 2376), there are more than 400 vulnerable instances that are internet facing. Imagine how many there are, hiding on internal networks:
How to Exploit:
From the offensive side, seeing an exposed Docker container should make your eyes light up like a Christmas tree. It is an easy privilege escalation and an easy container escape.
For this example, I spun up a basic nginx container. This is the default image and configuration pulled from the Docker cloud, which is where most administrators would pull their containers from.
While versioning with nmap, Docker containers will have the following version format:
This will indicate that there is a Docker API running on this port, which can then be queried to list what containers are running.
To query the Docker API, you just need to run the following command:
docker -H tcp://<remote host ip>:<port> psAnd this will output something like the following:
This is where the fun starts. To “hop” into the container, simply run the following:
docker -H tcp://<remote host ip>:<port> exec -it <container name> /bin/shWhen you are in the container and run whoami, it will say you are root. This is a bit misleading as, while you do have root privileges in the container, you can’t interact with the host system that the container is running on.
This is where --privileged flag comes into play. The flag “unlocks” more privileges that the base root user doesn’t have. Notably, mounting the host system’s file system, so that you can perform a container escape.
To access the container with --privileged, just run:
docker -H tcp://<remote host ip>:<port> exec --privileged -it <container name> /bin/shTo check to see if this worked, its as simple as running:
ls /dev
--privileged