Top Trending CVEs of March 2024
- Apr 03, 2024
- Shawn Evans
March may be absolute madness for the NCAA and people in bunny suits, but it was a fairly quiet month for security research. That didn’t stop a few research teams from laying into Fortinet, as is the Easter tradition. Researchers identified two (2) critical injection vulnerabilities that impact FortiGate and FortClient EMS. We also cover an arbitrary file read in Jenkins that has the sneaky potential to lead to RCE, but RCE depends on how well you fortify your deployments. Let’s fire up your favorite shell and listen to the sound of the ocean as we learn about the most trendy CVEs for March 2024.
Jenkins is an open-source automation platform that facilitates the building, testing, and deployment of software. The platform is typically accessed via an HTTP interface, but it also includes a command line interface (CLI) that can be used for scripting purposes. Researchers discovered that the CLI was prone to an unauthenticated arbitrary file read vulnerability that grants unauthorized attackers read access to the filesystem – at least the first three (3) lines of an arbitrary file. The vulnerability exists in the commands who-ami-i, enable-job, and keep-build as a result of insecure parsing of argument inputs. The Jenkins CLI leverages the args4j parsing library to parse command arguments. This library has a feature that replaces an @ character followed by a file path with the contents of the file, effectively treating the file contents as command arguments. The application behavior varies depending on the authentication status of the attacker. An unauthenticated user can only read the first three (3) lines of a file, however authenticated users can read the entire file system. Although unlikely, proof of concept code exists that demonstrates that attacks against the confidentiality key are possible, which could enable decryption attacks against secret keys used by Jenkins.
Under the correct conditions the vulnerability could be exploited to achieve remote command execution. The various attack scenarios defined in the Jenkins advisory are dependent on the configuration of the deployment, though some of the configuration settings would be present in a default deployment.
Proof of concept exploit code to read arbitrary files is available in the public domain, though RCE code is not yet prevalent. Given the critical nature of most Jenkins deployments it is likely that exploit code will continue to mature, resulting in more reliable remote command execution. Patch now! Jenkins admins unable to apply the patch should disable the CLI interface until such time the patch can be applied.
Severity | Complexity | CVSS Score |
Critical | Low | 9.8 |
Systems Impacted:
Read more:
FortiClient EMS is an enterprise endpoint management platform that was recently(ish) found to be prone to an unauthenticated SQL injection vulnerability. Although initially identified in 2023, Fortinet only recently released a patch to address a SQL injection vulnerability, which enabled researchers to triage the software and identify a root cause and exploit. FortiClient EMS daemon operates on TCP port 8013 (default) and has an additional local service (FCTDas.exe) that translates system telemetry into SQL queries sent to a SQL server database. An analysis of the data access server executable revealed that in addition to connecting to SQL server TCP localhost:1433, the binary also opened a listening socket on TCP localhost:65432. All of these components establish a local architecture where the EMS daemon operates on TCP 8013 and proxies requests to the data access layer. This also makes it the most likely entry point and means to target the database.
Using a clever test harness researchers were able to hook DLLs used by the EMS daemon and set breakpoints on specific function calls to identify the message format submitted to the service. The message consisted of a simple text based string of key=value pairs delimited by new line characters (\x0a) terminated with two carriage-return, new line feed characters (\x0d\x0a), most of which contained a FCTUID identifier. This discovery facilitated meaningful interaction with the EMS daemon independent of the EMS client. An analysis of debug log files generated by the data access service revealed that the FCTUID value frequently appeared in SQL queries. Using a simple Python script as a fuzzer the team discovered that the FCTUID value was vulnerable to SQL injection. Game over.
Remote command execution could be achieved only if xp_cmdshell was enabled on the SQL server database instance, however this is trivial to enable on default installations. The ability to execute xp_cmdshell indicates that the injection point was vulnerable to a specific class of SQL injection called stacked query execution. Stacked query execution greatly increases the attack surface and number of potential attack vectors, commensurately resulting in greater risk. In addition to executing commands on the vulnerable SQL server instance, it’s possible to compel the server to connect to an attacker-controlled host intended to hijack NetNTLMv2 hashes. Attackers can crack hashes offline or relay intercepted hashes to other systems in a domain that lack signing, such as SMB and LDAP. **Read more about this attack vector in our article about abusing default Windows behavior!
Fortinet has released a patch to address the vulnerability. It is strongly recommended you patch now!
Severity | Complexity | CVSS Score |
Critical | Low | 9.8 |
Systems Impacted:
Read more:
I think SSL VPN RCE may be my favorite combination of acronyms. A researcher has found that Fortinet’s FortiGate SSL VPN is vulnerable to a pre-auth RCE vulnerability. The vulnerability is a bit more complex than a vanilla shell code injection or serialization bug. It results from an out-of-bounds write during SSL negotiation.
The researchers began by extracting the contents of FortiGate VMs, available for download from Fortinet. The target of the research was the /bin/init binary, which has historically contained a bundle of various applications. Once access to /bin/init was attained in the unpatched and patched versions, the research team performed patch diffing using Ghidra for decompilation and bindiff for comparison. The analysis focused on functions that performed HTTP parsing. It was eventually discovered that the latest version of FortiGate contained additional logic to verify requests with chunked encoding.
Using a simple Python script fuzzer, it was possible to trigger a segfault (crash) on the appliance by submitting a malformed POST chunk request with excess chunk bytes. This is where things get a bit complex. A crash is a denial of service (DoS) vuln without the help of a proper debugger, so the team set about identifying methods to bypass integrity checks on the file system and enable remote GDB debugging. They were ultimately successful in defeating filesystem and kernel integrity checks. They deployed a patched /bin/init and a backdoored binary that replaced /bin/smartctl. The new unauthorized binary disabled sshd and enabled telnetd on port 22. The patched binaries were repackaged into the VM, the VM booted, and the team was able to launch the malicious /bin/smartctl binary. All of this just to remote debug via GDB. I love the tenacity of these researchers.
Having established a reliable framework for debugging it’s finally time to inspect the crash details. Without getting into too much detail, the researcher isolated how to overwrite heap addresses and direct execution to an arbitrary address via the SSL_do_handshake function. The final step in the process was to create a ROP chain and launch a reverse shell via Node. The entire chain from patch diff to exploitation is technically steep, though exploitation only requires two well crafted HTTP requests to bag RCE. Truly awesome research!
Severity | Complexity | CVSS Score |
Critical | Low | 9.8 |
Systems/Applications Impacted:
Read more:
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 the NopSec 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 the NopSec platform can do in action register for our monthly platform walkthrough webinar. Bring any questions you have and we’ll be happy to answer them!