Utilize enumeration and web enumeration techniques to identify vulnerabilities. Engage in exploiting Server-Side Template Injection (SSTI) and implement privilege escalation strategies to enhance your access. This lab is designed to capitalize on your skills in vulnerability exploitation.

Phase 1: Reconnaissance — Discovering the Attack Surface

Step 1: Network Scanning

I started with a fast port sweep to map live ports and services, then used a targeted service/version scan on discovered ports.

Findings: The host exposed four notable TCP services. The most relevant for initial access were an HTTP server on port 80 and an additional web API on port 5000 (identified as a Flask/Werkzeug application). Another TCP port responded to raw TCP probes (31337) but was not HTTP.

Foothold — exploring the web services

I browsed the application on port 80 first to gather context about the target application and then moved to the service on port 5000.

What I observed

• Port 5000 hosted a ticketing-style API with endpoints to create and view tickets (title/description)
• Several existing tickets contained helpful clues — e.g., probable usernames and internal references — that informed subsequent authentication attempts.

After checking port 80, I navigated to the service on port 5000. The page presented several links and documents that appeared to belong to an internal ticketing system — a promising attack surface.

I went through the tickets exposed on port 5000. While reading them, I came across a few entries that stood out — they contained hints that could be useful for authentication. These tickets revealed possible usernames.

The browser wouldn't render anything on port 31337, which suggested a non-HTTP service. I switched to a raw TCP connection using nc to inspect the banner and interaction.

SSTI Exploitation

Vulnerability Identification

Analysis of the ticketing system on port 5000 revealed a direct reflection of user-supplied content in rendered templates. Leveraging legitimate credentials obtained through support ticket analysis (guest: guest), authenticated API access was established.

Proof-of-Concept Development

Initial SSTI confirmation was achieved using standard template evaluation tests:

{{ self._TemplateReference__context.cycler.__init__.__globals__.os.popen('COMMAND').read() }}
```__

While adding tickets, I noticed user-supplied fields were rendered in server-side templates. A safe, non-malicious test confirmed that expressions in the ticket content were evaluated by the server template engine, indicating an SSTI (Server-Side Template Injection) vulnerability.

What this means

• If the template engine evaluates user input, it can allow arbitrary code execution within the application context.

A successful callback was received, establishing persistent access to the target system.

Phase 3: Privilege Escalation — PwnKit Exploitation

Local Enumeration

With a shell as an unprivileged user, I performed standard local enumeration to identify potential escalation vectors:

Post-exploitation enumeration identified binaries with elevated privileges:

find / -perm -4000 2>/dev/null

The pkexec binary was discovered with the SUID bit set, presenting an opportunity for privilege escalation.

Vulnerability Research

Public exploit research identified CVE-2021–4034 (PwnKit) as applicable to the target environment. The vulnerability provides unauthorized privilege escalation through improper argument handling in pkexec.

Findings and Risk Assessment

Critical Risk Factors Identified

1. Template Engine Misconfiguration: Unsanitized user input processed through Jinja2 templates enabled arbitrary code execution
2. Insecure Permissions: SUID bit on pkexec without proper mitigation controls enabled, privilege escalation
3. Limited Access Controls: Weak authentication credentials exposed API functionality

Remediation Recommendations

Immediate Actions

1. Implement proper input sanitization for all user-supplied template variables
2. Restrict SUID permissions on non-essential binaries
3. Enforce strong authentication and access control policies.

Conclusion

The DJINN 3 box illustrates a common and dangerous chain: an application-layer injection (SSTI) led to command execution, which, combined with an improperly configured SUID binary, resulted in a full system compromise. Fixes involve both secure development practices and system hardening.