Administrators and IT teams managing and maintaining a PHP-FPM-enabled website on NGINX server are advised to patch a vulnerability that can let attackers carry out remote code execution (RCE) on the vulnerable website and server. Here’s what you need to know about the vulnerability and what IT and security teams can do to defend against threats that may exploit it:
What is the vulnerability about?
Designated as CVE-2019-11043, the vulnerability affects websites running on NGINX web servers enabled with the Hypertext Preprocessor FastCGI Process Manager (PHP-FPM). The vulnerability is related to a lack of checks on the configurations of NGINX and PHP-FPM. Under certain conditions, the vulnerability can be exploited to achieve remote code execution.
PHP-FPM is an alternative implementation of FastCGI (a way to execute scripts faster) with additional features especially for high-traffic sites. While PHP-FPM isn’t a core component in NGINX installs, web hosting providers typically include it in their PHP environments. CVE-2019-11043 was reported to the PHP bug tracker thread by Emil Lerner, and credited the vulnerability’s discovery to one of Wallarm’s security researcher, Andrew Danau.
How can the vulnerability be exploited?
Technical analysis by Ranga Duraisamy, Vulnerability Researcher
The vulnerability works for a specific configuration, as shown in Figure 1. The regular expression in fastcgi_split_path_info will break if an encoded newline (%0a) character is introduced in the uniform resource identifier (URI). Because of this, the PATH_INFO variable will be empty and the unpatched version assumes that env_path_info would always contain a value. Owing to the lack of validation, the vulnerability is triggered and the system crashes.
Figure 1. Nginx configuration for exploit
The length of the URI should be about 2,000 bytes, making path_info point exactly to the first byte of the _fcgi_data_seg structure. FCGI_PUTENV function will overwrite the variables with a script path. An arbitrary PHP_VALUE fcgi variable can be created, enabling an attacker to have access for remote code execution. The vulnerable server can be exploited by sending a crafted HTTP GET request with code to be injected ("$_GET[a]`?>") immediately after the newline character (%0A).
Figure 2. Specially crafted malicious GET request sent to the server for remote code execution
Once the code is injected, a persistent webshell is created and can be accessed through the parameter ‘a’ (http://vulnserver/index.php?a=).
After exploiting the security flaw, the attacker can also modify the parameter name and obfuscate the injected code, achieve code execution persistence, and the vulnerability be triggered by accessing any .PHP file apart from index.php.
Figure 3. Persistent code execution
Following PATH_INFO, SCRIPT_FILENAME can set the parameter to identify the path difference and the length of SCRIPT_FILENAME (slen) and PATH_INFO (pilen) are used in arithmetic operations without applying a sanity check. By introducing a newline character (%0a), the PATH_INFO would be empty and will be set to zero in subsequent stages. If slen is greater than pilen, PATH_INFO would be negative and will decrement the pointer, leading to underflow.
Figure 4. Malicious GET request sent to server
Are there attacks exploiting CVE-2019-11043 in the wild?
Threat intelligence firm Bad Packets told ZDNet that the vulnerability is already being exploited in the wild to hijack servers. There is, in fact, a working exploit released as a proof of concept (PoC) in Github. The PoC queries a web server and checks if it is vulnerable. Once verified to be vulnerable, hackers can send especially crafted requests by appending characters in the URL of the web server.
As an enterprise’s online infrastructures become more complex — from their decentralization to the adoption of cloud, mobile, and internet-of-things (IoT) technologies — patch management has become an even more time-consuming and resource-intensive task. Here's how virtual patching can help.
What is the potential impact of this vulnerability?
This vulnerability has been rated critical since the exploit is considered simple, achieves persistence once abused, is limited to affecting a certain type of configurations, and authentication is not required. Successfully exploiting CVE-2019-11043 can lead to RCE. In this case, it can allow hackers and threat actors to take over a PHP-written or -supported web application and its web server. This allows attackers to steal, delete, add, or overwrite content, embed them with malware, or use them as doorways into other systems or servers connected to it.
The impact could be pervasive, given the real-world usage of NGINX-based web servers and PHP 7-based websites (the version of PHP that CVE-2019-11043 affects) at 30.6% and 33%, respectively. PHP is the framework for many popular websites and web applications, including content management systems WordPress and Drupal.
Has the vulnerability been patched?
Yes. Administrators and IT teams using NGINX with PHP-FPM are recommended to update their PHP to their latest or stable versions (7.2.24 or 7.3.11), which have addressed the vulnerability along with other bugs. If the patch or upgrade is not feasible or cannot be immediately applied, Wallarm provided a workaround by adding rules to check if a file exists or not, or filters in URLs. Web hosting provider Nextcloud also released an advisory on the vulnerability.
Web injections are every programmer, developer and information security (InfoSec) professional’s headache — and a permanent fixture in a cybercriminal’s toolkit. Here’s a glance at the most prevalent web injection attacks and how programmers and information security professionals can mitigate them.
What can be done to mitigate attacks or threats that exploit the vulnerability?
Administrators of the vulnerable web servers can also adopt the following best practices to deter threats or intrusions that exploit the vulnerability:
Regularly patch and update the PHP environment to its latest versions and accordingly disable unnecessary or outdated plug-ins or components
Always use validation and sanitation checks on all user-generated inputs or data
Enforce the principle of least privilege by restricting permissions as well as access to tools or programming techniques that can be abused to gain a foothold on a web server
Inspect requests and responses being made within the website or web application