KNOX D3: path traversal

How to exploit Directory traversal vulnerability?

<div dir="ltr" style="text-align: left;" trbidi="on">Backtrack has lots of tools for web-application testing. Directory traversal is one of the critical vulnerability in web-application. Previously i post about <a href="http://tipstrickshack.blogspot.com/2013/02/how-to-bypassing-filter-to-traversal_8831.html" target="_blank">what is directory traversal & how to bypass its filter</a> , but that process is manual, it can consume lots of time.But in bactrack automatic tools are available for this test which is DOTDOTPWN. If you are on other distro , then you can download it form <a href="http://dotdotpwn.blogspot.com/" target="_blank">here</a>. It's a very flexible intelligent fuzzer to discover traversal directory vulnerabilities in software such as HTTP/FTP/TFTP servers, Web platforms such as CMSs, ERPs, Blogs, etc. Also, it has a protocol-independent module to send the desired payload to the host and port specified. On the other hand, it also could be used in a scripting way using the STDOUT module. It's written in perl programming language and can be run either under *NIX or Windows platforms. It's the first Mexican tool included in BackTrack Linux . <h3 style="text-align: left;">Fuzzing modules supported in this version: </h3><div style="text-align: left;"></div> - HTTP - HTTP URL - FTP - TFTP - Payload (Protocol independent) - STDOUT <a name="more"></a> ./dotdotpwn.pl -m  http-url -S -u https://localhost/mutillidae/index.php?page=TRAVERSAL -k root -o unix    <div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBGsz8liuK3ExRPc9ZN4PzEC5qECzl4QCBqPvrtTXqSU9cGDNFwNb657ne-lzSidwu5Pn1WLgdOjBR1QNNZNGlUCf2UtnGnmClBsWwK-LPXStBWh5S5GL3RezcUHywqvU2_Hc8GM9oK7Cj/s1600/Path-traversal.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="path-traversal" border="0" height="206" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBGsz8liuK3ExRPc9ZN4PzEC5qECzl4QCBqPvrtTXqSU9cGDNFwNb657ne-lzSidwu5Pn1WLgdOjBR1QNNZNGlUCf2UtnGnmClBsWwK-LPXStBWh5S5GL3RezcUHywqvU2_Hc8GM9oK7Cj/s320/Path-traversal.PNG" title="path-traversal" width="320" /></a></div> In below figure; you can see vulnerable URL where directory traversal is applicable. <div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicV10V1i-Wo9atneHCv0BoOXRZs-qVygjFKu-JfD51mowuio_T67lTvCg3CnzX5igq2yaGcw9u-a3UazKP8OuMkgOf68gSCGVIutO3hkGDjOaDUXQsFu6srr-pPnHRifSKF66Wy7VLBf8F/s1600/path-traversal-2.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="path-traversal" border="0" height="230" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicV10V1i-Wo9atneHCv0BoOXRZs-qVygjFKu-JfD51mowuio_T67lTvCg3CnzX5igq2yaGcw9u-a3UazKP8OuMkgOf68gSCGVIutO3hkGDjOaDUXQsFu6srr-pPnHRifSKF66Wy7VLBf8F/s320/path-traversal-2.PNG" title="path-traversal" width="320" /></a></div></div>

How to exploit Directory traversal vulnerability?

Backtrack has lots of tools for web-application testing. Directory traversal is one of the critical vulnerability in web-application. Previo...

+ Read more »

How to Bypassing Filter to Traversal Attacks ?

<div dir="ltr" style="text-align: left;" trbidi="on">Bypassing Filter to Traversal Attacks If your initial attempts to perform a traversal attack, as described previously, are unsuccessful, this does not mean that the application is not vulnerable. Many application developers are aware of path traversal vulnerabilities and implement various kinds of input validation checks in an attempt to prevent them. However, those defenses are often flawed and can be bypassed by a skilled attacker. The first type of input filter commonly encountered involves checking whether the filename parameter contains any path traversal sequences, and if so, either rejects the request or attempts to sanitize the input to remove the sequences. This type of filter is often vulnerable to various attacks that use alternative encodings and other tricks to defeat the filter. These attacks all exploit the type of canonicalization problems faced by input validation mechanisms Always try path traversal sequences using both forward slashes and backslashes. Many input filters check for only one of these, when the file system may support both. Try simple URL-encoded representations of traversal sequences, using the following encodings. Be sure to encode every single slash and dot within your input: dot                            %2e forward slash           %2f backslash                  %5c <h3>Try using 16-bit Unicode–encoding:</h3> dot                           %u002e forward slash          %u2215 backslash                %u2216 <h3>Try double URL–encoding:</h3> dot                        %252e forward slash         %252f backslash                %255c <h3>Try overlong UTF-8 Unicode–encoding:</h3> dot                        %c0%2e       %e0%40%ae    %c0ae etc. forward slash        %c0%af       %e0%80%af      %c0%2f etc. backslash              %c0%5c       %c0%80%5c      etc. You can use the illegal Unicode payload type within Burp Intruder to generate a huge number of alternate representations of any given character, and submit this at the relevant place within your target parameter. These are representations that strictly violate the rules for Unicode representation but are nevertheless accepted by many implementations of Unicode decoders, particularly on the Windows platform. If the application is attempting to sanitize user input by removing traversal sequences, and does not apply this filter recursively, then it may be possible to bypass the filter by placing one sequence within another. For example: ....// ....\/ ..../\ ....\\ The second type of input filter commonly encountered in defenses against path traversal attacks involves verifying whether the user-supplied filename contains a suffix (i.e., file type) or prefix (i.e., starting directory) that the application is expecting. Some applications check whether the user-supplied file name ends in a particular file type or set of file types, and reject attempts to access anything else. Sometimes this check can be subverted by placing a URL encoded null byte at the end of your requested filename, followed by a file type that the application accepts. <h3 style="text-align: left;">For example:</h3><div style="text-align: left;"> ../../../../../boot.ini.jpg The reason this attack sometimes succeeds is that the file type check is implemented using an API in a managed execution environment in which strings are permitted to contain null characters (such as String.endsWith() in Java). However, when the file is actually retrieved, the application ultimately uses an API in an unmanaged environment in which strings are null-terminated and so your file name is effectively truncated to your desired value. A different attack against file type filtering is to use a URL-encoded newline character. Some methods of file retrieval (usually on Unix-based platforms) may effectively truncate your file name when a newline is encountered: ../../../../../etc/passwd%0a.jpg Some applications attempt to control the file type being accessed by appending their own file type suffix to the filename supplied by the user. In this situation, either of the preceding exploits may be effective, for the same reasons. Some applications check whether the user-supplied file name starts with a particular subdirectory of the start directory, or even a specific file name. This check can of course be trivially bypassed as follows: wahh-app/images/../../../../../../../etc/passwd If none of the preceding attacks against input filters are successful individually, it may be that the application is implementing multiple types of filters, and so you need to combine several of these attacks simultaneously (both against traversal sequence filters and file type or directory filters). If possible, the best approach here is to try to break the problem down into separate stages. For example, if the request for diagram1.jpg is successful, but the request for foo/../diagram1.jpg fails, then try all of the possible traversal sequence bypasses until a variation on the second request is successful. If these successful traversal sequence bypasses don’t enable you to access /etc/passwd, probe whether any file type filtering is implemented and can be bypassed, by requesting diagram1.jpg.jpg Working entirely within the start directory defined by the application, try to probe to understand all of the filters being implemented, and see whether each can be bypassed individually with the techniques described. Of course, if you have white box access to the application, then your task is much easier, because you can systematically work through different types of input and verify conclusively what filename (if any) is actually reaching the file system. </div></div>

How to Bypassing Filter to Traversal Attacks ?

Bypassing Filter to Traversal Attacks If your initial attempts to perform a traversal attack, as described previously, are unsuccessful, thi...

+ Read more »

Path traversal vulnerabilities Tutorial

<div dir="ltr" style="text-align: left;" trbidi="on">Path traversal vulnerabilities arise when user-controllable data is used by the application to access files and directories on the application server or other back-end file system in an unsafe way. By submitting crafted input, an attacker Exploiting Path Traversal may be able to cause arbitrary content to be read from, or written to, anywhere on the file system being accessed. This often enables an attacker to read sensitive information from the server, or overwrite sensitive files, leading ultimately to arbitrary command execution on the server. Consider the following example, in which an application uses a dynamic page to return static images to the client. The name of the requested image is specified in a query string parameter: https://wahh-app.com/scripts/GetImage.aspx?file=diagram1.jpg When the server processes this request, it performs the following steps: 1. Extracts the value of the file parameter from the query string. 2. Appends this value to the prefix C:\wahh-app\images\. 3. Opens the file with this name. 4. Reads the file’s contents and returns it to the client. The vulnerability arises because an attacker can place path traversal sequences into the file name in order to backtrack up from the image directory specified in step 2 and so access files from anywhere on the server. The path traversal sequence is known as “dot-dot-slash,” and a typical attack would look like this: https://wahh-app.com/scripts/GetImage.aspx?file=..\..\windows\repair\sam When the application appends the value of the file parameter to the name of the images directory, it obtains the following path: C:\wahh-app\images\..\..\winnt\repair\sam The two traversal sequences effectively step back up from the images directory to the root of the C: drive, and so the preceding path is equivalent to this: C:\winnt\repair\sam Hence, instead of returning an image file, the server actually returns the repair copy of the Windows SAM file. This file may be analyzed by the attacker to obtain usernames and passwords for the server operating system. In this simple example, the application implements no defenses to prevent path traversal attacks. However, because these attacks have been widely known about for some time, it is common to encounter applications that implement various defenses against them, often based on input validation filters. As you will see, these filters are often poorly designed and can be bypassed by a skilled attacker. </div>

Path traversal vulnerabilities Tutorial

Path traversal vulnerabilities arise when user-controllable data is used by the application to access files and directories on the applicati...

+ Read more »