Introduction
Hack The Box’s Pilgrimage box tests the attacker on compromising the target through recon discovery, understanding of Git repositories and image processing applications and using known exploits to obtain footholds and escalate through the system to a complete compromise.
Enumeration
To begin with, start with a light port scan to identify our potential attack surface of the target. Using parameters “-sV” for software versioning and “-sC” will further enumerate the server with protocol-specific tests. You could run a broader and deeper port scan without a clear foothold path.
# nmap -sS -sV -sC -oA pilgrimagenmap pilgrimage.htb
Starting Nmap 7.93 ( https://nmap.org ) at 2023-08-25 15:36 EDT
Stats: 0:00:01 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
Nmap scan report for pilgrimage.htb (10.10.11.219)
Host is up (0.023s latency).
Not shown: 998 closed tcp ports (reset)
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-git:
| 10.10.11.219: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-title: Pilgrimage - Shrink Your Images
|_http-server-header: nginx/1.18.0
| http-cookie-flags:
| /:
| PHPSESSID:
|_ httponly flag not set
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 8.35 seconds
In Pilgrimage’s instance, an SSH and standard HTTP service are open publicly. NMap also found a .git repository on the web service port through the script’s engine. This is worth reviewing manually; if we can access the original storage of the web content, this will allow us to do whitebox testing of the application. Additionally, looking at the website, we can see a file upload service; this strongly indicates some file upload foothold.
.Git Structure
.GitHub Repositories use git folders to keep all details of the versioning of the repository on the local machine; this helps to track changes to files locally and remotely.
Using a web browser or Curl/Wget, we can see the .git folder is protected and presents an HTTP 403 response, denying the ability to browse the folder freely. Testing endpoints such as /.git/HEAD shows we can obtain repository files. Getting the /.git/index file will give us a database of all the files within the git repository.
Tools such as Gin can extract the index database and list all the filenames, giving a clear view of the website’s folder structure. At this point, it would be worth checking for configuration files or note files containing sensitive data.
Pulling some of the GitHub repository logs reveals the unique commit hashes. These hashes are publicly searchable within Github. We can locate the original GitHub repository within Github using this commit hash.
Download the public repository with the git clone command to obtain a local copy of the repository.
File Uploader
Within the web application, we see a file upload service. We consider file upload bypass vulnerabilities as our foothold in this system. As we have the application’s source code, we can also look to see if any filters are in place.
Upload Test
We are using BurpSuite to intercept the upload request of the file upload service with a standard PNG file. We can see a POST request is made to the index.php page with the contents of the PNG file.
Forwarding on the burp HTTP request, we see a second request is returned with the URL of the shrunk uploaded PNG file within the web application path.
This output URL is also presented on the webpage upon a successful upload. As we now know, the file upload starts the upload process on the Index.php page with a POST message. We can refer back to the GitHub repository to view the code of the upload feature on the site.
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
$image = new Bulletproof\Image($_FILES);
if($image["toConvert"]) {
$image->setLocation("/var/www/pilgrimage.htb/tmp");
$image->setSize(100, 4000000);
$image->setMime(array('png','jpeg'));
$upload = $image->upload();
if($upload) {
$mime = ".png";
$imagePath = $upload->getFullPath();
if(mime_content_type($imagePath) === "image/jpeg") {
$mime = ".jpeg";
}
$newname = uniqid();
exec("/var/www/pilgrimage.htb/magick convert /var/www/pilgrimage.htb/tmp/" . $upload->getName() . $mime . " -resize 50% /var/www/pilgrimage.htb/shrunk/" . $newname . $mime);
unlink($upload->getFullPath());
$upload_path = "http://pilgrimage.htb/shrunk/" . $newname . $mime;
if(isset($_SESSION['user'])) {
$db = new PDO('sqlite:/var/db/pilgrimage');
$stmt = $db->prepare("INSERT INTO `images` (url,original,username) VALUES (?,?,?)");
$stmt->execute(array($upload_path,$_FILES["toConvert"]["name"],$_SESSION['user']));
}
header("Location: /?message=" . $upload_path . "&status=success");
}
else {
header("Location: /?message=Image shrink failed&status=fail");
}
}
else {
header("Location: /?message=Image shrink failed&status=fail");
}
}The” exec” command within the code above shows a call to the magick binary with the parameters of the inputted file and outputted shrunk file.
Magick Vulnerability
Running the magick binary locally, we can see the software version; as this is cloned from the repository of the application, we can confirm the application is using 7.1.0-49.
We can search for the magick 7.1.0-49 application and vulnerabilities or exploits using search engines. We encounter an LFI exploit to read any file in the target server. The PoC I used can be found at https://github.com/Sybil-Scan/imagemagick-lfi-poc, “git clone” the repository and “chmod +x generate.py” to execute the PoC.
The first payload we use is a test to the known /etc/passwd file. This will reveal how the exploit works and, at the same time, give us a list of users within the system as we know there is an SSH service exposed. Firstly, we generate the malicious PNG file by requesting the /etc/passwd. Looking at the Exploit code in generate.py, the exploit is simply adding the requested file name to a PNG image metadata data under the entry of “profile”.
Using the malicious PNG file we upload to the platform, this file will pass through the “exec” command in the code above, and the exploit will trigger and store the output in the output file. Retrieve the shrunken file using wget or curl from the target machine.
As per the PoC, using the Identify feature of the magick software, we can look into the response image and see a hex string in the “Raw Profile type” field of the file.
Using any way you like to remove carriage returns and a hex decoder such as cyberchef or the python module, the output is decoded, and the /etc/passwd is shown. We see a user called “Emily” with /bin/bash access from the file output.
User Foothold
Looking at the uploader code above, a database called “/var/db/pilgrimage” is referenced to store the filename details for a given user. We can obtain this file with the LFI exploit to read the database for any credentials. Repeating the steps like the first payload, we get a hex dump of the file within the returned shrunk image file.
Taking the header numbers and using a hex decoder, we can see that the SQLite Format 3 file type is shown within the data. This confirms we successfully obtained the file from the target.
Decoding the hex data, we came across a set of credentials for Emily.
We can log in and grab the user flag within the Emily account to test these credentials on the SSH-exposed service.
Privilege Exploit
We observe a “malwarescan.sh” process running as root during enumeration. Using the “watch” command, we can see the processes running and being refreshed over time.
All users can view this file. The file monitors the shrunk output folder and executes a binwalk command on each file. This indicates there’s an escalation within the binwalk binary.
Running the binwalk binary, we see that version 2.3.2 is currently installed on the target system.
Using search engines, we can see a binwalk exploit for remote code execution on the system; downloading the PoC and adding a standard PNG file, source IP and Port number as parameters into the PoC code will present a malicious output PNG file called binwalk_exploit.png. Transfer this file onto the target system and copy the file into the /var/www/pilgrimage.htb/shrunk/ folder to align into the malwarescan.sh, program.
As the program scans the file and feeds it into the vulnerable binwalk binary, the shell is returned to our NC listener on our local attacking machine, leading to a complete compromise of the device as the root user.
Reach out to me via Twitter @PR3R00T for any feedback or questions.