Last week a new exploitation technique for PHP applications was announced at the BlackHat USA conference. Find out everything you need to know in this blog post.

Summary

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. We added the detection of this new type of attack to our RIPS Code Analysis engine.

Stream Wrappers

Most PHP file operations allow to use various URL-style wrappers such as data:// , zlib:// , or 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

1 2 3 include ( $_GET [ 'file' ]) include ( 'php://filter/convert.base64-encode/resource=index.php' ); include ( 'data://text/plain;base64,cGhwaW5mbygpCg==' );

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 format . Let’s create a Phar file and add an object with some data as meta data:

Creating a Phar File

1 2 3 4 5 6 7 8 9 10 11 12 // create new Phar $phar = new Phar ( 'test.phar' ); $phar -> startBuffering (); $phar -> addFromString ( 'test.txt' , 'text' ); $phar -> setStub ( '<?php __HALT_COMPILER(); ? >' ); // add object of any class as meta data class AnyClass {} $object = new AnyClass ; $object -> data = 'rips' ; $phar -> setMetadata ( $object ); $phar -> stopBuffering ();

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.



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 __destruct() or __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

1 2 3 4 5 6 7 class AnyClass { function __destruct () { echo $this -> data ; } } // output: rips include ( 'phar://test.phar' );

Exploitation

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 sufficient .

So far, this still doesn’t seem that critical because if an attacker can control the full file path in operations such as ìnclude() , fopen() , file_get_contents() , 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:

1 2 3 4 file_exists ( $_GET [ 'file' ]); md5_file ( $_GET [ 'file' ]); filemtime ( $_GET [ 'file' ]); filesize ( $_GET [ 'file' ]);

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.

Figure 2: Examplary taint analysis performed by RIPS.

