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.

WordPress’ /wp-includes folder

 

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

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.

GoSecure Titan® Managed Extended Detection & Response (MXDR)​

GoSecure Titan® Managed Extended Detection & Response (MXDR)​ Foundation

GoSecure Titan® Vulnerability Management as a Service (VMaaS)

GoSecure Titan® Managed Security Information & Event Monitoring (Managed SIEM)

GoSecure Titan® Managed Perimeter Defense​ (MPD)

GoSecure Titan® Inbox Detection and Response (IDR)

GoSecure Titan® Secure Email Gateway (SEG)

GoSecure Titan® Threat Modeler

GoSecure Titan® Identity

GoSecure Titan® Platform

GoSecure Professional Security Services

Incident Response Services

Security Maturity Assessment

Privacy Services

PCI DSS Services

Penetration Testing Services​

Security Operations

MicrosoftLogo

GoSecure MXDR for Microsoft

Comprehensive visibility and response within your Microsoft security environment

USE CASES

Cyber Risks

Risk-Based Security Measures

Sensitive Data Security

Safeguard sensitive information

Private Equity Firms

Make informed decisions

Cybersecurity Compliance

Fulfill regulatory obligations

Cyber Insurance

A valuable risk management strategy

Ransomware

Combat ransomware with innovative security

Zero-Day Attacks

Halt zero-day exploits with advanced protection

Consolidate, Evolve & Thrive

Get ahead and win the race with the GoSecure Titan® Platform

24/7 MXDR FOUNDATION

GoSecure Titan® Endpoint Detection and Response (EDR)

GoSecure Titan® Next Generation Antivirus (NGAV)

GoSecure Titan® Security Information & Event Monitoring (SIEM)

GoSecure Titan® Inbox Detection and Reponse (IDR)

GoSecure Titan® Intelligence

OUR SOC

Proactive Defense, 24/7

ABOUT GOSECURE

GoSecure is a recognized cybersecurity leader and innovator, pioneering the integration of endpoint, network, and email threat detection into a single Managed Extended Detection and Response (MXDR) service. For over 20 years, GoSecure has been helping customers better understand their security gaps and improve their organizational risk and security maturity through MXDR and Professional Services solutions delivered by one of the most trusted and skilled teams in the industry.

EVENT CALENDAR

LATEST PRESS RELEASE

GOSECURE BLOG

SECURITY ADVISORIES

 24/7 Emergency – (888)-287-5858