I’ve had some success in the past when finding directory traversal vulnerabilities on Linux/Unix hosts and thought I would share a little post on what I’ve found. The vulnerabilities are often found in the unauthenticated portions (convenient) of management applications such as Webmin or ColdFusion and are frequently running with elevated privileges.

The first step I take is using the vulnerability to access /etc/passwd and, if possible, /etc/shadow. I immediately begin attempting to crack the passwords in /etc/shadow if they were available. While the cracking utility is off and running, I then access /etc/group and look for anyone listed in the ‘root’ group (yikes!) or the ‘wheel’ group. Anyone belonging to these groups either has or is likely to have permission to `su` to root or to run `sudo`.

The next step is to see if any of these users has run a command line tool that required a password to be provided or to see if they fat fingered a command that resulted in the password being stored in the command history. So I directory traverse to the home directory for each user belonging to the ‘root’ or ‘wheel’ groups and attempt to access the various possible history files such as .bash_history, .history, .mysql_history, etc. I search these files for stuff like “pass”, “pwd”, or uses of su/sudo. On several occasions, I have found a user that was typing too fast and tried to `su` to root only to type su + the password together (example: suMyR00tP@ssword).

More often than not, I find a password I can use to access the system over SSH or Telnet in the history files. In a few instances, I’ve also found the root password and been immediately able to `su` to root and in a few cases I’ve found a system configured to allow root logins over SSH. Usually, a password for a user with permission to run `sudo` is enough. If you can login over SSH under an account that has permission to run commands via `sudo`, then it is rarely locked down to prevent which commands can be run. The final step, if you don’t already have the root password to `su` to, is to then simply run `sudo bash`, `sudo sh`, `sudo screen`, or some other variation that results in loading a shell, which will now be running under root.

So the steps laid out in order:

1. Access /etc/passwd and /etc/shadow via directory traversal
2. Immediately attempt cracking hashes in /etc/shadow
3. List off the home directories in /etc/passwd
4. Find users with elevated permissions in /etc/group via the directory traversal
5. Access the history files in each home directory of each user with elevated permissions via the directory traversal
6. Search the history files for passwords
7. Login to the system over SSH/Telnet/whatever using a password found in a history file
8. Sudo to a bash prompt, resulting in root access (example: `sudo bash`)

I know there are several directory traversal tools out there that will automatically attempt to pull certain files via the vulnerability such as /etc/passwd and /etc/shadow. Panoptic is a good one and so is DotDotPwn. Metasploit even has a built in module for this as well. However, I wanted something that kind of put all of this together; getting the home directories, searching the history files, and logging any potential matches for credentials. I also wanted to find another opportunity to use Python, so I build a tool called dirscalate.py. The script will exploit a directory traversal vulnerability and loop through a list of provided history files, attempting to access each history file in each home directory, and for each found file loop through a list of tokens. Any matches of the tokens found in the history files will be logged to a log file.

Program usage:

  usage: dirscalate.py [-h] --link LINK [--histfile HISTFILE] 
                       [--tokens TOKENS] [--logfile LOGFILE] 
                       [--depth DEPTH] [--type TYPE]

  Exploit a directory traversal vulnerability to find sensitive information

  optional arguments:
    -h, --help           show this help message and exit
    --link LINK          the full URL to exploit, replace value in vulnerable
                         parameter with #vulnerability# marker (must include
                         http(s):// (default: None)
    --histfile HISTFILE  the list of history files to search (default:
                         histfile.txt)
    --tokens TOKENS      the list of strings to search for in the history 
                         files (default: tokens.txt)
    --logfile LOGFILE    the logfile to write matches to (default:
                         dirscalate.txt)
    --depth DEPTH        the length of the traversal attempt (default: 10)
    --type TYPE          1 (../), 2 (URL encoded), or 3 (double encoded)
                         (default: 1)

  Example: dirscalate.py --link \
    https://www.victim.com/login.php?test=1&blah=#vulnerability#&id=2 \
    --histfile histfile.txt --tokens tokens.txt --depth 10 --type standard

 
The –link option is required and is used to specify the vulnerable link, marking the vulnerable parameter with #vulnerability#. The –histfile option specifies a list of history files to check for in each home directory, if not provided then it defaults to using histfile.txt in the directory from which dirscalate.py was executed. The –tokens option specifies a list of items to search for in each history file, if not provided then it defaults to using tokens.txt in the directory from which dirscalate.py was executed. The –logfile option specifies the file in which to record any token matches and defaults to saving to dirscalate.txt. The –depth option specifies the number of traversals (../) to use on the vulnerable parameter and defaults to 10. The –type option specifies the type of traversal to use and can be the standard ‘../’ characters, URL encoding of those characters, or double URL encoding of the characters.

The program was tested on one of my hosts with a simple PHP script:

  <?php
    print file_get_contents($_GET['file']);
  ?>

 
Then running the following command within the same directory in which the PHP script was saved (dirvuln.php):

  php -S 1.1.1.1:8222

 
Exploiting the vulnerability using my script was then as simple as:

  dirscalate.py --link http://1.1.1.1:8222/dirvuln.php?file=#vulnerability# \
    --type 1

 
You can download a copy of dirscalate.py here, a sample history file here, and a sample tokens file here.

A good post on finding and exploiting directory traversal vulnerabilities can be found on the carnal0wnage blog.

Happy Hunting!