What is Path Traversal?
Web servers generally are set up to restrict public access to a specific portion of the Web server’s file system, typically called the “Web document root” directory. This directory contains the files intended for public access and any scripts necessary to provide Web application functionality.
In a path traversal attack, an intruder manipulates a URL in such a way that the Web server executes or reveals the contents of a file anywhere on the server, including those lying outside the document root directory. Path traversal attacks take advantage of special-characters sequences in URL input parameters, cookies and HTTP request header.[1]
Real world examples of path traversal strings:
../../../../../../../etc
../../../../../../../../../../etc/passwd
../windows\\winhelp.exe
..\\..\\..\\..\\..\\..\\..\\..\\..\\_private/
String examples
Path traversal issues can allow an intruder perform arbitrary code execution, stored XSS attacks or second order SQL injections. By simply uploading malicious code that later on is going to retrieved by a user, uploading a JavaScript file that later is going to be executed by another user or a piece of code that is going to execute an SQL query.
Why Path Traversal happens
A path traversal attack happens because user controllable data is used by the application to access files and directories in the application server or other back end file systems.? A path traversal attack is possible in parts of the web application that legitimate file uploading takes place, but it also can happen in parts of the web application that there are dynamic execution issues.
In a search engine field for example:
$searchForData = $_GET[searchForData ];
eval(’searchForData;’);
Code example in PHP.
A very straightforward example of path traversal attacks using a RFI (Remote File Inclusion attack) vulnerability.Remote File Inclusion attacks allow malicious users to run their own PHP code on a vulnerable website. The attacker is allowed to include his own malicious code in the space provided for PHP programs on a web page. For instance, a piece of vulnerable PHP code would look like this:[3]
include($page . ‘.php’);
This line of PHP code, is then used in URLs like the following example:
http://www.vulnerable.example.org/index.php?page=archive
Because there is no filtering someone can upload malicious PHP code such as a webshell and embed his code to the current file.
Fixing the problem in Web Application
Multiple levels of security should be used to defeat the vulnerability. All Web Application functionality that is responsible for uploading the file (if that is necessary for some reason ) should take into consideration the following counter measures:
1. All user supplied data should be decoded and canonicalized and then check if the user supplied data contain any path traversal sequences such as ../, ..//,..\/, also this measure should filterout the all null characters e.g. ../../../../../../../../../../../../../../../../../../boot.ini.jpg .The “″ sequence is used both to bypass a simple file extension check and to cut off the extension when the file is read and processed by the CGI application.[1]
2. The Web Application should perform a while list filtering removing all non allowed characters or dropping immediately all user supplied data if they do not comply with the white list filter.
3. Use a Chroot environment can be used to create and host a separate virtualized copy of the operating system. in order to restrict the user from accessing the parts of file system that should not.
4. The malicious user trying to perform the path traversal attack has the same privileges with the Web Application process handling the whole interaction. Make sure the Web Application has only the needed privileges to perform it tasks.
5. All malicious activity should be logged, so as to have an understanding of what is attempted.
API used to defeat the path traversal issues:
1. In java is java.io.File object. Use the getCanonicalPath function.
2. In ASP .NET the System.Io.GetFullPath should be used.
Fixing the problem in IIS
The easiest way to tighten an IIS Web server against this and other attacks is to download and run the IISLockdown tool, free from http://download.microsoft.com. URLScan, which is installed when you run IISLockdown, blocks requests that contain unsafe characters. IISLockdown also disables the parent paths setting, which prevents the use of “..” in script and application calls. Finally, IIS Web administrators should check all Web permissions, which provide an extra layer of security to NTFS file permissions, and consider upgrading to IIS 6.0, which provides significantly enhanced default security over previous versions of IIS.[1]
Reference [1]: http://searchsecurity.techtarget.com/tip/1,289483,sid14_gci1134252,00.html
Reference [2]: http://en.wikipedia.org/wiki/Remote_File_Inclusion
Reference [3]: The Web Application Hackers Hand Book, Chapter 10 page 345.
Web servers generally are set up to restrict public access to a specific portion of the Web server’s file system, typically called the “Web document root” directory. This directory contains the files intended for public access and any scripts necessary to provide Web application functionality.
In a path traversal attack, an intruder manipulates a URL in such a way that the Web server executes or reveals the contents of a file anywhere on the server, including those lying outside the document root directory. Path traversal attacks take advantage of special-characters sequences in URL input parameters, cookies and HTTP request header.[1]
Real world examples of path traversal strings:
../../../../../../../etc
../../../../../../../../../../etc/passwd
../windows\\winhelp.exe
..\\..\\..\\..\\..\\..\\..\\..\\..\\_private/
String examples
Path traversal issues can allow an intruder perform arbitrary code execution, stored XSS attacks or second order SQL injections. By simply uploading malicious code that later on is going to retrieved by a user, uploading a JavaScript file that later is going to be executed by another user or a piece of code that is going to execute an SQL query.
Why Path Traversal happens
A path traversal attack happens because user controllable data is used by the application to access files and directories in the application server or other back end file systems.? A path traversal attack is possible in parts of the web application that legitimate file uploading takes place, but it also can happen in parts of the web application that there are dynamic execution issues.
In a search engine field for example:
$searchForData = $_GET[searchForData ];
eval(’searchForData;’);
Code example in PHP.
A very straightforward example of path traversal attacks using a RFI (Remote File Inclusion attack) vulnerability.Remote File Inclusion attacks allow malicious users to run their own PHP code on a vulnerable website. The attacker is allowed to include his own malicious code in the space provided for PHP programs on a web page. For instance, a piece of vulnerable PHP code would look like this:[3]
include($page . ‘.php’);
This line of PHP code, is then used in URLs like the following example:
http://www.vulnerable.example.org/index.php?page=archive
Because there is no filtering someone can upload malicious PHP code such as a webshell and embed his code to the current file.
Fixing the problem in Web Application
Multiple levels of security should be used to defeat the vulnerability. All Web Application functionality that is responsible for uploading the file (if that is necessary for some reason ) should take into consideration the following counter measures:
1. All user supplied data should be decoded and canonicalized and then check if the user supplied data contain any path traversal sequences such as ../, ..//,..\/, also this measure should filterout the all null characters e.g. ../../../../../../../../../../../../../../../../../../boot.ini.jpg .The “″ sequence is used both to bypass a simple file extension check and to cut off the extension when the file is read and processed by the CGI application.[1]
2. The Web Application should perform a while list filtering removing all non allowed characters or dropping immediately all user supplied data if they do not comply with the white list filter.
3. Use a Chroot environment can be used to create and host a separate virtualized copy of the operating system. in order to restrict the user from accessing the parts of file system that should not.
4. The malicious user trying to perform the path traversal attack has the same privileges with the Web Application process handling the whole interaction. Make sure the Web Application has only the needed privileges to perform it tasks.
5. All malicious activity should be logged, so as to have an understanding of what is attempted.
API used to defeat the path traversal issues:
1. In java is java.io.File object. Use the getCanonicalPath function.
2. In ASP .NET the System.Io.GetFullPath should be used.
Fixing the problem in IIS
The easiest way to tighten an IIS Web server against this and other attacks is to download and run the IISLockdown tool, free from http://download.microsoft.com. URLScan, which is installed when you run IISLockdown, blocks requests that contain unsafe characters. IISLockdown also disables the parent paths setting, which prevents the use of “..” in script and application calls. Finally, IIS Web administrators should check all Web permissions, which provide an extra layer of security to NTFS file permissions, and consider upgrading to IIS 6.0, which provides significantly enhanced default security over previous versions of IIS.[1]
Reference [1]: http://searchsecurity.techtarget.com/tip/1,289483,sid14_gci1134252,00.html
Reference [2]: http://en.wikipedia.org/wiki/Remote_File_Inclusion
Reference [3]: The Web Application Hackers Hand Book, Chapter 10 page 345.
No comments:
Post a Comment