Server Side Exploitation
For this post, we’ll be taking a more manual approach to exploiting a server-side vulnerability. While there are scripts and Metasploit modules developed to detect and exploit Directory Traversal (or Path Traversal) vulnerability, you will see that it doesn't really require any specialized tools for it. Directory Traversal vulnerability is very easy to identify and exploit. Also, the consequences may be grave if the target system lacks adequate user permission settings. Here's how OWASP describes Path Traversal: *"By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files."*
So let's see step by step how we can do Server Side Exploitation
Step 1: Starting Vulnerable Server
First, let's start our vulnerable server application. Weborf is a small HTTP server for simple file sharing. Versions prior to and including 0.2.12 are vulnerable to attacks that we are going to perform. Start Weborf by typing the command below. By default, it listens on the TCP port 8080.
After that switch to a new tab or open up a new tab by command: Ctrl + Shift + T
Step 2: Browsing to Weborf Homepage
Let's navigate to Weborf homepage using Lynx - a text-based web browser:
You should see a very simple page with a couple of folders. Our target server is up and running. Notice that the main page also displays the Weborf version.
Step 3: Issuing HTTP GET Request
Now let's use GET to issue a request to the same address:
You will see some minimal HTML code for the main page we just visited. Let's get down to business.
Step 4: Testing Vulnerability
One of the most common ways to test the directory traversal vulnerability is to issue a request shown below. As the name suggests, such a request is trying to access a file in a directory that was not intended to be accessed by a web server visitor. In our case, we are trying to read the /etc/passwd file.
Didn't seem to work, did it? We are seeing the same HTML code for the home page.
This doesn't necessarily mean that the server is not vulnerable. There must be some sort of security mechanism in place for validating user input. In the next step, we will see how easy it is to circumvent a weak or incorrectly configured countermeasure.
Step 5: Percent-encoded Request
One of the most common ways to obfuscate malicious requests is to use an encoding. Let's see if we can modify our request so that the input validation mechanism in the Weborf server does not recognize it as malicious. We will use percent-encoding (or URI encoding) to replace the forward slash characters in our request with* %2f* as follows:
A different picture now!
We were able to read a system file, which is definitely not something that a regular web server user should be able to do.
Step 6: Reading Configuration Files
Now that we are capable of reading the local files, we can gather a lot of useful information about the system. Configuration files are always amongst the most valuable for pen-testing. Issue the following command to read the SSH configuration file:
The file is quite big. Remember that we can always pipe the output to more or save it to a file. In this step, we just wanted to verify that we can read it.
Step 7: Checking Privileges
You should get the idea by now: just change the directory/file name at the end of the request and see what else you can read. If we want to do some real damage here, we should try to read the /etc/shadow file to get password hashes. Let's try it.
No luck. Weborf runs with the same privileges as the currently user that's logged in.
Now again switch the tab.
Step 8: Starting Weborf as root
Now start Weborf server again, this time with root privileges:
Now again open a new tab.
Step 9: Reading /etc/shadow File
Re-issue the GET request for /etc/shadow file:
Game over. You can see how a system running a vulnerable web server application with inadequate privileges can be fully compromised via an attack as simple as directory traversal.
Also Read: Android Exploitation