adam's notes

Lab - Performing and Detecting Directory Traversal and Command Injection

Scenario

In this lab, you will perform directory traversal and command injection attacks, then investigate the results.

As a cybersecurity analyst, you are working to discover weaknesses and vulnerabilities that your organization, Structureality Inc., needs to mitigate throughout its internal network. In this lab, you will perform directory traversal abuse against the company website. Next, you will investigate the website for evidence and IoCs (Indications of Compromise) of directory traversal attacks. Next, you will perform command injection attacks against the company website. Finally, you will investigate the website’s logs for evidence and IoCs related to command injection.

Understand your environment

You will be working from a virtual machine named KALI, hosting Kali Linux, and a virtual machine named LAMP, hosting Ubuntu Server. You will initially use KALI to perform the attacks targeting the DVWA website hosted on the LAMP VM, and then you will work from LAMP to conduct the investigation.

Directory traversal

Directory traversal, or file path traversal, represents a web security flaw that enables an attacker to read various files on the web server where an application is running. This may encompass application code, backend system credentials, data, and sensitive operating system files. The vulnerability emerges when an application employs data that is controllable by the user (user-provided/untrusted data) to unsafely access files and directories on the application server or another backend file system. By providing manipulated input, an attacker could potentially read arbitrary content from any location on the file system being accessed, typically with the same access level as the application or user executing the script.

DVWA

DVWA or Damn Vulnerable Web Application is a safe and legal security playground that security professionals can use to improve their skills and learn tools and techniques related to web attacks and exploitations. DVWA is designed to be installed into a private (i.e., non-Internet) lab environment for internal use. Do NOT install DVWA on a production or an Internet-accessible system.

  1. Connect to the KALI VM.

  2. Launch the Firefox browser.

  3. In the Firefox address bar, enter dvwa.structureality.com

  4. If prompted, type admin and password into the Username and Password fields, respectively, then select Login.

  5. The Welcome to Damn Vulnerable Web Application! page should be displayed.

Info

If you scroll to the bottom of any DVWA page, you will see a footer that indicates several values, including the security level. To change the security level, select DVWA Security from the left-side navigation menu bar, make a selection from the pull-down list, then select Submit. This lab assumes the default security level of Low.

  1. In the left-side navigation menu bar, select File Inclusion.

  2. The Vulnerability: File Inclusion page should be displayed.

  3. Notice the URL displayed in the Firefox address bar: dvwa.structurealty.com/vulnerabilities/fi/?page=include.php

  4. Modify the URL to add “blah/” into the URL as follows:

dvwa.structurealty.com/vulnerabilities/fi/?page=blah/include.php

This is an initial test to verify that the “blah/” directory does not exist. This should result in a blank page (although the DVWA header and left-side menu will still be displayed).

  1. Modify the URL to add “blah/../” into the URL as follows:
dvwa.structurealty.com/vulnerabilities/fi/?page=blah/../include.php

This is a test to determine if the website supports the “change to parent directory” instruction. If so, you should see the “Vulnerability: File Inclusion” page (which was displayed when you first selected the File Inclusion item from the left-side navigation menu bar)

  1. Modify the URL to attempt to access the “etc/passwd” file as follows:
dvwa.structurealty.com/vulnerabilities/fi/?page=etc/passwd

This attempt purposefully does not have a leading slash in front of the etc directory.

This test checks to see if the website supports relative references to a known file. In this instance, you should see a blank result.

  1. Modify the URL to attempt to access the “/etc/passwd” file as follows:
dvwa.structurealty.com/vulnerabilities/fi/?page=/etc/passwd

The only difference between this and the previous URL test is the inclusion of the leading forward slash before the etc directory name.

This test checks to see if the website supports absolute references to a known file. In this instance, you should see the display of the contents of the /etc/passwd file. This implies that you do not need to use numerous changes to parent directory instructions to reach the root of the drive. You can simply provide an absolute reference to a file.

  1. Modify the URL to attempt to access the “/etc/passwd” file using a change to parent instruction as follows:
dvwa.structurealty.com/vulnerabilities/fi/?page=../etc/passwd

This URL attempts to move up one parent directory before attempting to enter the etc directory. This should have a blank result. This indicates that the etc directory is not located in the immediate parent of the web root directory for the current website.

  1. Add additional ”../” in front of the etc directory reference to create a relative reference URL to view the passwd file.

    • How many “change to parent” operations are needed to create a relative URL reference to view the passwd file?
    • Answer: ||6||

  2. Attempt to access the shadow file using the following URL:

dvwa.structurealty.com/vulnerabilities/fi/?page=/etc/shadow

This should result in a blank page. That is because while there is a shadow file present, it is only accessible to the root account, not the web visitor account you are operating under. Notice that this means there is no distinction between when you type in an incorrect reference to a file you can access versus when you type in a correct reference to a file that you do not have permission to access.

  1. Determine the OS version through directory traversal by accessing the version file from the /proc directory using the following URL:
dvwa.structurealty.com/vulnerabilities/fi/?page=/proc/version

  1. Since every process has a file in the proc directory, you can retrieve lots of information through this technique. Experiment with the following filenames from the /proc directory:

    • cpuinfo
    • devices
    • locks
    • meminfo
    • misc
    • modules
    • uptime

  2. Close Firefox.

Directory traversal can be used to access any file regardless of its directory container as long as the web user context has read privileges to the file. This vulnerability abuse technique will be used in many subsequent labs.

Investigate directory traversal abuse

As the cybersecurity analyst, you have been tasked with investigating the company website for potential directory traversal abuse events.

  1. Connect to the LAMP virtual machine and sign in as lamp using Pa$$w0rd as the password.

  2. Elevate to use root privileges by entering: sudo su and then entering Pa$$w0rd as the password.

  3. Enter cd /var/log/apache2 to change into the apache2 log directory.

  4. Enter ls -l to view the log filenames, sizes, and timestamps.

  5. Enter less access.log to view the website’s access.log. Look over the log for anything interesting.

You need to ‘ignore’ the directory path element of “/vulnerabilities/fi/” as this is the obvious name of the HTML document on the DVWA (Damn Vulnerable Web Application) that is designed to demonstrate file inclusion abuse and is vulnerable to directory traversal. In a real-world situation, you will not see obvious terms in the URL.

  1. Starting from the top of the access.log file (i.e., the oldest entry in the log), look down through the entries to find the one with the following as its HTTP request:
"GET /vulnerabilities/fi/?page=blah/include.php HTTP/1.1"

This was your first direct URL modification submission where you added blah/ as a guessed directory name. However, this is not evidence of directory traversal. It is simply an attempt to access a file from a non-existent directory. On its own, this is a record that could be benign or an element of reconnaissance. Or, if malicious, it is only an example of attempting to gain access to hidden content (i.e., files on a web server that are not linked to from existing web documents).

  1. The next log record entry should have the following HTTP request:
"GET /vulnerabilities/fi/?page=blah/../include.php HTTP/1.1"

This is direct evidence of a directory traversal. The character string ”../” is the change to parent function and is used to perform directory traversal.

Info

The change to parent function is only needed when attempting to access a directory that is not directly addressable or accessible through a standard URL. Most web servers will limit visitor access to just the contents of the web root directory. However, the change to parent function is often used to violate that limitation to access other directories elsewhere on the storage of the web server. In some instances, a basic character filter is used to block the use of the ”../” character string. This type of filter can be bypassed using alternate or obfuscation coding, such as ”..%2f” (using percent-encoding to reference ASCII characters with a HEX position reference) or ”..%u2215” (using 16-bit Unicode encoding) or ”..%252f” (using double percent-encoding (where the percent sign is itself percent-encoded)) or ”..%c0%af” (using overlong UTF-8 Unicode encoding).

  1. Further into the access.log, you should see a record entry with the following HTTP request:
"GET /vulnerabilities/fi/?page=/etc/passwd HTTP/1.1"

This is evidence that someone was able to retrieve the contents of this file using an absolute reference. This is evidence of directory traversal as a directory and file outside of the web root were accessed via URL manipulation.

  1. There should then be a series of log entries with the following HTTP requests:
"GET /vulnerabilities/fi/?page=../etc/passwd HTTP/1.1" "GET /vulnerabilities/fi/?page=../../etc/passwd HTTP/1.1" "GET /vulnerabilities/fi/?page=../../../etc/passwd HTTP/1.1" "GET /vulnerabilities/fi/?page=../../../../etc/passwd HTTP/1.1" "GET /vulnerabilities/fi/?page=../../../../../etc/passwd HTTP/1.1" "GET /vulnerabilities/fi/?page=../../../../../../etc/passwd HTTP/1.1"

This is a collection of records that indicates the visitor is probing the environment using directory traversal to determine the depth of the web root. In this example, this verifies that the web root is six (6) directories deep.

  1. Further in the access.log you should see a record entry with the following HTTP request:
"GET /vulnerabilities/fi/?page=/etc/shadow HTTP/1.1"

This is evidence of an attempt to access the password hashes of users on the web server.

Notice that this record has an HTTP response status code of 200 which means success. However, while this URL was successfully processed by the web server, it does not necessarily mean that the requested file was provided to the visitor. The /etc/shadow is an existing file, so the URL was focused on an existing object. However, the file would not be readable to the user without valid permission. This is where a comparison with a file-level access log would be needed to determine if the access attempt was granted or denied. This type of file object tracking log is not enabled in this lab.

  1. There should then be a series of log entries with HTTP requests similar to:
"GET /vulnerabilities/fi/?page=../../../../../../proc/version HTTP/1.1"

These entries are evidence of specific system probing via directory traversal to access the files associated with system processes.

  1. When finished looking over the access.log, type q to exit the less viewer.

  2. Enter echo 0 > /var/log/apache2/access.log.

    • This clears the website’s access.log in preparation for the next exercise.

  3. Enter exit, then enter exit again to fully log out of LAMP.

You have performed an investigation to detect directory traversal attacks. As you can see, if a change to parent operation is performed, you may be able to easily locate the logs of that activity. However, if the web server supports direct or absolute references to directories and files outside of the web root, then you have to compare the known web root URLs to the log entries to determine which are accessing files outside the web root.

Command Injection

Command injection is a cyber attack that involves executing arbitrary commands on a host operating system (OS). Typically, the threat actor injects the commands by exploiting an application vulnerability, such as insufficient input validation. In this exercise, you will be exploiting command injection vulnerabilities on a website.

  1. Connect to the KALI VM.

  2. Launch the Firefox browser.

  3. In the Firefox address bar, enter dvwa.structureality.com

  4. If prompted, type admin and password into the Username and Password fields, respectively, then select Login.

  5. The Welcome to Damn Vulnerable Web Application! page should be displayed.

  6. In the left-side navigation menu bar, select Command Injection.

  7. The Vulnerability: Command Injection page should be displayed.

  8. Type 10.1.16.66 into the Enter an IP address field, then select Submit.

You should see a result of a ping operation with four (4) replies.

This causes the website to perform a ping operation against a remote system. This IP address is in use by the Kali VM, but any accessible IP address could be used.

  1. Type 127.0.0.1; ls -la into the Enter an IP address field, then select Submit to test to see if a command injection will work.
    • This command injection test introduces an additional instruction after the IP address using a semi-colon. The semi-colon can be used to stack commands.
    • The loopback IP address is used to minimize the time involved in performing the ping operation so that the injected command will execute faster.

You should see the ping result followed by a listing of files from the directory hosting the file(s) which created this page (i.e., the web root directory). Notice the index.php file and source directories.

  1. Type 127.0.0.1 && cat index.php then select Submit.

You should see the ping operation followed by the contents of the index.php file. However, the browser will still attempt to render the contents of index.php as if it was HTML.

Info

Notice that with both of these stacked commands, you still have to wait for the ping function to complete.

  1. Type ; ls -la source then select Submit.

This command displays the contents of the source directory within the web root.

You can often skip or bypass a form field’s intended function by ignoring the request for a specific value and starting with a semi-colon before your injected command(s).

  1. Type ; ls -la .. then select Submit.

This command displays the contents of the parent folder of the web root. This is effectively combining command injection with directory traversal.

  1. Type ; whoami; hostname; ip a; pwd; uptime then select Submit.

This command displays the user context, hostname, IP and interface information, current working directory, and system uptime.

What is the result of the whoami command?

  • Answer; ||www-data||
  1. Type the following into the Enter an IP address field, then select Submit.
; ls ../; echo ...; ls ../../; echo ...; ls ../../../

In this injection, you are interspersing your own delimiter to separate the output from each listing command. This can make interpreting the results a little easier.

You should see a listing of the contents of the immediate parent folder, then three dots, then the contents of the next parent folder, then three dots, then the contents of the next parent folder.

  1. Type |cat /etc/passwd then select Submit.
    • You should see the contents of the /etc/passwd file.

The accounts listed in the passwd file are for the host OS, not the website. The website has its own independent accounts database and authentication service. So, while you may see similar/same account names from the OS and the website, they are different accounts. The users of those accounts could use the same password or different passwords.

You can use your imagination and think up other commands to perform through the vulnerable website.

  1. Close Firefox.

You have now performed command injection attacks using a variety of separator/combiner symbols to enumerate details about a target system.

Investigate command injection

As the cybersecurity analyst, you have been tasked with evaluating the logs of the company website for signs of compromise. In this exercise, you will investigate the log of the company’s website to see if you can find evidence or IoCs of command injection.

  1. Connect to the LAMP virtual machine

  2. Elevate to use root privileges by entering: sudo su and then entering Pa$$w0rd as the password.

  3. Enter cd /var/log/apache2 to change into the apache2 log directory.

  4. Enter ls -l to view the log filenames, sizes, and timestamps.

  5. Enter less access.log to view the website’s access.log. Look over the log for anything interesting.

You need to ‘ignore’ the directory path element of “/vulnerabilities/exec/” as this is the obvious name of the HTML document on the DVWA (Damn Vulnerable Web Application) that is designed to demonstrate command injection execution. In a real-world situation, you will not see obvious terms or entries in the logs.

  1. Starting from the top of the access.log file (i.e., the oldest entry in the log), look down through the entries to find the one with the following as its HTTP request:
"POST /vulnerabilities/exec/ HTTP/1.1"

Notice that the website’s access.log only includes the event of a POST communication to the vulnerable URL, not the actual content of the submission. You will need to view the error.log to view the contents of POST submissions.

  1. Notice the time stamp of the first occurrence of a POST HTTP request. Enter that time in the box below in the format HH:MM:ss. For example, 05:14:66 or 14:39:29.

  2. Press q to exit the less viewer.

  3. Enter less error.log to view the website’s error.log.

Notice the error log contains significant information, and it can be challenging to find a concerning item unless you know what to look or search for.

  1. Press q to exit the less viewer.

  2. Enter grep -n 00:46:57 error.log | less to search the error.log file for the time stamp of the first concerning POST message and view the results through the less viewer.

    • change time to what you have found

You should see a record which has a “(data-HEAP)” value of “ip=10.1.16.66&Submit=Submit”. This is the record of the first submission you made in relation to the command injection exercise. However, this is not evidence of command injection, nor is it obviously malicious. It is simply the submission of an IP address to a URL that is designed to accept IP addresses and perform a ping operation against it.

  1. Take note of the line number of the record related to the “(data-HEAP)” value of:
ip=10.1.16.66&Submit=Submit

Enter the line number in the box below: 309

  1. Press q to exit the less viewer.

  2. Enter less -N error.log to view the error.log with line numbers.

  3. Scroll down to find line number 309.

  4. Scroll down to find the next interesting entry in the error.log file. It will be about 65 lines further in the log. However, this assumes that you did not make any errors and performed the lab steps exactly as instructed.

In a real-world investigation, you will not know the exact value, “(data-HEAP)”, or error to look for. Nor will you always know the interval of entries to examine. You instead have to be able to differentiate legitimate, benign, and normal entries from those that are suspicious, malicious, and atypical. This is where an automated analysis tool is of significant benefit.

  1. Locate the entry with a “(data-HEAP)” value of:
ip=127.0.0.1;+ls+-la&Submit=Submit

It should be around line 111.

Info

The line numbers from this point forward are only estimates. But, should at least get you in the ballpark of the relevant entries in the logs. If you find the line number estimates to be significantly different than expected, then ignore the line numbers and look for the specific content indicated.

You can attempt a search within the less viewer by first typing the forward slash on your keyboard (i.e., /), then type the query string (such as “ip=127.0.0.1;+ls+-la&Submit=Submit”), followed by pressing Enter on your keyboard. All matches will be highlighted. Pressing n moves forward through matches, pressing N moves backwards through matches. Learn more about less controls using less —help.

This is the first real evidence of command injection. Here you see the command stacking character of a semi-colon followed by an OS-level command (i.e., long-list all contents of the current directory). It is also a little odd that the loopback address was the IP address submitted.

  1. You realize that each of the “(data-HEAP)” values you need to look at end with the same value, i.e., “Submit=Submit”. Therefore you can change your search operations to be less tedious.

  2. Press q to exit the less viewer.

  3. Enter grep -n Submit=Submit error.log.

This command will show only the error.log entries that include “Submit=Submit” and will still indicate the line numbers of those entries.

  1. Locate the entry with a “(data-HEAP)” value of:
127.0.0.1+%26%26+cat+index.php&Submit=Submit

%26 is the percent-encoding value of an ampersand. It is stored in the error.log file as an encoded value rather than the actual character because it is a metacharacter. By using percent-encoding, it avoids the accidental processing of the metacharacter view log viewers - which could allow for arbitrary code execution planted by an attacker against the log viewing application.

It should be around line 176.

This is the second IoC of command injection. Here you see the command stacking character of double ampersands followed by an OS-level command (i.e., display the contents of a file).

  1. Scroll to locate the entry with a “(data-HEAP)” value of:
ip=%3B+ls+-la+source&Submit=Submit

It should be around line 242.

%3B is the percent-encoding value of a semi-colon.

This is another command injection IoC. This example is pulling a long list of all contents of the source directory (which is located within the web root directory).

  1. Scroll to locate the entry with a “(data-HEAP)” value of:
ip=%3B+ls+-la+..&Submit=Submit

It should be around line 309.

This is more evidence of command injection. This example is a long list of all contents of the parent directory to the web root directory.

  1. Scroll to locate the entry with a “(data-HEAP)” value of:
ip=%3B+whoami%3B+hostnamme%3Bip+a%3B+pwd%3B+uptime&Submit=Submit

It should be around line 375.

This is a command injection IoC where the attacker is performing system reconnaissance. They are retrieving the user context name, the system’s hostname, the interface configuration, the present working directory’s absolute path, and the uptime of the system.

  1. Scroll to locate the entry with a “(data-HEAP)” value of:
ip=%3B+ls+..%2F%3B+echo+...%3B+ls+..%2F..%2F%3B+echo+...%3B+ls+..%2F..%2F..%2F&Submit=Submit

It should be around line 441.

This is another example of command injection evidence. In this example, the attacker is displaying a long list of all contents of the parent directory, then the 2nd parent directory, then the 3rd parent directory, with each separated by an arbitrary delimiter of three periods.

  1. Scroll to locate the entry with a “(data-HEAP)” value of:
ip=%7C+cat+%2Fetc%2Fpasswd&Submit=Submit

This is a command injection IoC. This example displays the contents of the /etc/passwd file to the attacker.

You have performed an investigation to detect command injection attacks.

Graph View