Pilgrimage
Hack the Box Pilgrimage Challenge, completed when the challenge was live.
Last updated
Hack the Box Pilgrimage Challenge, completed when the challenge was live.
Last updated
Start by enumerating the machine:
Adding the site to our /etc/hosts file.
We see a site with an upload option, login.
Went ahead and created an account.
Checking Wappalyzer we see the site is built using php, jquery and nginx:
More than likely we can perform the following to get access to the victim system:
Testing with uploading a reverse php shell.
Added the reverse shell:
Received image shrink failed.
Tried test.php%00.jpg, received image shrink failed.
Trying local file inclusion:
No luck.
Tried the following attempts to upload a php shell:
shell.php
File uploads:
shell.php%00.jpg
shell.php.jpg
shell.jpg.php
There seems to be some file validation.
Tried the following technique:
Bypass magic number, echo '<?php system($_REQUEST['cmd']); ?>' >> img.png
I was able to successfully upload the image, but the cmd execution failed
likely due to the image compression which is occurring
Moving to the next bullet points to attempt to run a shell post compression of the file
Used the php PoC from here - https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_plte_png.php
Attempting to use this payload, I ran into errors with the function imagecreate(). Did some searching online and this was due to not having the package installed on my machine.
Successfully ran php gen_plte_png.php. Successfully uploaded the file to the webserver. Unfortunately the payload I attempted to use did not work.
After reviewing a quick walkthrough, I saw we could use a tool called git-dumper to read a directory I previously found .git when I ran dirsearch.
Reference for dirsearch; https://www.kali.org/tools/dirsearch/
This is part of the Kali repository, so it should be easy to install
Reference for git-dumper;
Ran git-dumper against the url <machine-ip>/.git
This pulls the files which essentially compose the app.
Here we can see that there is a file named magick. From previous review and attempts to exploit the form, we know there is a tool called imagemagick was has exploits readily available.
From here we know to look around for potential PoC's which are specifically for this version of ImageMagick.
I found the following PoC that's available for arbitrary file reads:
https://github.com/Sybil-Scan/imagemagick-lfi-poc
I went ahead and forked the repo as well to include the requirements.txt, so you can run:
I went with naming my files bad_llama.png to make sure I knew which file to upload since I've already made so many attempts.
Uploaded the file.
Then pulled and output the file via curl:
We can go ahead and then run:
We know that from the PoC that the generate.py is decoding hex. When we get the output from our outfile, we see a good size block of text after the phrase Raw profile type:
I took the long route and ran:
Then put the file in vim and removed everything but the block of hex characters. Once that was done, I opened that file in cyberchef and we can run the following:
The recipe is:
From the walkthrough I was sifting through to nudge me along (https://medium.com/@babayaga00897/pilgrimage-htb-writeup-ae8242270434), there was apparently an sql database in the .git/dashboard.php file from earlier.
I basically repeated these steps to pull the referenced database file:
Uploaded bad_llama.png to the site. Then pulled down the file:
Used Vim to remove pieces out of the db.out that I did not need, kept only the hex. Used Cyberchef to parse everything down:
The same recipe from earlier was used:
From_Hex('Auto') Remove_null_bytes()
Note to self: I need to try and find a way to get better with enumeration and learning tools, searching for things in the hay stacks
username; emily password;
Kernel:
ss - https://man7.org/linux/man-pages/man8/ss.8.html
Nothing abnormal here, we already knew from our nmap scan in the beginning there were only the two ports listening, 22, 80.
ps -ef --forest
Nothing really interesting from the output, the malwarescan.sh is kind of peculiar as I've not seen that before, but apparently it's just part of the websites capability to "watch" for malicious files being uploaded.
Something worth noting, is we do have read capabilities on /usr/sbin/malwarescan.sh
Still something maybe worth mentioning since the process is also owned by root.
Reviewing id:
No abnormal gid, uid.
Checking for executable files by group:
Again it looks like I'm super stuck. After reviewing the write-up again, https://medium.com/@babayaga00897/pilgrimage-htb-writeup-ae8242270434, it looks like things are pointing to reviewing:
/usr/sbin/malwarescan.sh
/usr/local/bin/binwalk
Upon further investigation, binwalk is not just a file found in our local user, emily, but also a binary which exists on the machine.
Searching for potential exploits to run against the file:
https://github.com/adhikara13/CVE-2022-4510-WalkingPath
This will allow for RCE on the victim machine via the exploit.
We need to upload the binwalk_exploit.png to our victim system in the /var/www/pilgrimage/upload directory. To do this, I used the following:
Note: Run this after creating your exploit.png
attacker system
Victim Server
Once your exploit is uploaded, be sure to setup a listener on your attacker machine:
attacker system
Once your file is uploaded to the victim, you can run:
This will make a callback to your attacker systems nc listener with our established reverse shell.
The demo on this site helped me better understand what needed to be run in order for the exploit to properly complete:
https://onekey.com/blog/security-advisory-remote-command-execution-in-binwalk/
