This is a write-up for the machine “Doctor” from hack the box.
Initial Enumeration
Initial nmap scan:
The machine seems to be running Ubuntu as OS, and we can see 3 open ports:
- Port 22 ssh version 8.2p1
- Port 80 http apache 2.4.41
- Port 8089 splunk
The splunk service is some universal forwarded agent for remote data collection, according to this site. We need a password to access.
Navigating to the web server in port 80 we have a web page with nothing interesting at first sight, all the links send us to the same page and the form doesn’t seem to be active. This email direction is a hint,
we add this doctors.htb to the /etc/hosts file and navigate to the page again.
Running a gobuster scanner from this vhost we find the next web directories:
We proceed to create an account on the site, we got an advice that we have access for 20 minutes. We can then create a message divided into two fields, title and content.
The /archive web directory seems to retrieve an empty page, but if we look at the source code we can see:
This page retrieves some information about the messages submitted to the page. At first it looks like some kind of XML external entity injection is possible but, after a lot of trying with no luck, we switched our suspicious around server side template injection (SSTI). The exploitable field is the title of the message.
We use the methodology explained here to determine the templating language used.
We verify that by running the first payload, then as it doesn’t work, we run the { { 7 * 7 } } and this one does work. Finally to differentiate between twig and jinja2 the { { 7 * ‘7’ } } payload is used. Jinja2 is based in python and twig is based on php. So the first one should return 7777777 while the second one returns 49
Perfect, now we need a working payload to exploit this SSTI vulnerability.
Exploitation
We run the example exploit found here, changing it this way to point it to our IP and to generate a shell.
We set up a listener and when we visit the /archive web we gain a shell in the machine as the user web.
Local Enumeration
The user flag is not into the web's home directory. We only have another user in the machine, shaun. As we can see in the previous capture, the user web is part of the adm group and this means we can read logs.
There is an unusual backup file into the /var/log/apache2/ directory, if we grep it looking for passwords we find this entry:
Seems like someone typed the password instead of the email in the /reset_password page. We try to change to the user shaun with this credentials and have success, we can access the user flag now.
Splunk Exploitation
With the same credentials previously found we are able to access the splunk service in port 8089
Looking for ways to exploit this service we find this post. We read in the post:
The Splunk Universal Forwarded Agent (UF) allows authenticated remote users to send single commands or scripts to the agents through the Splunk API. The UF agent doesn’t validates connections coming are coming from a valid Splunk Enterprise server, nor does the UF agent validate the code is signed or otherwise proven to be from the Splunk Enterprise server. This allows an attacker who gains access to the UF agent password to run arbitrary code on the server as SYSTEM or root, depending on the operating system.
We download the exploit from the github page and proceed to test some of the remote examples, they require having a nc listener to receive the response of the commands.
As explained in the blog post, this exploit can be used to gain persistence in the system, but in this case we are going to just extract the flag we are looking for.
As we have local access we can also use the local version of the exploit, but then we need to tinker with the code because it doesn’t run right away using python3 and we can’t install dependencies for the other version of python we have in the system.