PHP
Some tricks specific to the PHP web programming language
Last updated
Some tricks specific to the PHP web programming language
Last updated
When code uses == or != instead of === or !== the user may use certain strings to do weird stuff with PHP converting strings to integers
In PHP (< 8.0) the following table of rules applies when loosely comparing variables:
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:
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:
pearcmd.phpRecently 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:
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:
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:
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:
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.
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.
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:
If you can't find the logs you might be able to find it by looking at the configuration of the server, you can include/read any file after all:
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.
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.
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.
For a complete and detailed guide on every possible comparison between types, see .
The "php" == 0 case was so weird, that from PHP 8.0 onward, this is no longer true. However, the "php" == true still works ().
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 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 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.
For arbitrary contents instead of just the <?=`$_GET[0]`;;?> needed here, check out the that Carlos Polop made. Synacktiv later also made a tool that automates it:
A trick using 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:
pearcmd.php to get RCE from local file inclusion through directory traversal
