Hackers have begun exploiting recently patched vulnerabilities in Juniper Networks firewalls that can be chained together to achieve remote code execution. Exploit details and a proof-of-concept were released late last week by a team of security researchers.
“This is an interesting bug chain, utilizing two bugs that would be near-useless in isolation and combining them for a ‘world ending’ unauthenticated RCE,” researchers from security firm watchTowr said in their detailed analysis. “Those running an affected device are urged to update to a patched version at their earliest opportunity, and/or to disable access to the J-Web interface if at all possible.”
Four Juniper bugs but only two needed
On August 18, Juniper patched four vulnerabilities in its SRX Series and EX Series firewalls. The flaws are in the J-Web component of Junos OS, the operating system of Juniper firewall devices, and are all rated 5.3 out of 10 on the CVSS scale. This translates to a criticality of medium, which is generally treated with lower priority in patching cycles. However, in this particular case, some of the vulnerabilities can be chained together to achieve remote code execution without authentication, which Juniper clearly warns in its advisory.
Two flaws, CVE-2023-36846 and CVE-2023-36847, are similar and allow an unauthenticated attacker to send specially crafted requests to a device that would allow them to upload arbitrary files via J-Web to the file system. The other two flaws CVE-2023-36844 and CVE-2023-36845, are also similar to each other and both allow an unauthenticated attacker to modify certain PHP environments variables.
Following Juniper’s advisory, researchers from watchTowr were intrigued about the possibility to chain these flaws so set out to investigate them. It turns out that only two are needed to achieve the attack, one file upload and an environment variable modification.
First, they found the CVE-2023-36846 vulnerability by looking at the internal functions of the J-Web interface, which is a PHP application. They located one called do_upload that handles the upload of files and immediately noticed that it lacked an authentication check. Therefore, exploitation was straightforward, but the upload file was placed in a tmp folder and it seemed that the web server itself was running as a jailed process.
Locating the second flaw that was needed to modify PHP environment variables was not hard, either. Taking it from there to arbitrary code execution was difficult due to the security defenses of Junos OS.
First, the researchers tried to abuse the LD_PRELOAD variablem which will instruct the PHP process to load a library. They pointed this variable to the location of the file they uploaded using the first flaw, but the execution attempt failed with an authentication error message.
The researchers tried to debug the error for a long time to understand what was going on and even tried to load libraries that already existed on the system without success.
“Well, it turns out that Juniper is (wisely) using a tool named veriexec, which will limit execution to binaries which have a valid signature – and also verify their location on the filesystem,” the researchers said. “This means that attempts to upload and execute a payload will fail, since our payloads will be located in a location not whitelisted (and also because they are not cryptographically signed). Great for security, but bad for us.”
Then the researchers wondered about what digitally signed binaries might exist on the system and whether they could influence their execution through an environment variable. The answer? The PHP binary itself. PHP is a framework and runtime, and when it starts it has a configuration file, usually called php.ini, the location of which is defined in an environment variable called PHPRC.
So, the researchers could upload a specially crafted php.ini configuration file using the file upload vulnerability, then use the second vulnerability to modify the PHPRC variable and point the PHP process to it. How do you execute arbitrary code from inside a configuration file? It turns out php.ini has an entry called auto_prepend_file that allows the user to point to a file that the process will execute before any other PHP code.
The chain was now complete. Upload a file with malicious shellcode, then upload a specially crafted php.ini with an auto_prepend_file pointing to it, then modify the PHPRC variable to execute the php.ini and implicitly the malicious shellcode. In addition to their detailed write-up, the researchers also published a proof-of-concept exploit on GitHub that automates the whole attack.
“While the quality of the code is much aligned with other devices in its class, such as the Fortiguard and Sonicwall devices we’ve been breaking, it is worth pointing out here that Juniper’s use of veriexec was a wise move, as it complicates code and command execution,” the researchers said. “However, it is not enough to prevent determined attackers – watchTowr researchers took around half an hour to circumvent it (and, I’ll admit, much longer to realise it was in effect).”
Attacks using the Juniper vulnerabilities in progress
The same day watchTowr published their PoC exploit, the Shadowserver Foundation, an organization that scans the internet for malware and monitors attacks using honeypots, reported seeing exploit attempts for Juniper J-Web CVE-2023-36844 and the other flaws. The organization noted that it currently tracks over 8,200 IP addresses with J-Web interfaces exposed to the internet.
The watchTowr researchers pointed out that patching might not be straightforward, especially for virtualized Juniper appliances running in the cloud. “We carried out this research using an EC2-hosted SRX device, and were dismayed to find that it is seemingly impossible for us to actually patch the device to latest,” they said. “Updates are only available to registered users, and it seems that the EC2 integration which performs registration is faulty.”
The researchers advise users who can’t patch immediately to disable the J-Web component or to restrict access to it to very trusted users. Their report also includes indicators of compromise that administrators can look for in the PHP log files of their appliances.