Identifying and Exploiting Directory Traversals
In this section we will explore Directory Traversal attacks,
also known as path traversal attacks.
This type of attack can be used to access sensitive files on a web server
and typically occurs when a web application is not sanitizing user input.
For a web application to show a specific page,
a web server provides the file from the file system.
These files can be located in the web root directory or one of it’s subdirectories.
While it’s important to understand how to exploit
Directory Traversal vulnerabilities,
it is also crucial that we can identify them.
We should always check for vulnerabilities by hovering over all buttons,
checking all links,
navigating to all accessible pages, and, if possible,
examining the page’s source code.
Links can be an especially valuable source of information,
providing parameters or other data about the application.
For example, if we find the following link,
we can extract vital information from it.
First,
login.php indicates that the web application uses PHP.
We can use this information to develop assumptions
about how the web application works,
which is helpful for the exploitation phase.
Second, the URL contains a language parameter with an HTML page as its value.
In a situation like this,
we should try to navigate to the file directly.
If we can successfully open it,
we can confirm that en.html is a file on the server,
meaning we can use this parameter to try other file names.
We should always examine parameters closely when they use files as a value.
Third, the URL contains a directory called cms.
This is important information indicating that the web application
is running in a subdirectory of the web root.
Let’s review a case study next.
We’ll begin by examining the Mountain Desserts web application.
To access it,
we’ll need to update the /etc/hosts file on our Kali machine to use the DNS name.
We will use this hostname for both the current and following demonstrations.
Next, let’s browse to the target web application.
The navigation bar displays a file named index.php,
so we can conclude that the web application uses PHP.
To gather more information about the page’s structure,
we should hover over all buttons and links,
collecting information about parameters and the different pages we come across.
At the bottom of the page, we’ll find a link labeled “Admin”.
We know the web application uses PHP and a parameter called “page”,
so let’s assume this parameter is used to display different pages.
When we click on the link,
we receive an error message stating the page is currently under maintenance.
This is an important detail for us,
since it reveals that information is shown on the same page.
In this case,
we’ll make a few assumptions about how the web application could be developed
to behave in such a way.
For example, when we open admin.php,
we’ll notice the same message that was shown after clicking the “Admin” link.
This message indicates the web application
includes the content of this page via the page parameter
and displays it under the “Admin” link.
We can now try to traverse directories in the potentially-vulnerable parameter.
We’ll specify a relative path to /etc/passwd
to test the page parameter for directory traversal.
We’re provided with the contents of /etc/passwd.
We successfully leveraged the directory traversal vulnerability
by using a relative path.
In most cases, the web server is run in the context of a dedicated user.
These users usually have limited access permissions on the system.
However, users and administrators
often intentionally set file access permissions
to be very permissive or even world-readable.
Sometimes this occurs due to time constraints in deployment
or less-mature security programs.
This means we should always check for the existence of SSH keys
and their access permissions.
SSH keys are usually located in a folder under the home directory of a user.
Fortunately for us,
/etc/passwd also contains the home directory paths of all users.
The output of /etc/passwd shows a user called offsec.
Let’s specify a relative path for the vulnerable “page” parameter
to try and display the contents of the user’s private key.
We successfully retrieved the private key for the offsec user.
Reviewing the output, we’ll notice that its formatting is a bit messy.
During web application assessments,
we should understand that as soon as we’ve identified a possible vulnerability,
such as with the “page” parameter in this case,
we should not rely on a browser for testing.
Browsers often try to parse or optimize elements for user friendliness.
When performing web application testing,
we should mainly use tools such as Burp,
cURL, or a programming language of our choice.
Let’s use curl to retrieve the SSH private key as we did with the browser.
The SSH private key is formatted better using curl than in the browser.
Let’s copy the output and paste it into a file
called dt_key in our home directory.
Let’s use the private key to connect to the target system
via SSH on port 2222.
We can use the -i parameter
to specify the stolen private key file
and -p to specify the port.
Before we can use the private key,
we’ll need to modify the permissions of the dt_key file.
If we don’t,
the ssh program will throw an error
stating that the access permissions are too open.