🔎🦶Enumeration/Foothold
BountyHunter is a Easy box from HTB and created by ejedev. This box features a poorly configured XML
form vulnerable to an XXE
. We use this alongside an LFI
(local file inclusion) to get the password from the database. We then enumerate the passwd
file to get the username. Finally we exploit a script used to process train tickets for root.
Before I begin each machine I kick off a full port nmap
scan:
Reviewing the results I can see Ports 22/80 open. I navigate over to Port 80
and I’m presented with:
Bounty Hunters ‘The B Team’ Website
Reviewing the page it appears to be a template and the source shows no relevant information. The contact form is also not functional. The Portal menu entry takes me to a new page which states: Portal under development. Go here to test the bounty tracker.
I can also see the hyperlink takes me to a .php
based link. I kick off FeroxBuster against the IP to have some enumeration in the background.
On the new page I try some database injection and after a few failures, send through some A’s and capture the request with Burp:
Bounty Report System
I can see a data parameter data=
and what appears to be base64
string. I confirm this using the inspector feature within Burp. As I prefer to work outside of Burp for these types of things I use CyberChef to decode the message:
Seeing an XML
request and remembering an article on PayloadsAllTheThings (which I used recently in two other boxes) we can attempt some XML
injection. I used the PHP
based one as I know this is a PHP
based framework.
I review the enumeration running on FeroxBuster to find its finished with some interesting results:
First I see a db.php
file which means a database might actually be present but not susceptible to SQL
based injections. I can also see a resources folder which had README.txt inside:
Nice, now we have more of an idea on what to do. So a database file exists but it is not connected. Going back to Burp I invert the request on CyberChef and change the Payload. I trim down the request so that only one field <title>
; will be displayed making it easier to work with:
I test the payload and I see an a come up as intended. I then edit the request to add in the injection point and select the db.php file as a PHP
file cannot be natively read via the browser and might have some juicy information:
and change the <title>
to be ∾
as that is what the example shows for the response: <foo><result>∾</result></foo>
.
I copy the output and put it into the data=
request within Burp. I get back a response with a decode directly within Burp under the inspector:
I try the password to SSH
into the box however it says incorrect. I use the same exploit to grab the PASSWD
file and see that development has an active login:
/etc/passwd
file showing the development user.
🔝Escalation to Root
I SSH
into the box and type sudo -l
to see if any direct escalation methods are available:
I navigate over to the skytrain_inc directory and review the script. I also see a invalid_tickets directory which provides insight to the type of file it is looking for.
To have a ‘Valid ticket’ requires you to abide by the 6 rules I’ve commented out above. Reviewing the script I create my own .md
file:
I then upload the exploit.md
to the box and run it.
⚠ Attack Machine – Tab 1
⚠ Attack Machine – Tab 2
🎯 Victim Machine
The nc
session pops and I grab the flags: