Path Traversal and The Good Old Days

Why do old cybersecurity vulnerabilities like path traversal still pose risks to contemporary digital infrastructures? After multiple decades, their enduring presence shows us there is still much we can learn from the past.

First Published 3rd June 2024

Throwback tech reminds us of timeless threats.

5 min read  |  Reflare Research Team

Vulnerability Hangover

If you have been following infosec news recently, you probably came across the news about CVE-2024-24919. Apparently, attackers have been exploiting a zero-day vulnerability in Check Point Security Gateways to gain access to corporate networks.

What is interesting, though, is that behind this vulnerability is a more than two-decade-old class of vulnerability known as path traversal. For many of us in cybersecurity who started our journey in the late '90s or early 2000s, this vulnerability class holds a special place. Today, we write about one of the most well-known vulnerabilities in the history of cybersecurity. Grab your coffee and read our story.

A Walk Down Memory Lane: The Unicode Vulnerability

In the cybersecurity field, many practitioners recall notable vulnerabilities that underscored the importance of web application security. One such vulnerability is the Unicode vulnerability in Microsoft's Internet Information Services (IIS), discovered two decades ago. Back in the early 2000s, the discovery of the Unicode vulnerability in IIS 4.0 and 5.0 sent shockwaves through the cybersecurity community. This vulnerability, often referred to as the "Dot-Dot-Slash" or "Unicode" attack, exploited improper handling of Unicode-encoded URLs by the IIS server. The exploitation technique was relatively simple yet highly effective, making it a landmark case in the history of web security.

At the core of this vulnerability was the web server's failure to properly sanitise and decode Unicode characters in URLs. Attackers discovered that by encoding the ../ sequence, used to navigate up directories, in Unicode format (e.g., %c0%af or %c1%1c), they could bypass security mechanisms that typically blocked such traversal attempts.

Here’s a step-by-step breakdown of how the attack worked:

1. Initial Request: A legitimate URL might look like this
   
2. Manipulating the URL: An attacker could alter the URL to include a Unicode-encoded traversal sequence
   
3. Bypassing Security: The web server decoded the %c0%af sequence into ../, effectively allowing the URL to navigate up the directory tree.
   
   
4. Executing Commands: Once the server processed this URL, it would execute the command specified in the query string (cmd.exe?/c+dir), allowing the attacker to list directory contents or execute other commands.

The implications of this vulnerability were severe. This vulnerability highlighted the critical importance of proper input validation and the dangers of relying on insufficiently sanitised user inputs.  By exploiting this vulnerability, attackers could:

• Access Sensitive Files: By navigating the directory structure, attackers could access configuration files, user data, and other sensitive information stored outside the web root directory.
• Execute Arbitrary Commands: Gaining access to cmd.exe enabled attackers to run arbitrary system commands, potentially leading to full system compromise.
• Remote Code Execution: With the ability to execute commands, attackers could upload and run malicious scripts, further compromising the server and its data.

How Path Traversal Works

Today, vulnerabilities similar to “dot-dot-slash” are known as path-traversal. Path traversal attacks take advantage of the way applications such as web servers process file paths. For example, web servers typically have a root directory, and any file access outside this directory is usually restricted. However, if an application allows user inputs to directly influence file paths without proper validation or sanitization, attackers can manipulate these inputs to escape the root directory.

In most operating systems, ../ is used to navigate to the parent directory. By repeating this sequence, attackers can move up the directory tree to access restricted areas. For example, the sequence ../../ moves two directories up from the current directory.

In some cases, attackers might use null byte injection to terminate the string prematurely, bypassing certain security checks. This method involves appending a null byte (%00 in URL encoding) to the end of a file path. For instance:

Here, the null byte might cause the application to ignore the .jpg extension, thus serving the sensitive file.

Here is another example, consider a web application that allows users to view their profile pictures. The URL for fetching the image might look something like this:

An attacker can exploit a path traversal vulnerability by modifying the filename parameter to traverse the directory structure. For example:

In this case, the application may read and return the contents of the /passwd file, which contains sensitive information about the system's user accounts.

Impact of Path Traversal Attacks

Path traversal vulnerabilities can have severe consequences for both the application and its users. Some of the potential impacts include:

Input Validation and Sanitization: Always validate and sanitise user inputs to ensure they do not contain malicious sequences. Reject inputs that contain ../ or other directory traversal characters. Use whitelisting to allow only specific, valid inputs.

• Use Secure APIs: Use secure file APIs that do not allow arbitrary file paths. For example, avoid using functions that take user inputs directly as file paths. Instead, use predefined paths or mappings.
• Implement Least Privilege: Configure your web server and application with the principle of least privilege. Ensure that the web server has access only to the necessary directories and files, and restrict access to sensitive areas.
• File System Restrictions: Configure the file system to prevent directory traversal. Use tools and features provided by the operating system to restrict file access. For example, use chroot jails or containerization to isolate the application.
• Error Handling: Handle errors securely by not disclosing detailed information about the file system or the application structure. Provide generic error messages to the users while logging detailed errors for administrators.
• Regular Security Audits: Perform regular security audits and code reviews to identify and fix potential vulnerabilities. Use automated tools to scan for path traversal vulnerabilities and other security issues.
  
  

Understanding the Path Less Travelled

Path traversal vulnerabilities have existed for decades, pose a significant risk to web applications, and can lead to serious security breaches. By explaining how they can be exploited and how you can implement robust security measures against them, we aim to help you protect your applications and users from potential harm.

Now, you should speak with your team and do the same.