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 It1. It can enable attackers to escalate the severity of file related vulnerabilities to remote code execution. We added the detection of this new type of attack to our RIPS Code Analysis engine.
Most PHP file operations allow to use various URL-style wrappers2 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
Phar Meta Data
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 format3. 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.
PHP Object Injection
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:
Automated Detection with RIPS
With RIPS’ taint analysis we can automatically detect whenever user input is used unsanitized or unvalidated in PHP file operations. This way, we detect file delete, file disclosure, file write, file manipulation, file create, file inclusion (and so on) vulnerabilities.
Moreover, RIPS’ context-sensitive string analysis enables us to precisely evaluate if the file path can be fully or only partially controlled by an attacker, and if it is possible to inject a
phar:// wrapper. And finally, RIPS is able to scan for possible gadget chains that allow to exploit an object injection vulnerability. We thus added a new vulnerability type to our RIPS Code Analyzer called Phar Deserialization to detect this new type of code risk.