Written by Ian Bouchard | 27 April 2016
In this article, we will be looking at a new exploitation technique using the default OPcache engine from PHP 7. Using this attack vector, we can bypass certain hardening techniques that disallow the file write access in the web directory. This could be used by an attacker to execute his own malicious code in a hardened environment.
OPcache is the new built-in caching engine with PHP 7.0. It compiles PHP scripts and sets the resulting bytecode in memory. It also offers caching in the filesystem when specifying a destination folder in your PHP.ini :
Inside the above folder, OPcache stores its compiled PHP scripts under the same folder structure as its corresponding PHP script. For example, the compiled version of
/var/www/index.php will be stored in
system_id shown above is an md5 hash comprised of PHP’s version, Zend’s extension build ID and the size of various data types. In Ubuntu’s latest distribution (16.04), the
system_id produced by the current version of Zend and PHP (7.0.4-7ubuntu2 at the time) is
81d80d78c6ef96b89afaadc7ffc5d7ea. The hash is most likely used to ensure binary compatibility between installations. The directory is created by OPcache when caching its first file. As we’ll see later on, each OPcache file will also have a copy of that
system_id stored in a header field. What’s interesting about the OPcache folder, is that all the folders/files generated by OPcache (everything under
/tmp/opcache/) will have write permissions as the user running the service. Here are the permissions inside the OPcache folder:
$ ls /tmp/opcache/
drwx------ 4 www-data www-data 4096 Apr 26 09:16 81d80d78c6ef96b89afaadc7ffc5d7ea
As you can see above, the folders generated by OPcache are writable by the
www-data user. If we have write access to the OPcache directory, we could execute arbitrary code by overriding cached files with a compiled webshell.
First, we must obtain the location of the cache folder (
/tmp/opcache/[system_id]) and the location of the targeted PHP file (
/var/www/...). For the sake of simplicity, let’s assume that the website has left a
phpinfo() file, from which we can obtain the cache folder location, the file source code location, and all the fields necessary to calculate the
system_id. (We’ve created a tool which calculates the
system_id from a website’s
phpinfo(). You can find it on our GitHub repository). It is important to note that the targeted website must also be vulnerable to unrestricted file upload. Let’s assume that the default
php.ini settings are used in addition to:
opcache.validate_timestamp = 0 ; PHP 7's default is 1
opcache.file_cache_only = 1 ; PHP 7's default is 0
opcache.file_cache = /tmp/opcache
Here’s how the attack works: We have found an unrestricted file upload vulnerability on a website where the
/var/www/permissions have been hardened. Our goal is to replace
/tmp/opcache/[system_id]/var/www/index.php.bin with our own code which includes a backdoor.
index.phpcontaining a webshell :
opcache.file_cachesetting in your PHP.ini file to the destination of your choice.
php -S 127.0.0.1:8080and then send a request for the
index.phpfile to trigger the caching engine. A simple
wget 127.0.0.1:8080will do the job.
index.php.bin. That’s the compiled version of our webshell.
system_idwill most likely be different from the target’s, we have to open
index.php.binand modify our
system_idto replace it with the target’s. As previously mentioned, system IDs can be guessed, bruteforced or computed from
phpinfo()‘s server information. The
system_idto replace is located right after the file signature:
index.phpwill run our webshell.
There are at least two configurations in the
php.ini settings that would create alternate behaviors.
If memory cache is prioritized before file cache, overwriting the OPcache file will not execute our webshell. This restriction can be bypassed if the server running our vulnerable website is restarted. Since the memory cache will have been emptied, OPcache will use the file cache to fill the memory cache, thus executing our webshell. With this behavior in mind, it is still possible to execute our webshell without the need of a restart. Under frameworks like WordPress, there are some deprecated files that are still publicly accessible (for example : registration-functions.php). Since these files are deprecated, they are never loaded and do not have a cached version in memory or in the filesystem. After uploading our malicious payload (
registration-functions.php.bin ) and requesting the associated webpage (
/wp-includes/registration-functions.php), OPcache will run our binary webshell.
If timestamp validation is enabled, OPcache will check the timestamp of the requested PHP source file and compare it to the timestamp header field of the cache file. If they do not match, the cache file is discarded and a new one is created. To successfully bypass this restriction, an attacker must know the timestamp of the targeted source file. That being said, under frameworks like WordPress, the timestamps for the source files are available as they remain intact upon extracting the zip or tar archive.
What’s interesting about this, is that some files haven’t been modified since 2012 (notice the
registration.php files). Therefore, these timestamps will be the same across multiple versions of WordPress. Knowing the timestamp, an attacker can then modify his payload accordingly and successfully override the cache, complying with the
validate_timestamps setting. The timestamp is located 34 bytes from the beginning of the file:
Here’s a quick demo showing how the attack works :
As we’ve mentioned briefly, we also have a GitHub repository. This repository contains our 010 editor template, the
system_id scraper tool and a copy of the demo website shown in this article. Feel free to help in the development of these tools and to submit pull-requests.
In summary, this new attack vector is an additional exploitation technique tailored to specific hardened environments. It is not a universal vulnerability affecting PHP applications. With the arrival of PHP 7.0 in major distributions such as Ubuntu 16.04, this attack vector reinforces even more the need to audit your code for file upload vulnerabilities and to be wary of potentially dangerous server configuration. A new post will be coming soon where we will present a more in-depth view of OPcache files.
This blog post has been written by Ian Bouchard who is currently doing an internship with us before going to University. Ian has demonstrated extraordinary abilities and we are proud to offer him the opportunity to share his research with the world.