DockMagic
In a land of magic, a wizard escaped from his confinement and embarks on a new adventure. - by Utkar5hM
Last updated
In a land of magic, a wizard escaped from his confinement and embarks on a new adventure. - by Utkar5hM
Last updated
The following post by 0xb0b is licensed under CC BY 4.0
We start off with a Nmap scan of our target. We can discover just two open ports. We have SSH on port 22 with OpenSSH 8.4p1 and on port 80 with nginx/1.18.0, a web server.
Since only a web server is present, the first thing to do is enumerate possible directories. But running Gobuster on the IP of the machine does not give us satisfying results.
We visit the page with the IP of the machine and get redirected to http://site.empman.thm/
. We add that to our host file and continue.
Since we now know that subdomains are used, there might be more of them. We hit up FFuF to fuzz for possible subdomains. We are able to spot two subdomains: backup
and site
. The subdomain backup looks promising.
While Gobuster is running in the background, we move on to enumerate the web page manually, since the first 5000 entries of the wordlist does not lead to any results.
At backup.empman.thm
we find a zip file containing ImageMagick. ImageMagick is a free and open-source software suite for creating, editing, and converting raster and vector images. It provides a wide range of command-line tools and libraries for image manipulation and processing.
Because of the room name DockMagick this might be about vulnerabilities in ImageMagick. Several vulnerabilities were present, and the first thing that came to mind was ImageTragick. But that's another tale and not part of this challenge:
The zip contains, besides ImageMagick, a to-do list, giving us a valuable hint. There are two serious to-dos: one about revoking the user's ssh keys and the other about switching to another image processor vips instead of ImageMagick because of recent security vulnerabilities. This once again confirms our assumption that we can somehow exploit ImageMagick.
We check out the install-unix.txt
to spot the used version. It is ImageMagick-7.0.9
.
Next, we check out http://site.empman.thm/
. Here, we are able to create a user with a profile picture. There might be an entry point using an ImageMagick vulnerability.
After account creation, we are able to edit or delete our account, there is nothing more to do.
For foothold, we researched several CVEs regarding ImageMagick. One worked out. CVE-2022-44268
. This applies to versions 7.1.0–49
and below matching our found version. With that, we are able to read arbitrary files. The images are manipulated in such a way that a payload is executed when the images are processed by ImageMagick, which queries information on the target system and then saves it in the image information. This means that the avatar of our account contains useful information after uploading.
As PoC we use the following:
We modify our profile picture on our attacker machine to retrieve the contents of /etc/passwd
.
pngcrush -text a "profile" "/etc/passwd" tf2.png passwd.png
Via exiv2
we review our changes to the PNG file.
Next, we create an account with our modified profile picture. The account update functionality did not work properly, so we kept creating new accounts to retrieve valuable information.
We retrieve the profile picture from the Edit User page.
To be able to read the information, we use tool identify
.
The information is encoded in hex.
For the sake of simplicity, we use CyberChef to decode the information. We are able to retrieve information from the target system. The machine is indeed vulnerable to CVE-2022-44268
. We are able to spot the user emp
.
Recalling the to-do note in the zip file about the ssh keys, we try to access the key of the user emp
.
This time it takes a while, don't worry.
Again, we use identify on the downloaded profile picture...
And there is the ssh key encoded in hex.
We use CyberChef to decode it...
... and directly use it. We are able to log in as the user emp and find the first flag at /home/emp/flag1.txt
.
As always, on a Linux machine, we run LinPEAS
to enumerate the target.
We spot a cronjob running /usr/local/sbin/backup.py
with a modified PYTHONPATH variable to /dev/shm
. Interesting.
For confirmation, we run pspy
and see the job running.
Luckily, we have write access to /dev/shm
.
We inspect /usr/local/sbin/backup.py
and see that a backup process is initiated on /home/emp/app
using the cbackup
module.
Since we are able to write to /dev/shm
and the module is being looked for there first, we can control exactly what module is imported.
For further reading on Python library hijacking, see the following link:
We create our own module containing a reverse shell.
vim /dev/shm/cbackup.py
We set up a listener on port 4445 and place our module at /dev/shm/cbackup.py
and waited a bit. After a short duration, our reverse shell connects, and we are root
. First things first, we upgrade our shell. We are root now, and we find the second flag in /root/flag2.txt
.
Again, we run LinPEAS
and see that we are able to break out of the Docker container via mounts, see release_agent breakout 2
. Since the Room is called DockMagick this might be the correct track.
For further Docker enumeration, the script deepce.sh
is used.
But it just confirms that the breakout is possible via groups/ mounts.
A proof of concept is described in the following link. After running this PoC, the machine has to be restarted, because only ps aux
which initally was placed in /cmd
is being executed even after editing the /cmd
.
Running the Hacktricks Poc:
Since I was only able to use the exploit and did not fully understand it - something magically is happening here - at the time of writing, I will now refer to an excellent explanation of the Docker escape here:
Instead of ps aux
, we place a reverse shell in the cmd.
We set up a listener on 4443, and after executing sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs".
We escaped the Docker container.
From there, we are able to spot the third flag at /home/vagrant/flag3.txt
.