Abusing Docker Configuration - Privilege Escalation

Off-topic Exploits
, , , ,
1

Spoiler Removed

2

Nice article bro, to must have, thanks. Bookmarked.

3

Thanks, this is a great article, and it enlightened me on something I found weird on a box I recently rooted. I don’t want to give any spoilers so I won’t name the box, I believe it’s still active.

Essentially after basic enum it was obvious that Docker had to be the path to root, so my first step in getting user access with docker privileges was to check for running containers. When I found one I jumped straight in to explore, assuming that this container was supposed to be running…

Once in there, I found that the whole host filesystem was mounted under /mnt, and I could grab the root flag from there. As a big fan of docker in development, my initial excitement ultimately ended up a bit of a let-down. I felt like the container was extremely unrealistic and that this would be a rare find in the wild. I also felt like it didn’t really count as rooting the box without a shell, but I also considered that may be a bit of a lesson in itself.

I must admit that even after thinking this container was odd, until I read your article it had never crossed my mind that I was piggy-backing off somebody else’s work here.

Edit: after reading more thoroughly, I see that it’s the box in your article :lol: I wonder if it was your exploit I hijacked?

4

Type your comment> @nospi said:

Thanks, this is a great article, and it enlightened me on something I found weird on a box I recently rooted. I don’t want to give any spoilers so I won’t name the box, I believe it’s still active.

Essentially after basic enum it was obvious that Docker had to be the path to root, so my first step in getting user access with docker privileges was to check for running containers. When I found one I jumped straight in to explore, assuming that this container was supposed to be running…

Most HTB boxes where Docker is the route to root have this as the intended path. I think the box you are talking about was set up for this to be the way.

Once in there, I found that the whole host filesystem was mounted under /mnt, and I could grab the root flag from there. As a big fan of docker in development, my initial excitement ultimately ended up a bit of a let-down. I felt like the container was extremely unrealistic and that this would be a rare find in the wild.

I’ve seen it in a few incidents I’ve been called into. It isn’t that rare. Badly configured containers are surprisingly common.

I also felt like it didn’t really count as rooting the box without a shell, but I also considered that may be a bit of a lesson in itself.

There are lots of boxes which dont lend themselves to you getting a root shell. The objective of the “mission” is to get the root flag, any task you set over that is self-enforced.

I must admit that even after thinking this container was odd, until I read your article it had never crossed my mind that I was piggy-backing off somebody else’s work here.

Edit: after reading more thoroughly, I see that it’s the box in your article :lol: I wonder if it was your exploit I hijacked?

I dont know which box was in the article (I assume that’s why it got spoilered) but the there have been a lot of boxes in the last 12 months which have used an intended privesc path like this.

5

Type your comment> @TazWake said:

Most HTB boxes where Docker is the route to root have this as the intended path. I think the box you are talking about was set up for this to be the way.

Please let me know if this is a spoiler - the box can be inferred from the example screenshot of the POC script in OP’s article. His first command there also suggests that there were no containers running before he ran his ‘exploit’.

I’ve seen it in a few incidents I’ve been called into. It isn’t that rare. Badly configured containers are surprisingly common.

I’m still surprised by how common these situations are, but the more I learn in this field, the more the world appears to be precariously balanced on matchsticks.

I have to admit that I hadn’t even considered the option of potential spoiler removed. HTB is my only experience in this area outside of Uplink and badly configuring my own servers, so it’s great to get an idea of how realistic these machines really are.

Thanks for your comments!

6

@nospi said:

Please let me know if this is a spoiler - the box can be inferred from the example screenshot of the POC script in OP’s article. His first command there also suggests that there were no containers running before he ran his ‘exploit’.

With a huge caveat that avoiding spoilers may mean we are talking at cross purposes here, and assuming we are talking about the same box:

  1. The docker image isn’t normally running so if you exploited a running docker image, you probably exploited someone else’s set up. However this is just a “docker run” difference really.

  2. The main clues come from enumerating what the user is part of and what exists on the filesystem to be used.

7

Sorry guys, I realized it is a spoiler, but I didn’t feel that way when using the screenshots because when you arrive at this point, you already did the hard part. I will blur the machine name this evening in the article.
About how the box initial state:

  • There is no container running (docker ps returns no container).
  • An Ubuntu image has already been pulled and docker image returns a result with 1 image.
  • A harder way would be to have to copy an image and a Dockerfile to exploit them (which should usually be easy with an internet connection as you can pull images from Docker Hub)
8

As promised, I blured machine and user name on the screenshots and nothing should appear now.
I hope HTB will agree that I can put the link to my article again:

Thanks