Me : " i wish someone can give osce review" John : *uploads osce review* Me : " mmm i wish i could learn more vulnserver commands i just know trun, gter" John : *makes a vulnserver video* Me : "man i know nothing about docker and active directory privescs" John : *makes docker priv esc* Damn john right here reading minds
Sleek... after watching u for years constantly...now i can watch what ur doing in 1.2x ...and the funny part is i can get all that info bombarded.....thx for upgrading my free of cost journey to ur world....hahha
that why you shall configure the user namespace, and use a difference socket for each user, otherwise, giving a user docker acces (via the docker group) is the same as giving him the root group
Thanks so much! I can try put something together like that... for this one, just avoid having low-privilege users that do not need to be running Docker commands within the Docker group. Try and remove as much as you can from the Docker group.
So if you give someone permission to run Docker on a machine, is there any way to prevent them from getting root access as well? Or should you never give access to Docker to someone you don't trust?
Never give access to Docker for a user that might not be trusted. Their documentation has a good warning: "The docker group grants privileges equivalent to the root user." docs.docker.com/install/linux/linux-postinstall/ They also have some suggested techniques here: docs.docker.com/engine/security/security/#docker-daemon-attack-surface
Standard docker daemon runs as root so if somebody can run containers they can alway PrivEsc like in this example. There is rootless mode of docker: docs.docker.com/engine/security/rootless/ which let's you run docker daemon with your user ID (Not root)so you cannot write to files that your user does not have write access to. In other words no PrivEsc.
You'd need to run docker rootless. Support for that was recently released, but requires some settings on the host to make it possible. In general, don't give untrusted users docker API access, it's effectively giving them root.
Actually the dockerfile part is useless, you can just run this technique from a simple ubuntu:latest image without creating the workdir in the first place. That makes it a one-liner. But anyway, nice vid as always :)
That doesn't typically happen. For some reason every now and again on my machine Docker spits all that nonsense out -- something somehow goes wrong somewhere -- but it still creates the image. ¯\_(ツ)_/¯ Thanks for watching!
Can this privilege escalation be detected by EDR? The confusing part for me from this video was, how can a user change host os permissions while in docker?
Hi John. I wonder wt if we don't have internet access in the victim machine for downloading weezy. I think a good idea would be to download the weezy image in our local system and export and save it as a file. Then transfer that image file to victim and import it locally using docker import. And then run the container. I just thought this idea. I don't know how far that works. I have to try this. I got this idea watching ur video. Thnx a lot. Big fan of yours.
So basically it means if I everybody is saying that I have to keep seperate user for running docker commands, then this becomes quite useless since there is this loophole, right? I guess, gonna look into that rootless way.
You created a docker image of the target's file system and then spunn up a docker file and hopped inside with privileges because why wouldn't docker give the user/owner privilege of a container that's the point.... Great video john learned some docker syntax too 👍🏿
Right -- the issue is that the `mark` user is in the `docker` group so he can run docker commands and build docker images -- and the docker service is running as `root`. Thanks for watching!
@@_JohnHammond You wanna know the absurd thing... it would be a non-issue, if docker relied on the user permissions that ran the command rather then it's own (to be clear it should have a set as well, but just not ignoring the user level permissions in regards to the host access of any sort)
Nice video! Did you investigate this topic a bit more after I pointed out that adding a user to the docker group can cause harm in your video about dvwa in docker? :D
Oh, ha, no, those weren't correlated -- I had known this technique for years, I just saw it resurface in a CTF over the weekend. :P My personal user has the Docker privileges since, I need that to use Docker, and that account already has sudo permissions. Thanks for watching!
I'm really new to docker and I don't really understand what John Hammond did exactly in the video. Can comeone please clarify what happened so that someone as dumb as me can understand it.
That seems like an extremely short sited failure. I am glad the warnings are out there, but honestly if docker gets to be more used & 'mainstream' for universal programs & games, this flaw alone will compromise security and we'll start to see docker just not allowed on education systems, cooperate systems, and likely advised against for enterprise systems that are leased out. Where windows has it's security flaws ( that can be easily locked down by a knowledgeable user/admin ), I can't imagine one person worth their weight to ever suggest leaving a program that would be able to escalate to system level privilege's w/o the admin password/access first & each time the setup has changed. There are a few warnings to be had here, but what I don't get is.. if this flaw is inherent within docker structure... how the hell does anyone ever think it'll ever be a suitable program for the masses to run programs in, if all they have to do is what amounts to 1-2min of typing at most to get un fettered access to the system (well beyond what even admin users of windows get without extensive combing through varied security setups )
Nice video, thanks. I played that at 0.75 as a beginner to understand everything ahah U are too fast ahah :D The only thing I didnt understood is this command : docker run -v /:/privesc -it privesc /bin/bash Why do we put /:/ before the first "privesc"? I mean, which should be the general syntax of this command? Cause I dont understand /:/
the "/:/privsec" is meant for the volume flag "-v". "-v /:/privesc" is telling docker to mount the root directory "/" onto the "/privesc" directory when running the container. the last part "/bin/bash" is telling docker what command to run in this container, which in this case is shell access into the container now with the root directory "/" mounted and shell access into container, the exploit can be carried out
Video starts at 2:34
Me : " i wish someone can give osce review"
John : *uploads osce review*
Me : " mmm i wish i could learn more vulnserver commands i just know trun, gter"
John : *makes a vulnserver video*
Me : "man i know nothing about docker and active directory privescs"
John : *makes docker priv esc*
Damn john right here reading minds
Ha! Our priorities are aligned mwahaha. Thanks so much for watching!
Sleek... after watching u for years constantly...now i can watch what ur doing in 1.2x ...and the funny part is i can get all that info bombarded.....thx for upgrading my free of cost journey to ur world....hahha
Congrats on the sponsorship! If anyone deserves it it's you man
Thank you! Good to get those in every now and again. :) Thanks for watching!
Damn, screw your username
This gives me flashbacks to spamming those characters wherever i could to fuck with people lmao
Dude this is one of your best videos. Very powerful!! Thx
that why you shall configure the user namespace, and use a difference socket for each user, otherwise, giving a user docker acces (via the docker group) is the same as giving him the root group
I believe I'm not the only one who expect the video is about escaping container
Great video as always, I would like if you share some links or advises to avoid the exploits you talk about
Thanks so much!
I can try put something together like that... for this one, just avoid having low-privilege users that do not need to be running Docker commands within the Docker group. Try and remove as much as you can from the Docker group.
Well, the issue here is that a mount to the host root file system has been given, if it was not the case, this truck wouldn’t have worked…
Strong
That's why you never give access to the docker daemon or map the docker socket to a container.
Note: This only works with privileged containers
and not just privileged? you would have to be in the same "mount" namespace. correct?
So if you give someone permission to run Docker on a machine, is there any way to prevent them from getting root access as well? Or should you never give access to Docker to someone you don't trust?
Never give access to Docker for a user that might not be trusted. Their documentation has a good warning: "The docker group grants privileges equivalent to the root user."
docs.docker.com/install/linux/linux-postinstall/
They also have some suggested techniques here:
docs.docker.com/engine/security/security/#docker-daemon-attack-surface
Standard docker daemon runs as root so if somebody can run containers they can alway PrivEsc like in this example. There is rootless mode of docker: docs.docker.com/engine/security/rootless/ which let's you run docker daemon with your user ID (Not root)so you cannot write to files that your user does not have write access to. In other words no PrivEsc.
You'd need to run docker rootless. Support for that was recently released, but requires some settings on the host to make it possible. In general, don't give untrusted users docker API access, it's effectively giving them root.
Actually the dockerfile part is useless, you can just run this technique from a simple ubuntu:latest image without creating the workdir in the first place. That makes it a one-liner. But anyway, nice vid as always :)
Hi John, great video!
Could you tell us why we see CPU registers during your Docker build process @7:02 ?
That doesn't typically happen. For some reason every now and again on my machine Docker spits all that nonsense out -- something somehow goes wrong somewhere -- but it still creates the image. ¯\_(ツ)_/¯
Thanks for watching!
awesome explanation, thank you so much👍
2:34 Start
Good lesson. 👍 Thank you. 🕵️♂️🕵️♀️🕵️♂️🕵️♀️🕵️♂️
Thanks for watching!
This is so cool!! Thanks John!
Thanks for watching!
wait for 4 second before pressing enter and running a command. sometimes it is hard to read what you type in the terminal
How would you protect against that? I mean a lot of us have docker on their system?
thanks :)
i got stuck in a docker container. "docker command not found". i got a bash script and a .dockerenv file...
Can this privilege escalation be detected by EDR? The confusing part for me from this video was, how can a user change host os permissions while in docker?
Besides not adding a user to the docker group and not having docker run on startup (or without sudo), how can we fix this? Is this an open exploit?
you could run unprivileged containers with podman without the docker daemon
Hi John. I wonder wt if we don't have internet access in the victim machine for downloading weezy. I think a good idea would be to download the weezy image in our local system and export and save it as a file. Then transfer that image file to victim and import it locally using docker import. And then run the container. I just thought this idea. I don't know how far that works. I have to try this. I got this idea watching ur video. Thnx a lot. Big fan of yours.
I also always confuse the order of the usermod syntax haha
So basically it means if I everybody is saying that I have to keep seperate user for running docker commands, then this becomes quite useless since there is this loophole, right? I guess, gonna look into that rootless way.
You created a docker image of the target's file system and then spunn up a docker file and hopped inside with privileges because why wouldn't docker give the user/owner privilege of a container that's the point.... Great video john learned some docker syntax too 👍🏿
This is because docker user/group has the permissions right?
Right -- the issue is that the `mark` user is in the `docker` group so he can run docker commands and build docker images -- and the docker service is running as `root`. Thanks for watching!
@@_JohnHammond You wanna know the absurd thing... it would be a non-issue, if docker relied on the user permissions that ran the command rather then it's own (to be clear it should have a set as well, but just not ignoring the user level permissions in regards to the host access of any sort)
cool
Nice video! Did you investigate this topic a bit more after I pointed out that adding a user to the docker group can cause harm in your video about dvwa in docker? :D
Oh, ha, no, those weren't correlated -- I had known this technique for years, I just saw it resurface in a CTF over the weekend. :P
My personal user has the Docker privileges since, I need that to use Docker, and that account already has sudo permissions. Thanks for watching!
@@_JohnHammond Yeah of course you know that, I just wanted to know if that brought up the idea to make a video about it :D
I'm really new to docker and I don't really understand what John Hammond did exactly in the video. Can comeone please clarify what happened so that someone as dumb as me can understand it.
That seems like an extremely short sited failure. I am glad the warnings are out there, but honestly if docker gets to be more used & 'mainstream' for universal programs & games, this flaw alone will compromise security and we'll start to see docker just not allowed on education systems, cooperate systems, and likely advised against for enterprise systems that are leased out.
Where windows has it's security flaws ( that can be easily locked down by a knowledgeable user/admin ), I can't imagine one person worth their weight to ever suggest leaving a program that would be able to escalate to system level privilege's w/o the admin password/access first & each time the setup has changed.
There are a few warnings to be had here, but what I don't get is.. if this flaw is inherent within docker structure... how the hell does anyone ever think it'll ever be a suitable program for the masses to run programs in, if all they have to do is what amounts to 1-2min of typing at most to get un fettered access to the system (well beyond what even admin users of windows get without extensive combing through varied security setups )
Does anyone else see the black dotted vertical line over the mid part of the comments? What is that?
It's called Zalgo text
whoa
Thanks for watching!
Nice
Thanks for watching!
@@_JohnHammond Thank you for interesting videos :)
Any way of protecting against this other then not letting untrusted people run docker?
ding that dong
big pp vibes
Nice video, thanks. I played that at 0.75 as a beginner to understand everything ahah U are too fast ahah :D
The only thing I didnt understood is this command :
docker run -v /:/privesc -it privesc /bin/bash
Why do we put /:/ before the first "privesc"?
I mean, which should be the general syntax of this command? Cause I dont understand /:/
the "/:/privsec" is meant for the volume flag "-v".
"-v /:/privesc" is telling docker to mount the root directory "/" onto the "/privesc" directory when running the container.
the last part "/bin/bash" is telling docker what command to run in this container, which in this case is shell access into the container
now with the root directory "/" mounted and shell access into container, the exploit can be carried out
@@chainer22 ty :)
smashed the bell , ! , @rootsh3ll1 :)