Exploiting Path Traversal - The Creative Way

André Eichhofer

Hey, Today I will show you how to exploit a path traversal vulnerability and I will show you some tricks to get most out of the target system. I will demonstrate this using a real world example. For this demonstration we will assume two preconditions, namely

• the target system is a Linux OS and
• we will only extract data and not escalate to further attacks.

As you know, a path traversal vulnerability allows you to jump out of the server directory and access files on the system. The vulnerability occurs, because of improper sanitization of user input in the source code of a server or web application.

Apache 2.4.49 vulnerability

So, let’s get started. Our example from the real world is a flaw in Apache Web Server 2.4.49 and I will show you some post exploitation tricks. To test the vulnerability, simply use a Linux VM and install the vulnerable Apache version.

Note, as a precondition for exploitation, access to the web server directory in Apache configuration file must be enabled:

<Directory />
    Require all granted
</Directory>

You can exploit the flaw using curl, like this:

curl http://192.168.178.70/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e$2/etc/passwd

Note, the cgi-bin directoy doesn’t necessarly need to exist.

As you can see, you can access the etc/passwd file.

Access interesting files on the target host

As a next step it would be cool to access other interesting files on the target system, like etc/shadow. However, this probably won’t work as you’re only moving with the rights of the server, e.g. www-data, and to access sensible files you need to have root privileges. Nevertheless, you can try it out and if you’re lucky you will get some first information about the target system:

• /proc/version: contains version of the kernel and the operating system
• /etc/aliases
• /etc/hosts: contains internal IP address and possible domain names
• /etc/hostname
• /etc/rc.conf: contains internal ip addresses of the host
• /proc/sys/kernel/hostname
• /home/$USER/.bash_history:
• /home/$USER/.ssh/id_rsa: only accessible with root privileges

Locate the Locate Database

What makes the exploitation tedious is that we can only access specific files on the system and we need to know where these files are sitting. We cannot browse the target system like from a shell. However, as we’re moving in a Linux OS we know that there is a well-known command in many Linux OS: Using locate a user can find files in the system. This command uses a database with an index of the file system. Usually, the database is updated once a week by the system. The location of the database depends on which locate command is installed and it depends on the specific Linux distribution.

There are 2 versions of the locate command available on Linux: mlocate and locate. On Debian when you call locate, automatically mlocate is launched.

The mlocate database usually sits under

• /var/lib/mlocate/mlocate.db

On other Linux distributions, the “original” locate command my be installed. The locate command generates a configuration file under

• /etc/locate.rc

with the path to the database. Usually, you can find the database at

• /var/db/locate.database

So, the next step is to download the locate database, like this:

curl http://192.168.178.70/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e$2/var/db/locate.database

An interesting question is why we can access and download the database at all? Well, because we’re moving with the rights of a process, in our case it may be www-data. And the locate database must be accessible for processes, locate must have access to it’s database.

Read the database offline and profit

As soon as we downloaded to database we can read the target system like an open book.

For example, you can read the database locally using locate -d <database_path>

From know on you can search for very interesting files and access them afterwards live on the target system. Assume that we have compromised a web hoster: In the locate database you should search for *.sql files which are used by the web host. These databases are usually readable by the user agent or web server and may contain password hashes. Other interesting files are

• web server config files
• web server access and error log
• ssh config files and keys

Note, that this attack path depends on the target OS. Also, if you exploit firmware of IOT / OT devices, the locate command will most probably not be installed as this would make no sense.

In this example, I will not demonstrate further escalation like file inclusion or remote code execution. However, knowing the target system will make the next steps more easier.