Nmap
Let's start this off with an Nmap scan:
Looking at the Nmap scan, we can see that there are only two ports open, Port 22 and Port 80.
As with most HTB boxes, SSH is not normally exploitable until credentials are gained to connect, so let's start with Port 80.
Enumeration
When looking at Port 80, I like to run recon in the background while I enumerate the website manually. So at this point I have ran the following tools before visiting the website:
- Feroxbuster
- GoBuster
- wfuzz
- nikto
While these are running lets view the website being hosted on Port 80:
The website looks like it is for a team of Bug Bounty hunters or Pen testers.
While enumerating the website manually, two input form areas were identified, that could each be tested.
The first was a message form on the main page:
The second, a form titled 'Bounty Report System - Beta', in the /log_submit.php directory (found after trying to attempt to access the Portal Page, then selecting ''here'):
With the second form being in supposed 'Beta', this was more than likely our foothold into this box.
Foothold
So lets see how it processes and stores the information we give it.
First I entered in random information into each input field and clicked Submit, which outputted the following:
Now lets look at this deeper with Burp Suite.
Sending another identical request, the following is shown in Burp:
The above request holds the data in one data string, and can be presumed to be base64, once URL decoded.
Using an online Base64 Encoder and Decoder (https://www.base64encode.org/), the above data held in the 'data' variable is decoded as the following XML data:
It is clear from this that we are looking at some kind of XML External Entities (XML) vulnerability. And so the first thing to do is see if we can maliciously change this XML data to reveal sensitive data. In order for the web server to understand it, we must keep the same format as the original data (including the fact that in the request it is base64 encoded, and then URL encoded).
An example of a malicious XXE payload we could use, and in the correct format, is:
The above attempts to read the /etc/passwd file of the machine. While it is important to enumerate the users on this machine, this is mainly to see if we can read files on the system, via this attack vector.
After base64 encoding, then URL encoding that output, and then placing this data into the 'data' variable within the web request, the web server replies with the following:
Success! The web server replies with the contents of the /etc/passwd file, showing us the users on the system. (We should note these down for later SSH enumeration)
Now we have the ability to read internal files, lets see if we can view the source of any sub directories found from our background directory busting scans (we ran from the start).
Looking through the results of Feroxbuster, one subdirectory has a very interesting name:
DB, usually standing for Database, should light up any pentesters eyes, as these normally contain very sensitive data, such as credentials.
Now lets see if we can read it using the same XXE vulnerability as before.
The following payload was again Base64 encoded, then URL encoded:
And when entered into the 'data' variable, and sent to the web server, we got the following output:
Now the response may look like a load of 'nada', but based on the last character being an '=' sign, this may indicate that this also, is base64 encoded.
Lets throw it in the base64 decoder and see what we get as output:
Just like that, we are given credentials!
SSH Login
Now we have a password, we can match this password with users found from the /etc/passwd contents found earlier, and try and login in via SSH (Port 22).
First we should try the most likely username - development.
(If the credentials didn't work for this user, you could create a text file full of the enumerated username, and then use an SSH brute force attack, specifying the password found)
Great! You have now logged in using those credentials.
(This is your chance to go and grab that user.txt file and submit your first flag for this box)
Privilege Escalation
Looking at the file /home/development/contract.txt, you can see that the development user has been set permissions to 'test' something related to ticket submission and validation. Seeing the word permission should be a good indicator to use the sudo -l command, to view our current permissions as this user:
As you can see from the output, we have permissions to run a ticketvalidator.py script via python3.8 as root. This is very likely our way to escalate privileges, so lets look at the script contents, to understand what it is doing:
Before looking too much into the code, lets see if we have permissions to edit the file, to execute a quick win:
Unfortunately no quick win today! We only have permission to read the file (and execute via python3.8)
Looking at the first section of the code, it asks the user to provide a file to read (the ticket). This is always great, as if we can make this file malicious, then get this script to run as root, we can elevate privileges.
In order for this file we create to be ran correctly, there are a number of requirements that need to be met, to 'validate the ticket', based off the code.
Requirements:
- Must have the 'md extension'
- First 3 lines must read:
# Skytrain Inc
## Ticket to
__Ticket Code:__
- The following lines after TicketCode must start with **
- Any text after ** and before the first '+' sign must be an integer that has a remainder of 4 when divided by 7
- Only when all the above conditions are met will the ** be removed and the line will be run
To help with this, you can find a few invalid tickets in the /opt/skytrain_inc/invalid_tickets directory:
Using one of these as an example, we can copy one and alter it to make them valid, with an additional appended piece of malicious code.
The original ticket is:
However, after altering it to make it valid (Changing T and C to capitals) it becomes:
Running the script and providing it this ticket, the output is that the ticket is now valid.
Now we can just add an 'and' statement to append a reverse shell:
Lets run the ticketValidator.py script using sudo, and provide our malicious .md file (ticket):
Success!!! We have now pwned this machine, now go grab that root flag to finish the box!!
Thank you for reading, please be sure to like the blog if it was helpful, or message me any feedback!
Comentarios