Path Traversal: A Potential Gateway to System Compromise

While working through HTB's Conversor machine—where XSLT execution serves as the entry point—a classic path traversal vulnerability appeared as part of the exploitation chain. This seemingly simple flaw remains one of the most relevant building blocks in offensive security. Though rarely the final objective, it often serves as an initial step that, under the right conditions, can escalate into more severe attacks.

What is Path Traversal?

Path traversal (also known as directory traversal or dot-dot-slash attacks) occurs when an application allows user input to influence file system paths without proper sanitization. By injecting sequences like ../, an attacker can escape the intended directory and access files elsewhere on the system.

A vulnerable request might look like this:

GET /download?file=report.pdf

An attacker could manipulate it to:

GET /download?file=../../../etc/passwd

Beyond Reading Files: The Attack Chain

Path traversal is rarely an end in itself. It functions as reconnaissance—an opportunity to gather information that may enable further exploitation. Depending on system configuration and additional vulnerabilities, the escalation path may follow this pattern:

Path Traversal → Local File Inclusion (LFI) → Remote Code Execution (RCE)

This progression is not guaranteed. Each stage requires specific conditions to be met, and many systems will only be vulnerable to partial exploitation.

Stage 1: Path Traversal — Reconnaissance

The initial exploitation phase focuses on information gathering. Common targets include:

• /etc/passwd — User enumeration
• /etc/shadow — Password hashes (if readable)
• ~/.ssh/id_rsa — Private SSH keys
• Application configuration files containing database credentials
• Source code that may reveal additional vulnerabilities

On Windows systems, targets shift to:

• C:\Windows\System32\config\SAM and SYSTEM — Local password hashes
• C:\inetpub\wwwroot\web.config — Application configuration
• %USERPROFILE%\.ssh\ — SSH keys

Stage 2: LFI — Weaponization

When the application not only reads but includes or processes files, path traversal may evolve into Local File Inclusion. This transition depends on how the application handles the retrieved content.

Common escalation techniques include:

Log Poisoning: Injecting malicious code into server logs (Apache access logs, mail logs, SSH auth logs), then including that log file to trigger execution.

# Poison the log
curl -A "<?php system(\$_GET['cmd']); ?>" http://target/
# Include and execute
http://target/vuln.php?page=../../../var/log/apache2/access.log&cmd=id

PHP Wrappers: Abusing protocol handlers to read source code or inject payloads.

# Read source code as base64
http://target/vuln.php?page=php://filter/convert.base64-encode/resource=config.php

# Execute arbitrary code
http://target/vuln.php?page=data://text/plain,<?php system('id'); ?>

Session File Inclusion: If session data can be controlled, including the session file may allow payload execution.

Stage 3: RCE — Potential Compromise

If code execution is achieved, further actions become possible:

• Establishing a reverse shell for persistent access
• Pivoting to internal network segments
• Privilege escalation through local exploits
• Data exfiltration

However, reaching this stage requires multiple conditions to align: writable locations, executable contexts, and insufficient access controls.

XSLT and Path Traversal

In HTB's Conversor machine, the vulnerability chain begins with XSLT execution—a reminder that path traversal often appears alongside other vulnerabilities. XSLT processors, when misconfigured, can:

• Read arbitrary files using the document() function
• Write files to disk
• Execute system commands in certain implementations

This creates scenarios where XSLT provides the initial foothold, and path traversal extends the reach to sensitive system files.

A proof of concept demonstrating XSLT injection leading to reverse shell execution can be found at ex-cal1bur/XSLT-Injection_reverse-shell.

Defense Strategies

Preventing path traversal requires a defense-in-depth approach:

1. Input Validation: Rejecting any input containing .., /, \, or null bytes
2. Path Canonicalization: Resolving the full path and verifying it remains within allowed directories
3. Chroot/Sandboxing: Isolating the application's file system view
4. Principle of Least Privilege: Running applications with minimal file system permissions
5. WAF Rules: Blocking common traversal patterns at the network edge

# Safe path handling in Python
import os

def safe_file_access(user_input, base_dir):
    requested_path = os.path.realpath(os.path.join(base_dir, user_input))

    if not requested_path.startswith(os.path.realpath(base_dir)):
        raise SecurityException("Path traversal attempt detected")

    return requested_path

Conclusion

Path traversal illustrates how an initial vulnerability can, under specific circumstances, contribute to broader system compromise. In red team operations, it frequently serves as a starting point for further enumeration and potential escalation. The Conversor machine demonstrates how understanding these foundational attack patterns—and how they may chain together—remains essential for security assessment.

This article was inspired by HTB's Conversor machine.