You notice that in the Settings section, there is an option to enable any commands that an authenticated user may execute. You add
sh to the available commands and save the configuration:
You attempt a command injection test. You’re still aware of the unencrypted traffic, so you are careful with what you execute. You inject
whoami into the shell to see if you have command execution:
It works! You continue to enumerate more and identify that this web application is running in a container. While that’s not particularly surprising, you also identify that it is running in privileged mode and has access to the physical host’s file system:
This means that this container can mount the physical host’s root file system and you’ll have arbitrary read/write to the entire file system! This is an excellent primitive for a Docker escape and can get you onto the physical server.
You use the following commands to mount the host’s
/dev/sda5 file system:
You now have read/write access to the physical host! Carefully, you enumerate the home directories and their contents:
You notice that the
risottoadmin user has sudo privileges. You also notice that there is a
.ssh directory. You carefully enumerate the
.ssh directory to see if it has any files:
id_rsa file is the SSH key for the
risottoadmin user. It can get you authenticated access to the server.
Your team member looks at you.
“What’s the call, doc?”
What do you do?