Tuesday, April 12, 2011

Path Traversal Attack or Dot-dot Slash

A Path Traversal attack aims to access files and directories that are stored outside the web root folder. By browsing the application, the attacker looks for absolute links to files stored on the web server. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration and critical system files, limited by system operational access control. The attacker uses “../” sequences to move up to root directory, thus permitting navigation through the file system.
This attack can be executed with an external malicious code injected on the path, like the Resource Injection attack. To perform this attack it’s not necessary to use a specific tool; attackers typically use a spider/crawler to detect all URLs available.
This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”.
Why this attack works ?? 
Traditionally, web servers and web applications implement authentication mechanisms in order to control access to files and resources. Web servers try to confine users' files inside a "root directory" or "web document root" which represent a physical directory on the file system; users have to consider this directory as the base directory into the hierarchical structure of the web application. The definition of the privileges is made using Access Control Lists (ACL) which identify which users or groups are supposed to be able to access, modify, or execute a specific file on the server. These mechanisms are designed to prevent access to sensitive files from malicious users (for example, the common /etc/passwd file on a Unix-like platform) or to avoid the execution of system commands.
Many web applications use server-side scripts to include different kinds of files: it is quite common to use this method to manage graphics, templates, load static texts, and so on. Unfortunately, these applications expose security vulnerabilities if input parameters (i.e., form parameters, cookie values) are not correctly validated.

Examples of hostile strings :- 

Encoding and double encoding:
%2e%2e%2f represents ../
%2e%2e/ represents ../
..%2f represents ../ 
%2e%2e%5c represents ..\
%2e%2e\ represents ..\ 
..%5c represents ..\ 
%252e%252e%255c represents ..\ 
..%255c represents ..\ and so on. 
Percent encoding (aka URL encoding)
Note that web containers perform one level of decoding on percent encoded values from forms and URLs.
..%c0%af represents ../ 
..%c1%9c represents ..\ 
OS specific
Root directory:  “ / “ 
Directory separator: “ / “
Root directory: “  <partition letter> : \ “
Directory separator: “ / “ or “ \ ” 
Note that windows allows filenames to be followed by extra . \ / characters.
In many operating systems, null bytes  can be injected to terminate the filename. For example, sending a parameter like:
will result in the Java application seeing a string that ends with ".pdf" and the operating system will see a file that ends in ".doc". Attackers may use this trick to bypass validation routines.

Example of attack :-

The following examples show how the application deals with the resources in use.
In these examples it’s possible to insert a malicious string as the variable parameter to access files located outside the web publish directory.
http://some_site.com.br/get-files?file=../../../../some dir/some file 
http://some_site.com.br/../../../../some dir/some file 
The following URLs show examples of *NIX password file exploitation.
Note: In a windows system an attacker can navigate only in a partition that locates web root while in the Linux he can navigate in the whole disk.
How to Avoid Path Traversal Attack ?? 
All but the most simple web applications have to include local resources, such as images, themes, other scripts, and so on. Every time a resource or file is included by the application, there is a risk that an attacker may be able to include a file or remote resource you didn’t authorize.

How to identify if you are vulnerable

  • Be sure you understand how the underlying operating system will process filenames handed off to it.
  • Don't store sensitive configuration files inside the web root
  • For Windows IIS servers, the web root should not be on the system disk, to prevent recursive traversal back to system directories.

How to protect yourself

  • Prefer working without user input when using file system calls
  • Use indexes rather than actual portions of file names when templating or using language files (ie value 5 from the user submission = Czechoslovakian, rather than expecting the user to return “Czechoslovakian”)
  • Ensure the user cannot supply all parts of the path – surround it with your path code
  • Validate the user’s input by only accepting known good – do not sanitize the data
  • Use chrooted jails and code access policies to restrict where the files can be obtained or saved to



Naviya Nair said...

I have read your blog its very attractive and impressive. I like it your blog.

Java Training in Chennai Core Java Training in Chennai Core Java Training in Chennai

Java Online Training Java Online Training Core Java 8 Training in Chennai Core java 8 online training JavaEE Training in Chennai Java EE Training in Chennai

Priya Kannan said...

Wonderful bloggers like yourself who would positively reply encouraged me to be more open and engaging in commenting.So know it's helpful.
Java Training in Chennai

Path traversal said...

It is really very informative and helpful blog. Thanks for sharing tutorial for path traversal vulnerabilities.

Twitter Delicious Facebook Digg Stumbleupon Favorites More

Design by Vamshi krishnam raju | Bloggerized by Vamshi krishnam raju - Vamshi krishnam raju | Vamshi krishnam raju