Hidden Backdoor program in PHP Opcache

0x00 Preface

Translated from this blog

In this article, we will look for strategies to detect and analyze malicious software hidden in the Opcache file. If you haven't seen us before about hiding the binary Webshell in the PHP7 opcache file, we recommend reading it before continuing.

0x01 Opcache

Opcache is the PHP7.0 new built-in cache engine. It compiles the PHP script and sets the byte code generated by the storage in memory.

You can also specify the destination folder for the cache in php.ini:

Opcache.file_cache=/tmp/opcache

Persisent secondary file-based cache for Opcahe

In the folder above, Opcache stores the PHP script and the corresponding compiled PHP script under the same folder structure directory. For example,/var/www/index.php will be stored in/tmp/opcache/[system_id]/var/www/index.php.bin after compilation

The system_id above is the version number of PHP, the extension ID of Zend and the size of various data types, MD5 later obtained. In the latest version of Ubuntu (16.04), there is the current Zend version and PHP (7.0.4-7) produced by system_id is 81d80d78c6ef96b89afaadc7ffc5d7ea. This hash is most likely used to ensure binary compatibility at installation time. The directory is created by Opcache when it caches its first file.

As we will see later, each Opcache file will have a system_id saved in the header field.

Interestingly, Opcache all generated folders/files (everything under/tmp/opcache) will have write permissions as the service that this user is running.

The following are the permissions in the Opchache folder:

#!shell$ ls/tmp/opcache/drwx------4 www-data www-data 4096 APR 09:16 81d80d78c6ef96b89afaadc7ffc5d7ea

As you can see above, the folder generated through Opcache is written by the Www-data user and has permission to write. If we have write permission in the Opcache directory, we can execute arbitrary code by rewriting the file with the compiled Webshell cache.

0x02 Attack case

First, we have to get the location of the cache folder (/tmp/opcache/[system_id]) and the location of the targeted PHP files (/var/www/... ）

For the sake of brevity, we assume that the site leaves the phpinfo () file, from which we can get the location of the cache folder, the location of the source code of the file, and all the necessary fields to calculate the system_id. (We have created a tool that calculates the system ID () of the phpinfo from a site.) You can find it in our GitHub library).

It is important to note that the target site must also be easy to upload files.

Assume that the default PHP.ini setting is used:

Opcache.validate_timestamp = 0    ; PHP 7 ' s default is 1opcache.file_cache_only = 1       ; PHP 7 ' s default is 0opcache.file_cache =/tmp/opcache

Here's how the attack works: we found a website that can upload any file to/var/www. Our goal is to replace/tmp/opcache/[system_id]/var/www/index.php.bin with our own backdoor-containing files.

1. Create a local containing Webshell malicious php file named index.php:

#!php
 
  

2. Settings in the php.ini file Opcache.file_cache set to the place you selected.

3. Run a Web service, use Php-s 127.0.0.1:8080, and then send a request for the index.php file, triggering the cache engine. A simple wge t127.0.0.1:8080 will do the job.

4. Go to the cache folder specified in step 1; you will find a file named Index.php.bin. This is the compiled version of our Webshell.

5. Since the local system_id will be different from the target, we will open the Index.php.bin and modify the system_id. As mentioned earlier, system_id can be computed by brute force or phpinfo () function server information. To change the right side of the file signature where the system_id is located:

6. Using file upload vulnerability, we upload a file/tmp/opcache/[system_id]/var/www/index.php.bin.

7. Refreshing the website's index.php file will run our Webshell.

0x03 continue in-depth

Setting at least two configurations in php.ini will create an alternative behavior.

disabling file_cache_onlyenabling Validate_timestamp

Bypassing memory cache (file_cache_only = 0)

If the memory cache file caches the priority file cache, overwriting the Opcache file will not execute

Our Webshell. This restriction can be bypassed if the Web server restarts. Because the memory cache will be emptied, Opcache will use the file cache to fill the memory cache, thus executing our webshell.

From this behavior, it is still possible to perform webshell without restarting.

In the framework like WordPress, there are also some outdated files that are still publicly accessible (for example: functions.php).

Because these files have been deprecated, they will not be loaded in memory or have a cached version in the file system. After we upload the malicious payload (functions.php.bin) and request the relevant webpage (/wp-includes/registration-functions.php), Opcache will run our binary Webshell.

bypassing timestamp validation (validate_timestamps = 1)

If timestamp validation is enabled, Opcache checks the timestamp of the requested PHP source file and compares 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 circumvent this restriction, an attacker would have to know the timestamp of the target source file.

That being said, in the framework like WordPress, the timestamp of the source file is as they were when extracting the zip or tar.

The interesting thing is that some of the files have not been modified since 2012 (functions.php and registration.php files). Therefore, these WordPress timestamps that span multiple versions will be the same. Knowing the timestamp, the attacker could modify his payload accordingly and succeed in replacing the cache with the Validate_timestamps setting. The timestamp is located 34 bytes from the beginning of the file:

0X04 Conclusion

In short, this new attack vector is an additional mining technique for specific hardening environments. It is not a common vulnerability that affects PHP applications. With the advent of PHP7.0, such as Ubuntu16.04, this attack will need to strengthen the auditing of your code to avoid file upload vulnerabilities and to be wary of potentially dangerous server configurations.

