LaMeH@CkeR

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%00.jpg .The “%00″ 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.

1. Map Web Application

1.a Explore all visible content (e.g. all linked content)

a. Find all linked content using both passive and active spidering (use Burp Spider). b. Find all none linked content (use Wikto BackEnd, and Google by using inlink, filetype and site keywords). c. Find all default content (use Nikto, Wikto BackEnd). d. Find all cached web site content from search engines (e.g. use the above Google keywords to check cached information).

2. Identify functionality and technologies used

2.a Identify core functionality:

a. Login functions (if concurrent logins are allowed then check for session hijacking ). b. Logout functions (check if proper session termination is done). c. User registration mechanism (to test trust boundaries). d. Password recovery mechanism (the error messages allow user enumeration?). e. Major Web Application functionality (find the purpose of web site functionality).

2.b Identify platforms

a. Programming language used (see ending of web page, php, jsp etc.). b. Web Application platform used (see http header with Burp for banner advertisement or server ip disclosure). c. Web Server used (use Httprint). d. Make sure if any Web Application firewall or proxy, or IPS is in front of the Web Application.

3. Test Client Side

a. Check if client side cookie manipulation is done (with the use of Javascript or VBScript). b. Check if client side session management exists (with the use of Javascript or VBScript). c. Check if client side input validation is not the only input validation used (by passing client validation is trivial). d. Check data transmission by making sure secure flag is set. e. Check data transmission by making sure httpOnly is flag is set. f. Check data transmission by making sure that proper SSL enforcement is applied by requesting pages without the s in https. h. Verify non critical variables are passed through hidden fields (see how core web site functionality uses hidden variables). i. Verify that no Javascript or Html or VBScript comments exits that reveal the web application internals. j. Test all client side components (e.g. decompile Java Applets returned back from the web application, use ollyDebuger to debug activeX controls). k. Test possible function identifiers, and try to perform identifier guessing (e.g. /admin?licenseId=123).

4. Test Authentication Mechanisms

a. Go through the whole authentication mechanism (e.g. locate login mechanism, password recovery mechanism, registration process etc.). b. Test password and username security policies (e.g. validate and try to bypass the default password complexity and make sure each user name is unique and is associated with only one password). c. Test lock out mechanism (e.g. brute force the web application using the Burp intruder) d. Run a brute force attack or a dictionary attack against the web application, then log the errors returned from the web application and make sure there is no information disclosure issues. d. Try to perform user enumeration using the responses from the server (e.g. try login using many different valid usernames with invalid password and analyse the error messages). e. Test for auto generated credentials predictability if applicable (e.g. generate a large amount for usernames and passwords to see how predictable are).

5. Test Session Management Mechanism

a. Test for session fixation. Go to the home page, capture the generated token session, then login, if no new session token is generated then session fixation is possible. b. Capture a large amount of sessions tokens and test for token predictability (Use the Burp sequencer). If the tokens are predictable then there is session fixation issue. c. Login using some valid user credentials then go back to the login page and login using some other user credentials, if no new session token is generated then there is a session fixation issue. d. If the application does not support login but you can access sensitive data (e.g. such as payment details) using an old sessions then there is a session fixation issue. e. If the web application relies only in cookie session, does not distinguish between GET and POST requests and is vulnerable to XSS then is also vulnerable to XSRF attacks. f. If the session token is passed inside URL’s or the Http Header referer then there is a session information disclosure issue (e.g. off site links, web server logs and proxy logs). g. Check if session termination de validates properly the user session by using terminated sessions access data. h. Check if the cookie scope restricts cookies only to the current cookie.

7. Test Access Control

a. Test for user information disclosure using the broken links. c. Test for vertical privilege escalation by replaying requests of users with the same privileges trying to access resources of different users using the same privilege cookie. d. Test for horizontal privilege escalation using the broken links identified earlier and try to replay requests of users with higher privileges using the a low privilege cookie. e. Test for insecure access control implementations.

6. Test Input Based Vulnerabilities

a. Test for SQL injections. b. Test for XSS attacks. c. Test for XSRF attacks (if concurrent logins are allowed and the web application is ). d. Test for Path traversal attacks. e. Test for Perform fuzzing. f. Test for String format attacks. g. Test for command injection issues

7. Test for Web Server Vulnerabilities

a. Check for default content using Nikto and Wikto Back End. b. Check for default user credentials while trying to access administrative control panels. c. Check for Http methods, such as OPTIONS, PUT, DELETE, TRACE and CONNECT. d. Check if WebDav is enabled using a WebDav client. e Check for weak SSL ciphers using SSLdigger or THCSSLCheck. f. Check for directory listing. g. Check Http header injection using the Line Feed character and return carriage character (encoded %0a and %0d).

Reference:

http://portswigger.net/wahh/

The Web Application Hacker’s Handbook: Detecting and Exploiting Security Flaws
Authors: Dafydd Stuttard & Marcus Pinto

1. Map Web Application

1.a Explore all visible content (e.g. all linked content)

By saying all visible content I mean all content that has links inside the targeted website using a web
crawler. A web crawler (also known as a web spider, web robot, or?€”especially in the FOAF community?€”web scutter[1]) is a program or automated script which browses the World Wide Web in a
methodical, automated manner.

Suggested programs:

a. Burp Spider: Burp Spider enables you to obtain a detailed understanding of how a web
application works, avoiding the time-consuming and unreliable task of manually following links, submitting forms and scouring HTML source code.

URL: http://portswigger.net/spider/

b. WebScarab Spider:WebScarab is a Web Application Review tool. It sprang from the designs of the
people inhabiting the WebAppSec list run from SourceForge, for a powerful, free, open tool for reviewing web applications for security vulnerabilities.

URL:http://dawes.za.net/rogan/webscarab/

1.b Explore all none visible content

By saying none linked content I mean all all default, dynamic and none linked content. How? Simple using
the most privileged account to login and the using a crawler and of course Wikto back end and other search engines.

Suggested programs/methods:

a. Wikto back-end: The Back-End miner section in Wikto is used to find interesting files and
directories on a web server. It is using the default database from Nitko to be updated.

URL: http://www.sensepost.com/research/wikto/

b. Google:The keywords filetype, inurl, site, relevant and other keywords can be used to extract
cached and none cached information about the targeted website.

2. Identify functionality and technologies used

2.a Identify core functionality:

a. Login functions (e.g. Are concurrentlogins allowed? Is there a lockout mechanism?).

b. Logout functions (e.g. Is propersession termination is done?).

c. User registration mechanism.

d. Password recovery mechanism (e.g. does it allow user enumeration?).

e. Major Web Application functionality.

2.b Identify platforms

Platform used:

a. Programming language used.

b. Web Application platform used.

c. Web Server used.

Programs suggested:

HttpPrint: HttPrint is a web server fingerprinting tool. It relies on web server characteristics
to accurately identify web servers, despite the fact that they may have been obfuscated by changing the server banner strings, or by plug-ins such as mod_security or servermask.

URL: http://www.net-square.com/httprint/

3. Define Web Application Attack Surface

Associate core functionality and web application content with known vulnerabilities, e.g. file uploading
with path traversal.

4. Test Client Side Functionality

4.a Make sure that no security mechanisms exist in the client side (e.g. client side cookie
manipulation, client side session management, client side input validation).

4.b Test data transmission (e.g. make sure secure flag and httpOnly flag are enabled).

4.c Verify no critical variables are passed through hidden fields, if any, and make sure the application
is not vulnerable to repudiation attacks (e.g. replay old client request to bypass access control mechanisms).

4.d Verify that no comments exits in the content returned back to the client that reveal the internals of
the web application (e.g. Javascript and Html comments).

4.e Test thick client components (e.g. decompile Java Applets returned back from the web application).

Programs suggested:

Firebug: Integrates with Firefox to put a wealth of development tools at your fingertips while you
browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page.

URL:https://addons.mozilla.org/en-US/firefox/addon/1843

5. Test Authentication Mechanisms

5.aGo through the whole authentication mechanism (e.g. locate login mechanism, password recovery mechanism, registration process etc.)

5.b Test password and username security policies (e.g. validate and try to bypass the default password
complexity and then make sure that the each user name is unique and is associated with only one password).

5.c Test lock out mechanism (e.g. Does the web application have a lockout mechanism and how effective is?)

5.d Run a brute force attack and a dictionary attack against the web application, then log the errors
returned from the web application and make sure there is no information disclosure issue.

5.d Try to perform user enumeration using the responses from the server (e.g. try login using many
different valid usernames with invalid password and analyse the error messages).

5.e Test for auto generated credentials predictability (e.g. if usernames and passwords are generated from
the web application, generate a large amount for usernames and passwords to see how predictable are).

5.f Test for unsafe credential transmission (e.g. There is no SSL enforcement, secure and httpOnly flags are not set and hidden fields are used to pass user credentials or critical variables). Verify that no user credentials are passed to the cookie (e.g. XSS attacks), the referrer header (e.g. session fixation attacks) when third party links are allowed inside the web application or the url query string (e.g. web server logs and and internet browsers will save user credentials into the history).

6. Test Session Management Mechanism

Understand what a session is composed from(e.g. Variables in hidden fields, cookies, URL identifiers e.t.c). Understand meaning of session and try to reproduce valid sessions using various user credentials. Test session generation and session termination. Test for session fixation (e.g. try to produce valid sessions, try to replay a request using an old session or replay a request using a from the targeted web application a session ( captured before a successful login) trying to retrieve authenticated pages, after the user has logged in. Try to perform CSRF.

Programs suggested:

Stompy: Stompy is a free tool to perform a fairly detailed black-box assessment of WWW session identifier generation algorithms. Session IDs are commonly used to track authenticated users, and as such, whenever they’re predictable or simply vulnerable to brute-force attacks, we do have a problem.

URL:http://www.securiteam.com/tools/5VP0O2AKAG.html

7. Test Access Control

Look for broken links (e.g. access variables with high user account privileges simply by guessing URL ID’s).

8. Test Input Based Vulnerabilities

Test for:

a. SQL injections

b. XSS attacks

c. XSRF attacks

d. Path traversal attacks

e. Perform fuzzing

10. Test for Web Server Vulnerabilities

Check Http header injection, server banner advertisement, enabled Http methods and supported protocols
that run over Http (e.g. WebDev). Also check Web Server default content and configuration.

Nikto: Is an Open Source (GPL)web server scanner which performs comprehensive tests against web
servers for multiple items, including over 3500 potentially dangerousfiles/CGIs, versions on over 900 servers, and version specific problems on over 250 servers.

URL:http://www.cirt.net/nikto2

Reference [1]:
http://en.wikipedia.org/wiki/Web_crawler