News: CFTIRC Online Bulletin Board Launched (Pentesting & DFIR Miner).
Please register an account to access our community's posts.

Login  |  Register

Author Topic: Tale of Escaping a Hardened Docker container  (Read 683 times)

BigBrother

  • Administrator
  • Sr. Member
  • *****
  • Posts: 408
  • Karma: 2000
  • You Posted! You Posted! : Earned for posting at least 1 time.
    Have something to say! Have something to say! : Earned for posting at least 10 times.
    Talkative! Talkative! : Earned for posting at least 100 times.
Tale of Escaping a Hardened Docker container
« on: August 25, 2020, 08:11:05 pm »
Legend has it that before his death, Harry Houdini once said: “if it is truly possible for someone to return from the afterlife, I will”. Despite of the fact he was a great illusionist and escape artist, it seems this last proof has revealed to be very hard, even for him. Much simpler trying to escape out of a container. Of course a docker container 🙂 … our topic for today.

The danger of exposing “docker.sock” to a docker container is well-known and the security literature is full of examples (one is here) leading to container escape and privilege escalation issues in the host machine. But sometimes this is required (if not even necessary) for legitimate purposes, like creating other containers or pushing configuration settings. While the docker security guidelines advocate to not share the Docker UNIX socket inside a container, at the same time the project developers do not give any advice on how to secure such a kind of configuration whenever it is needed for “good reasons”. And that’s why so many companies that adopt docker and deliver services based on it, still today, suffer from this problem.

For example, last year a customer of us has contracted a security firm to check the robustness of their docker infrastructure. One of their main findings was the file “docker.sock” being mounted within some of their containers, which of course was a sufficient condition to compromise the entire host operating system. In the absence of a strong solution coming from the community, our customer has decided to build its own solution. They created a reverse proxy in front of the Docker UNIX socket file that would add authentication/authorization, and would prevent insecure utilization of the Docker socket itself.

Then they asked us to test the new architecture. This is the story of how the sympathetic Red Timmy has managed to bypass it.

The architecture

Before moving forward, we must explain a bit the implementation we have been called to test and a picture should make the job easy enough.


Read the full article @ https://www.redtimmy.com/docker/a-tale-of-escaping-a-hardened-docker-container/
--
Best Regards
CFTIRC Admin
https://www.acfti.org/cftirc-community