Use the Opcache in PHP 7 to implement Webshell

In this article, we will explain the security issues in the PHP7 Opcache engine, and will introduce a new exploit technology. With this approach, we can bypass some security hardening techniques, such as security measures that prohibit web directories from reading and writing files. In addition, attackers can use this attack technique to execute malicious code in the target host.

Opcahce

Opcache is a new cache engine embedded in PHP 7.0. It compiles the PHP script code and stores the result of the compilation in memory as a byte-code situation.

Opcache improves PHP performance by storing PHP script precompiled bytecode in shared memory, and the benefit of storing precompiled bytecode is to eliminate the overhead of loading and parsing PHP scripts every time.

In addition, it provides caching capabilities for the file system, but we must define the destination folder path for the cache information in the php.ini configuration file:

Opcache.file_cache=/tmp/opcache

In this folder above, Opcache will save the compiled PHP script in the same directory structure as the corresponding PHP script. For example, the code that needs to be compiled is saved in/var/www/index.php, and the compiled code is saved in/tmp/opcache/[system_id]/var/www/index.php.bin.

In the above file path, system_id is a MD5 hash that contains the current PHP version information, the Zend Framework's extension ID, and various data type information. In the latest release of the Ubuntu Operating system (16.04), system_id is comprised of the current Zend Framework and the PHP version number (81D80D78C6EF96B89AFAADC7FFC5D7EA). When Opcache caches these files for the first time, the corresponding directories are created in the file system.

As we'll see in the next sections, each Opcache file also saves a copy of system_id in the header field of the file.

At this point, we have to mention the Opcache folder, one of the very interesting thing is that when the user has enabled the service, the user will have all the Opcache generated folders or files (all files and folders are located under the/tmp/opcache/directory) write permissions.

The permissions information in the Opcache folder is as follows:

$ ls/tmp/opcache/

DRWX------4 www-data www-data 4096 APR 09:16 81d80d78c6ef96b89afaadc7ffc5d7ea

As we can see, the users under the Www-data group have write access to the Opcache generated folder. If we have write access to the Opcache directory, then we can rewrite the cache file in the directory and then use Webshell to execute arbitrary code.

Attack scenario

First, we must get the cache folder's save path (/tmp/opcache/[system_id]), as well as the destination PHP file save path (/var/www/...).

To make it easier for everyone to understand, we assume that there is a phpinfo () file in the Site directory where we can get the cache folder and the location where the file source code is stored, which we will need when we calculate the system_id. We have developed a tool that can extract information from website phpinfo () and calculate system_id. You can get to this tool in our GitHub code base.

Here, we need to note that the target site must not be limited to the uploaded files.

Now, let's assume that in addition to the default settings information in PHP.ini, the following configuration data is added:

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

Next, we will explain the attack implementation process:

We have found a vulnerability in our website which means that the website does not impose any restrictions on the files we upload. Our goal is to replace the file/tmp/opcache/[system_id]/var/www/index.php.bin with malicious code that includes a backdoor.

The Web interface that contains the vulnerability is displayed.

1. Create a malicious php file that contains Webshell locally and name it "index.php":

System ($_get[' cmd ');

?>

2. Add the relevant settings of the Opcache.file_cache to your php.ini file.

3. Start a Web server with the php–s 127.0.0.1:8080 command, then request the index.php file to the server and trigger the cache engine. In this step, we only need to use the command wget 127.0.0.1:8080 to achieve our goal.

4. Navigate to the cache folder that we set in the first step, and you will find a file named Index.php.bin. This file is a Webshell that has been compiled.

Shows the index.php.bin generated by the Opcache.

5. Since the local system_id is likely to be different from the system_id of the target host, we must open the Index.php.bin file and modify our system_id to the target host's system_id. As we mentioned earlier, system_id is likely to be guessed, such as brute force cracking, or based on the server information in the Phpinfo () file. We can modify the system_id after the file signature data, as shown in the following:

The data storage location for system_id is displayed.

6. Since the target website does not have any restrictions on the uploaded files, we will now upload the files to the server directory:

/tmp/opcache/[system_id]/var/www/index.php.bin

7. Refresh the site's index.php, and the website will automatically execute our Webshell.

Bypassing the memory cache (file_cache_only = 0)

If the memory cache has a higher priority than the file cache, overwriting the Opcache file does not execute our Webshell. If there is a file upload restriction vulnerability in a server-hosted Web site, we can bypass this restriction after the server restarts. Now that the memory cache can be emptied, Opcache will use the file cache to populate the memory cache to achieve the purpose of our Webshell execution.

This means that we still have a way to execute our Webshell without restarting the server.

In the WordPress and other Web site framework, there will be some outdated files can be publicly accessible, such as registration-functions.php.

Because these files are obsolete, the system will not load these files again, which means that there is no possibility of these files in the memory and file system caches. After we upload the malicious code (REGISTRATION-FUNCTIONS.PHP.BIN), and then visit the relevant web page (/wp-includes/registration-functions.php), Opcache will automatically execute our Webshell.

Bypassing timestamp authentication (validate_timestamps = 1)

A timestamp is usually a sequence of characters that uniquely identifies the time of a moment. In general, the process of time stamping is that the user first encrypts the file that needs to be timestamp into a hash code, and then sends the digest to Dts,dts after it has joined the date and time information of the received file digest and then encrypts (digitally signed) the file and then sends it back to the user.

If the server has the timestamp authentication feature enabled, Opcache will validate the timestamp of the requested PHP source file, and if the file matches the timestamp in the header domain of the cache file, the server will allow access. If the timestamp does not match, then the cache file is discarded and a new cache file is created. To circumvent this limitation, an attacker would have to know the timestamp of the target source file.

This means that in the framework of WordPress and other Web sites, the timestamp of the source file can be obtained, because when the developer extracts the code files from the compressed package, the timestamp information remains unchanged.

The information in the Wordpress/wp-includes folder is displayed.

Interestingly, some of these documents have not been modified since 2012 (please note the following two files: registration-functions.php and registration.php). So, even with different versions of WordPress, the timestamps of these same files are the same. Once the file timestamp information is obtained, the attacker can modify their malicious code and successfully overwrite the server's cached data. The timestamp information is at the 34th byte position at the beginning of the file:

Demo Video

Here we give you a brief video of the demo, and the attack steps are explained in the video:

Video Address: Https://youtu.be/x42l-PQHhbA

As we mentioned before, you can get the tools you need in our GitHub code base.

Summarize

All in all, this new type of attack does not have an impact on applications that use PHP for development, because this is not a common vulnerability for PHP. Now, a lot of Linux distributions operating systems (such as Ubuntu 16.04) will install PHP 7 by default, so when we learn about this attack technology, in our development process, it is more prudent to review our code, and check the site for file upload Restrictions vulnerability, Because this vulnerability would have an impact on the security of the server.

This article by 360 security broadcast translation, reprint please specify "Transfer from 360 security broadcast", and attached link.

Original link: http://blog.gosecure.ca/2016/04/27/binary-webshell-through-opcache-in-php-7/

