apache log poisoning with local file inclusion

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.

lf1

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.

lf2

finding the apache log files using burp intruder

Often when conducting security assessments it is necessary to go beyond just identifying the vulnerability, reporting it and heading out for a beer. Sometimes, like when conducting a penetration test or when asked by a client to demonstrate business risk, it is necessary to gain command line line access to the machine to show the risks associated with having a web user being able to execute commands on their machine. Often this involves getting a shell by some means but in the case of Local File Inclusion (LFI) simply finding the Apache Log location folder can be enough to start running commands on the system as the Apache service account.

Often I’ve wasted hours trying all sorts of combinations trying to find the correct location of the log files by looking up version numbers and identifying operating systems but being the true to the Pentesters code, sometimes it’s better to be lazy and just automate the damn thing. So what a buddy of mine and me did was to compile a list of common Apache … read more