Share this
Path Traversal and The Good Old Days
by Reflare Research Team on Jun 3, 2024 2:41:17 PM
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:
- Initial Request: A legitimate URL might look like this
- Manipulating the URL: An attacker could alter the URL to include a Unicode-encoded traversal sequence
- Bypassing Security: The web server decoded the %c0%af sequence into ../, effectively allowing the URL to navigate up the directory tree.
- 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.
Share this
- August 2024 (1)
- July 2024 (1)
- June 2024 (1)
- April 2024 (2)
- February 2024 (1)
- January 2024 (1)
- December 2023 (1)
- November 2023 (1)
- October 2023 (1)
- September 2023 (1)
- August 2023 (1)
- July 2023 (1)
- June 2023 (2)
- May 2023 (2)
- April 2023 (3)
- March 2023 (4)
- February 2023 (3)
- January 2023 (5)
- December 2022 (1)
- November 2022 (2)
- October 2022 (1)
- September 2022 (11)
- August 2022 (5)
- July 2022 (1)
- May 2022 (3)
- April 2022 (1)
- February 2022 (4)
- January 2022 (3)
- December 2021 (2)
- November 2021 (3)
- October 2021 (2)
- September 2021 (1)
- August 2021 (1)
- June 2021 (1)
- May 2021 (14)
- February 2021 (1)
- October 2020 (1)
- September 2020 (1)
- July 2020 (1)
- June 2020 (1)
- May 2020 (1)
- April 2020 (2)
- March 2020 (1)
- February 2020 (1)
- January 2020 (3)
- December 2019 (1)
- November 2019 (2)
- October 2019 (3)
- September 2019 (5)
- August 2019 (2)
- July 2019 (3)
- June 2019 (3)
- May 2019 (2)
- April 2019 (3)
- March 2019 (2)
- February 2019 (3)
- January 2019 (1)
- December 2018 (3)
- November 2018 (5)
- October 2018 (4)
- September 2018 (3)
- August 2018 (3)
- July 2018 (4)
- June 2018 (4)
- May 2018 (2)
- April 2018 (4)
- March 2018 (5)
- February 2018 (3)
- January 2018 (3)
- December 2017 (2)
- November 2017 (4)
- October 2017 (3)
- September 2017 (5)
- August 2017 (3)
- July 2017 (3)
- June 2017 (4)
- May 2017 (4)
- April 2017 (2)
- March 2017 (4)
- February 2017 (2)
- January 2017 (1)
- December 2016 (1)
- November 2016 (4)
- October 2016 (2)
- September 2016 (4)
- August 2016 (5)
- July 2016 (3)
- June 2016 (5)
- May 2016 (3)
- April 2016 (4)
- March 2016 (5)
- February 2016 (4)