Top Trending CVEs of August 2023
- Sep 01, 2023
- Shawn Evans
Summer is slowly cooking everyone into air conditioned spaces as vacations wind down and school winds up. August featured some interesting software vulnerabilities, one of which will impact an unknown number of applications. This month we cover an unauthenticated remote (RCE) command execution vulnerability that impacts some of Juniper’s enterprise firewalls. This isn’t Juniper’s first rodeo. Researchers found that the Java Spring Framework was prone to a security bypass vulnerability that could expose restricted endpoints to external threat actors. Finally we take a look at a command injection vulnerability that impacts Checkpoint’s Gaia Portal.
This is the tail of the chained vulnerability, where the cumulative risk is greater than the individual exploit. Juniper recently released an out-of-cycle patch for J-Web of Juniper Networks Junos OS. J-Web is the web browser friendly manner of managing the firewall so admins don’t have to rely exclusively on the command line terminal. The patch addressed four vulnerabilities that included CVE-2023-36845 and CVE-2023-36846. CVE-2023-36845 is a vulnerability that allows unauthenticated threat actors to make arbitrary changes to PHP environment variables. CVE-2023-36846 is an arbitrary file upload vulnerability that is attributed to a lack of authentication checks on critical administrative functions. This piqued the interest of the research team at WatchTower.
J-web is a collection of PHP scripts that collectively facilitate the remote management of the firewall. Researchers analyzed the code base of this software and found that a few core scripts lacked checks to verify the user was authenticated. One of which included webauth_operation.php. This script in particular relied upon a different class for authentication, but by default bypassed said authentication class. The webauth_operation.php script accepts two (2) POST parameters as input, a function name and an argument list. The lack of authentication checks meant that an unauthenticated attacker could access any internal function available to an admin user, which totaled nearly 150 functions. The purpose of these functions ranged from simple helpers to complex interactions with the CLI. Using some clever techniques to alter the code to inject debug statements resulted in the exposure of the complete list of internal functions available to internal users. The research team zeroed in on the function “do_upload”, which surprisingly also lacked authentication checks. The function expected a single JSON object that contained the values fileName, fileData, and csize. By combining these elements it was possible to upload arbitrary files to the vulnerable endpoint (CVE-2023-36846). By default, uploaded files ended up in a BSD jail (/tmp/jail).
The second link of the vulnerability chain was the ability to set arbitrary PHP environment variables. J-web was based on a variant of the GoAhead web server, which has a history of environment variable injection vulnerabilities. J-web wasn’t operating a vulnerable version of GoAhead, but introduced a vulnerability within their own PHP code that acted as a proxy between the GoAhead CGI engine and PHP. Leveraging the ability to define arbitrary environment variables provided a fairly direct exploit path. An attacker could upload a crafted “php.ini” and PHP web shell, and maliciously set the LD_LIBRARY_PATH, LD_PRELOAD, and LD_DEBUG environment variables to effectively compromise the deployment. On their own, these CVEs were assigned a CVSSv3 score of 5.3, but their powers combine to top the charts. Who knew CVSS compound math was even a thing? Pretty cool exploit. The good news here is that most firewalls will not be externally exposed, but there are always exceptions. Exploit code is publicly available and the attack complexity is trivial. Patch now!
These issues affect Juniper Networks Junos OS on SRX Series:
All versions prior to 20.4R3-S8
These issues affect Juniper Networks Junos OS on EX Series:
All versions prior to 20.4R3-S8
Spring Security recently released a patch to address a broken access control vulnerability. Spring Security is a component of the Spring Framework, which is a Java based application development platform. You may have noticed that we didn’t even land at WebFlux yet. Spring WebFlux was introduced to Spring Security to handle asynchronous, non-blocking, reactive programming. So, it’s basically a way to increase concurrency and minimize threads, but none of that really matters much to understand the vulnerability.
The J-Frog research team analyzed the code changes between the patched versions of Spring Security, previous releases, and noted changes to the “PathPatternParserServerWebExchangeMatcher” class file. Specifically, changes were made to the “initFullPathPattern” method that added a forward slash (/) to a string if it didn’t already start with one.
The attack comes full circle when you understand the global context of the “initFullPathPattern”. This method is called when parsing the configuration values of Spring Security rules. Consider a situation where an application has different basic user and admin portals. It would be possible then to block access to administration URLs to unauthorized nodes by defining a wildcard pattern that denied access to a specific path and all sub paths. However, due to the vulnerability patterns that contained a wild card or any path not ending in a forward slash exposed restricted directories to unauthorized threat actors.
The vulnerability in this case could be present in any application that leveraged a vulnerable Spring Security framework and had a wildcard (or any path not ending in a forward slash) URL filter defined in the application configuration.
It’s not clear how many applications will be impacted by this vulnerability. Spring Security is a popular framework, but not all deployments will use a wildcard URL filter or URL filter without a terminating forward slash. As a temporary alternative to patching, add a leading forward-slash to any URL filter used in Spring Security. This vulnerability will not universally result in remote command execution, but on vulnerable deployments it will certainly expose unintended attack vectors and increase an organization’s attack surface.
Upgrading your Spring Security version to one of the following is strongly advised:
The above requires the Spring Framework versions:
Gaia is the core operating system deployed on Check Point Appliances. Researchers found that the Gaia Portal, a web based Gaia platform management system, was prone to command injection vulnerabilities.
The vulnerability was attributed to the vulnerable CGI script “hosts_dns.tcl”. This script enabled authorized users the ability to create domain names on appliances. The script accepts three (3) POST parameters as input: hostname, domainname, and save. It was found that the parameters processed by the script were injected directly into a string that was ultimately executed as a shell command. By appending a pipe (|) to the “hostname” parameter it was possible to inject any system command between tick marks (`) into the request. This is as simple as it gets. Command injection 101.
It should be noted that this vulnerability is only exploitable by authenticated users that have write permissions on the DNS settings. At least one of these vulnerabilities required attackers to put in some legwork finding credentials.
The following version of Quantum Appliances and Quantum Security Gateways are vulnerable
Please see the following hotfixes:
To stay up to date on the latest trending and critical celebrity vulnerabilities, subscribe to NopSec’s newsletter. If you don’t like having to keep up with vulnerabilities like these yourself, let our Unified VRM platform do it for you. It takes into account new critical vulnerabilities as they emerge, ensuring your risks are prioritized accordingly in your unique environment. If you’d like to see what NopSec’s Unified VRM can do in action watch this on-demand product tour.