Local File Inclusion Parameter

I thought this was an interesting problem because there's a local file inclusion vulnerability but some of the typical methods for including the juicier files are prevented due to the addition of a defined PHP parameter.  The problem consists of a web site that allows the viewer to select whether they'd like to see dog or cat pictures.

When viewing the site, we are presented with:



When we choose dog, we get what appears to be a local file inclusion (and a picture of a dog!):


If we try the normal tricks for including a file like /etc/passwd, we get a message about dogs or cats only.  If we drop a semicolon after dog, we break the page and we can see that .php is getting added:


Using a base64 filter, we can retrieve the cat.php page:


When we decode it, we see a simple page that randomly selects images from 1-10:


Grabbing the index page:


We retrieve the base64:


We decode it and I'm removing the unimportant parts, getting to the meat:


Basically, dog or cat, look for the .php extension, if it doesn't exist, add the .php extension.  How this occurs is through the ext parameter.  We can include this parameter in our request:


How you reference the initial sequence is not relevant.  We can have:

/?view=./dog/../../../../../../../../etc/passwd&ext
/?view=dog../../../../../../../../etc/passwd&ext
/?view=dog/../../../../../../../../etc/passwd&ext

And we can also define dog with .php on each of these as well. 

With this particular problem, we are capable of poisoning the logs.  I think I mentioned this in a previous post but we can do this through the User-Agent parameter and we can leverage Burp for this task:


Let's see if we can get execution:


When we dig through the log file:


We find the user www-data.  Now let's see if we can catch a shell.  Going old school with Perl:


With our handler setup:


The log poisoning aspect is not real world.  By default, Apache logs are not world readable nor can www-data read them.

www-data@c2:/root/temp$ tail -n 50 /var/log/apache2/access.log
tail: cannot open '/var/log/apache2/access.log' for reading: Permission denied

Just pointing that out because the PHP vulnerability is possible because people write code the best they can understand whereas it would take an intentional act to modify the default permissions of the Apache log files.

Anyway, I thought this was an interesting file inclusion twist.