File upload vulnerability
subdomain enumeration and discovery
Identify upload function and backend service
A quick nmap scan shows some basic ports suggesting a narrow attack surface followed by a redirect.
We initially cannot resolve the webpage which pushes a redirect to artcorp.htb. We could burp the request to render the page before the redirect, but let us instead add this host to our hosts file.
We are able to successfully browse to the website. Here it becomes apparent that there is nothing interactive we can work with.
Using FFuF we are able to find our target.
We see our target of dev01.
Adding the file to our /etc/hosts file and browsing over provides a MetaView option.
File upload/Initial foothold
The first thing to do is try a file upload with a .png which provides a blank screen.
We try a jpg instead and sure enough it works. This results we are looking at are from the exiftool. We eventually figured this out because we are dealing with meta data, and using the exiftool renders those same results.
From here we learn about the following CVE. https://github.com/convisolabs/CVE-2021-22204-exiftool
We clone the exploit locally and follow the instructions. We change our IP and PORT in the config file to our local host and listening port. We run the exploit and it generates a file that we then upload to the target.
Convert_images.sh discovery and enumeration
Mogrify discovery and research
conver_images.sh and Mogrify exploit to user
Reviewing users on the box shows us the only user is Thomas.
Running linpeas provided a convert_image.sh file.
$ cat /usr/local/bin/convert_images.sh
cd /var/www/dev01.artcorp.htb/convert_images/ && /usr/local/bin/mogrify -format png *.* 2>/dev/null
Lets take a look at the mogrify we learn it is a tool to resize images. More can be read here.
Taking a look at the version and searching up CVE's leads to some fantastic results.
This look wonderful, as we are on version 7.0..10-36. So this descriptions leads me to believe that we can use the ImageMagic binary, and exploit the -authentication option to inject shell commands.
I found a great POC here and modified the command to cat the users SSH key into the tmp folder, which will automatically widen the permissions providing us full access to the SSH key of Thomas.
Here I uploaded the file and copied it over to the directory where are vulnerable binary executes.
Great lets pivot and get the ssh key!
Internal discovery of sudo -l
Research neofetch config usage
Research neofetch GTFO
Sudo -l provides us with our next step. We also note the env_keep+=XDG_CONFIG_HOME
What is neofetch!
It shows the linux info in a nice and colorful way :)
Running the neofetch binary as www-data provided infromation to the workflow of the binary.
Let's try adding code to the config.conf file for neofetch. Great this totally executes when run. Now we want this to run as root!
This suggests that neofetch calls the config file when running. We know that we have a persistent environment variable of env_keep+=XDG_CONFIG_HOME.
So we point this environment variable to a config file with malicious code and we get root.
I had to execute out of the thomas directory, and copy and paste the commands back to back or the malicious command was quickly sanitized.
echo 'exec /bin/sh' > .config/neofetch/config.conf
XDG_CONFIG_HOME=~/.config sudo neofetch