First I tried to hit machine IP the browser and got no response. Either no web server there, or some tinkering needed to access it.

Nmap scan revealed that it's the latter:

80/tcp open  http    syn-ack nginx 1.18.0
|_http-title: Did not follow redirect to http://pilgrimage.htb/
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: nginx/1.18.0

We got a redirect attempt, but requesting pilgrimage.htb in browser also doesn't work. And why would it, no resolver knows this domain. So I added the line:

10.10.11.219 pilgrimage.htb

to /etc/hosts on my kali machine, and voila.

Now we can access the web app running on the box. A quick glance on the source code revealed links like "login.php", so it's a PHP app. Next useful point I discovered is that when you upload an image, app gives a link to shrunken image. So we have some kind of input-output interactive part of a web app, usually things like that appear to be hackable. Except this info, I didn't find anything useful on pages or in source code and decided that it's time to fuzz this website.

A combo of ffuf and common.txt wordlist from seclists revealed that there is an exposed .git directory. I used gitjacker script to download it after I failed to outright clone it, and found some goodies there.

• a file called 'magick' that google identified as a part of ImageMagick package, a Linux binary for image processing

• local path to SQlite database file

• possible username 'emily' from git commit

• a script bulletproof.php used for image uploads

I started my research with bulletproof.php and found no vulnerabilities there. Also, database interactions inside PHP code were properly configured to prevent SQL injection by using PDO and prepared statements.

Next came magick, and there it was. I checked it's version using dpgk -S magick and found out that it's ImageMagick 6.q16-6 which has an Arbitrary File Read vulnerability, documented under CVE-2022-44268. Link https://github.com/voidz0r/CVE-2022-44268 has a description and exploit ready for usage. It allows to instruct ImageMagick to read arbitrary file in the system and embed it into the processed image.

So firstly I tried it out on /etc/passwd and confirmed that non-root user is emily. Then I tried to snatch /home/emily/user.txt but failed, because ImageMagick was executed under www-data user, that can't read /home/emily. But what this account could access it an sqlite database file. So I grabbed it, did necessary unpacking of binary data from the image and got what looked like a login:password pair.

I tried to ssh into machine under emily using this password, and it worked. So that's user flag pwned!

Now, to get the root flag I obviously needed root-level access. I started with exploring /home/emily

After configuring a few hundred of linux-based web servers you tend to notice uncommon files and folders. And I didn't remember ~./config/binwalk to be pre-installed, so I thought that it's there for a reason.

Checking out running processes revealed a script running with root privileges:

Combining that with googled knowledge that binwalk is a malware scanner for linux systems told me I'm on a right path an that probably that's my way to pwning the machine. So here's the file:

Linux tool inotifywait allows to detect changes in files and folders and run scripts on them upon such a change. So basically it breaks down to a simple logic: whenever a file appears inside /var/www/pilgrimage.htb/shrunk a command binwalk -e "$filename" will be executed against this file with root privileges.

Googling "binwalk cve" eventually got me to CVE-2022-4510, a Remote Code Execution vulnerability. And that's just what we need to get a root shell. RCE allows to execute arbitrary command, and that command would be a reverse shell to my attack box, obviously.

Last thing I stumbled upon was that exploit that I found generated a .png image with payload inside of it, but when binwalk extracted it nothing happened. POC had a pretty brief description, a sapienti sat style. I tried running binwalk -e exploit.png, it unpacked and detected PFS payload but didn't execute it. Finally, after poking and digging I found that I need to run binwalk -e against a .pfs exploit, not the .png containing it. I tried it against injected ping 10.10.14.2 -c 10 command and listened with tcp dump, and it worked!

Next it was easy, I spawned a reverse shell to root and got the flag.

First I tried to hit machine IP the browser and got no response. Either no web server there, or some tinkering needed to access it.

Nmap scan revealed that it's the latter:

80/tcp open  http    syn-ack nginx 1.18.0
|_http-title: Did not follow redirect to http://pilgrimage.htb/
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: nginx/1.18.0

We got a redirect attempt, but requesting pilgrimage.htb in browser also doesn't work. And why would it, no resolver knows this domain. So I added the line:

10.10.11.219 pilgrimage.htb

to /etc/hosts on my kali machine, and voila.

Now we can access the web app running on the box. A quick glance on the source code revealed links like "login.php", so it's a PHP app. Next useful point I discovered is that when you upload an image, app gives a link to shrunken image. So we have some kind of input-output interactive part of a web app, usually things like that appear to be hackable. Except this info, I didn't find anything useful on pages or in source code and decided that it's time to fuzz this website.

A combo of ffuf and common.txt wordlist from seclists revealed that there is an exposed .git directory. I used gitjacker script to download it after I failed to outright clone it, and found some goodies there.

• a file called 'magick' that google identified as a part of ImageMagick package, a Linux binary for image processing

• local path to SQlite database file

• possible username 'emily' from git commit

• a script bulletproof.php used for image uploads

I started my research with bulletproof.php and found no vulnerabilities there. Also, database interactions inside PHP code were properly configured to prevent SQL injection by using PDO and prepared statements.

Next came magick, and there it was. I checked it's version using dpgk -S magick and found out that it's ImageMagick 6.q16-6 which has an Arbitrary File Read vulnerability, documented under CVE-2022-44268. Link https://github.com/voidz0r/CVE-2022-44268 has a description and exploit ready for usage. It allows to instruct ImageMagick to read arbitrary file in the system and embed it into the processed image.

So firstly I tried it out on /etc/passwd and confirmed that non-root user is emily. Then I tried to snatch /home/emily/user.txt but failed, because ImageMagick was executed under www-data user, that can't read /home/emily. But what this account could access it an sqlite database file. So I grabbed it, did necessary unpacking of binary data from the image and got what looked like a login:password pair.

I tried to ssh into machine under emily using this password, and it worked. So that's user flag pwned!

Now, to get the root flag I obviously needed root-level access. I started with exploring /home/emily

After configuring a few hundred of linux-based web servers you tend to notice uncommon files and folders. And I didn't remember ~./config/binwalk to be pre-installed, so I thought that it's there for a reason.

Checking out running processes revealed a script running with root privileges:

Combining that with googled knowledge that binwalk is a malware scanner for linux systems told me I'm on a right path an that probably that's my way to pwning the machine. So here's the file:

Linux tool inotifywait allows to detect changes in files and folders and run scripts on them upon such a change. So basically it breaks down to a simple logic: whenever a file appears inside /var/www/pilgrimage.htb/shrunk a command binwalk -e "$filename" will be executed against this file with root privileges.

Googling "binwalk cve" eventually got me to CVE-2022-4510, a Remote Code Execution vulnerability. And that's just what we need to get a root shell. RCE allows to execute arbitrary command, and that command would be a reverse shell to my attack box, obviously.

Last thing I stumbled upon was that exploit that I found generated a .png image with payload inside of it, but when binwalk extracted it nothing happened. POC had a pretty brief description, a sapienti sat style. I tried running binwalk -e exploit.png, it unpacked and detected PFS payload but didn't execute it. Finally, after poking and digging I found that I need to run binwalk -e against a .pfs exploit, not the .png containing it. I tried it against injected ping 10.10.14.2 -c 10 command and listened with tcp dump, and it worked!

Next it was easy, I spawned a reverse shell to root and got the flag.