The security researcher Sam Thomas from Secarma found a new exploitation technique that can lead to critical PHP object injection vulnerabilities - without using the PHP function
unserialize(). The new technique was announced at the BlackHat USA conference in his talk It’s a PHP Unserialization Vulnerability Jim, but Not as We Know It. It can enable attackers to escalate the severity of file related vulnerabilities to remote code execution.
Most PHP file operations allow to use various URL-style wrappers such as
php:// when accessing a file path. Some of these wrappers are often used to exploit remote file inclusion vulnerabilities where an attacker can control the full file path of a file inclusion. For example, the wrappers are injected to leak source code that otherwise would be executed, or to inject own PHP code for execution:
Remote File Inclusion Exploitation
But so far, nobody paid attention to the
phar:// wrapper. What is interesting about Phar (PHP Archive) files is that these contain meta data in serialized format. Let’s create a Phar file and add an object with some data as meta data:
Creating a Phar File
Our newly created
test.phar file now has the following content. We can see that our object was stored as a serialized string.
Figure 1: Hex view of the created Phar file.
If a file operation is now performed on our existing Phar file via the
phar:// wrapper, then its serialized meta data is unserialized. This means that our injected object in the meta data is loaded into the application’s scope. If this application has a class named
AnyClass and it has the magic method
__wakeup() defined, then those methods are automatically invoked. This means we can trigger any destructor or wakeup method in the code base. Even worse, if these methods operate on our injected data then this can lead to further vulnerabilities.
PHP Object Injection via Phar file
First, an attacker must be able to plant a crafted Phar file on the targeted web server. But Sam Thomas found some nice tricks on how to sneak a Phar file into a fake JPG, so a common image upload feature is already sufficient1.
So far, this still doesn’t seem that critical because if an attacker can control the full file path in operations such as
file() etc., then this already poses a severe security vulnerability itself. Therefore, user input used in these functions is usually validated.
However, the unserialize is triggered for the
phar:// wrapper in any file operation. Thus, other file operations, such as
file_exists() which simply checks the existence of a file, were until now considered as less sensitive to security risks and are less well protected. But now an attacker can inject the
phar:// wrapper and gain code execution.
Examples of so far harmless looking code:
- Pydio 8.2.1 Unauthenticated Remote Code Execution
- Shopware 5.3.3: PHP Object Instantiation to Blind XXE
- A Salesmans Code Execution: PrestaShop 22.214.171.124
- CTF Writeup: Complex Drupal POP Chain
- Breaking Into Your Company's Internal Network - SuiteCRM 7.11.4
- phpBB 3.2.3: Phar Deserialization to RCE
- What is PHP Object Injection