Binary Webshell Through OPcache in PHP 7

Update: A follow-up article was published on the detection and the reverse-engineering of those binary web shells.

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

 

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 :

opcache.file_cache=/tmp/opcache

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 /tmp/opcache/[system_id]/var/www/index.php.bin The 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.

 

Attack Scenario

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.

Vulnerable website example

1. Create a malicious PHP file locally named index.php containing a webshell :

   <?php
      system($_GET['cmd']);
   ?>

2. Set the opcache.file_cache  setting in your PHP.ini file to the destination of your choice.
3. Run a webserver using php -S 127.0.0.1:8080 and then send a request for the index.php  file to trigger the caching engine. A simple wget 127.0.0.1:8080  will do the job.
4. Navigate to the cache folder specified in step #1; you’ll find a file called index.php.bin . That’s the compiled version of our webshell.
   
5. index.php.bin generated by OPcache
6. Since the local system_id  will most likely be different from the target’s, we have to open index.php.bin  and modify our system_id to replace it with the target’s. As previously mentioned, system IDs can be guessed, bruteforced or computed from phpinfo() ‘s server information.  The system_id to replace is located right after the file signature:
   
   Location of the system_id
7. Using the unrestricted file upload vulnerability, we upload our file to /tmp/opcache/[system_id]/var/www/index.php.bin.
8. Refreshing the website’s index.php  will run our webshell.

Going Deeper

There are at least two configurations in the php.ini settings that would create alternate behaviors.

• Disabling file_cache_only
• Enabling validate_timestamp

Bypassing memory cache (file_cache_only = 0)

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.

Bypassing timestamp validation (validate_timestamps = 1)

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-functions.php  and 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:

Demo

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.

 

Conclusion

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.

 

References

• PHP’s OPCache extension review (Mirror) by Julien Pauli
• 25 PHP Security Best Practices for Sys Admins by Vivek Gite
• Speeding up the web with PHP7 by Rasmus Lerdof

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.