Top Trending CVEs of May 2024

It’s May, baseball is in full swing and schools are nearly out for summer vacation. This month we take a look at a trio of vulns impacting everything from network monitoring and storage systems to desktop agents. It’s not all RCE, but sometimes it’s more interesting to see how a researcher solved a complex problem with sound fundamental reverse engineering techniques. Fill up your coffee, drop to a command line, and appreciate some truly clever problem solving as we dissect the trending CVEs of May 2024.

1. QNAP QTS RCE CVE-2024-27130

Qnap has a rich history of critical risk vulnerabilities that impact their network storage (NAS) solutions. This tradition continues thanks to the research team at watchTowr. Researchers decided to pop the hood on the QNAP QTS operating system that underpins a range of Qnap products. Their efforts resulted in the discovery and disclosure of over a dozen vulnerabilities of varying degrees of severity, which included unauthenticated remote command execution. 

They began their research with a QuTSCloud VM, available for download on the Qnap website. Access to the Linux OS the VM is based on enabled a detailed analysis of the application code. This consisted primarily of CGI scripts coded in C that were launched from a custom httpd service listening on TCP port 8080. The binary was disassembled using IDA, which led to the immediate identification of CGI endpoints vulnerable to numerous format string and overflow bugs. Given the prevalence of bugs the team decided to do some more basic testing and fired up cURL with a peppering of Python to send some excessively long strings. This test harness resulted in a segfault on the ‘/cgi-bin/filemanager/share.cgi’ endpoint.   

The segfault was triggered by the overflow of a 4104 byte buffer in the function “No_Support_ACL” via the injection-attacker-controlled input into the “name” URL query parameter. After identifying the memory layout of the stack and what an attacker could overwrite, identifying a path to exploitation was fairly trivial. It should be noted that exploitation required a few qualifiers. During their research the team decided to disable address space layout randomization (ASLR) so the exploit demonstrated does not function on out-of-the box QTS deployments. The attack also required that the trigger request contain a valid ssid value. The “ssid” value is a unique identifier assigned to a file for the purpose of easy sharing. It’s not required that the value correlate to a file managed on the NAS, but must be valid. A quick Google search will bag you plenty of “ssid” values to use for independent testing, so a properly formatted “ssid” value is easy like Sunday morning. 

As we mentioned, the remote command execution vuln was just one of more than a dozen identified. I have a feeling this won’t be the last time we cover a Qnap RCE vuln this year. Time will tell. Qnap has released a patch. Oddly, this vuln was only assigned a CVSS score of 7.2, which feels like it’s on the low side. You know the drill. Patch it!

Systems Impacted: 

• QTS 5.1.x
• QuTS hero h5.1.x

Read more: 

• https://nvd.nist.gov/vuln/detail/CVE-2024-27130
• https://www.qnap.com/en/security-advisory/qsa-24-23
• https://labs.watchtowr.com/qnap-qts-qnapping-at-the-wheel-cve-2024-27130-and-friends/

2. Fortinet FortiSIEM RCE CVE-2024-23108

Fortinet FortiSIEM is an enterprise security incident and event management system. Researchers have recently found that it is vulnerable to an unauthenticated remote command execution vulnerability. This is a bit of a deja-vu style vuln. If we turn back time and revisit CVE-2023-34992 we’ll find that Fortinet already pushed a patch for an incredibly similar vuln. Security is always a lesson in the cyclical nature of history. Gotta love it. 

This iteration of the command injection vulnerability is so similar to the first you’d be hard pressed to find a difference in the exploit code. To better understand how we got to this point, we decided to take a look at CVE-2023-34992. The initial remote command execution was identified by decompiling some of the WAR files that support the appliance. This provided a means to at least analyze the unauthenticated attack surface, which resulted in the identification of the LicenseUploadServlet class. A POST function within this class ultimately makes a call to the function sendCommand. The sendCommand function is interesting in that it sends binary encoded user controlled data to the monitor service on TCP port 7900 of the localhost. 

At this point the researchers needed to understand how to interact with the service. Binary payloads generally mean that a proprietary data stream is created by the client and parsed on the server. This application proved no different. Due to the lack of data validation on numerous fronts, researchers found it was possible to craft a payload to TCP port 7900 and execute some arbitrary code. This is highly over simplified, but one of key factors contributing to this vulnerability was that the sendCommand function used an integer identifier in the binary message to designate the type of command to be executed. This granted an unauthenticated attacker access to nearly every function available to the phMonitor service, i.e a huge attack surface. Neat!

Ok, so now that we’re familiar with the past, how does it relate to the present? The original exploit focused on injecting commands into the server IP address argument of a message. Fast forward to 2024 and the injection point has shifted to the second argument of the message. What was conventionally a disk mount path argument, now serves as a command injection vector. Who would have thought you needed to escape all the user controlled input, not just one argument? History hits hard. Fortinet has released a patch. Fingers crossed it buttons up this RCE bug for good.

Systems Impacted: 

Read more: 

• https://fortiguard.fortinet.com/psirt/FG-IR-23-130
• https://www.horizon3.ai/attack-research/disclosures/cve-2024-23108-fortinet-fortisiem-2nd-order-command-injection-deep-dive/
• https://nvd.nist.gov/vuln/detail/CVE-2024-23108

3. ManageEngine ADAudit CVE-2024-1212

ManageEngine seems to pop up in the news with some degree of regularity. It’s not entirely shocking given that they have roughly 50 discrete products available. The ADAudit software enables enterprises to monitor changes and misconfigurations to the Active Directory environment. The audit software running on the server provides basic data query functions for AD objects, but the product also includes an agent that runs on desktop systems to return more specific host level data. As we all know Active Directory is complex, so it stands to reason that software designed to monitor it would share this quality. 

ManageEngine often deploys products on top of Tomcat, which means application functionality is facilitated through a series of JAR files. Tomcat obviously doesn’t introduce risk, however it does ease the process of decompiling and reverse engineering code. This is where the research team at Shelltrail started. Their investigation led to the discovery that the ADAudit server communicates with connected agents via NamedPipes over TCP port 135. 

This is where the research gets pretty cool. The team decided to build an RCP client to interact with the ADAudit server. This wasn’t a trivial task and I encourage everyone to read the research. The ultimate result of their efforts was a means to interact with the server and the only requirement was an AD account in the Domain Users group, i.e basically all domain users. Great, the team created a client, but it doesn’t do much. So, they decided to decompile the ADAuditPlusAgent binary. 

It’s worth mentioning that one of the features of the AD agent was to capture sequential screenshots of user sessions as a means to identify state changes on the desktop. If an attacker could leverage this functionality via a malicious agent, then it would be possible to spy on the sessions of other users! 

With this goal in mind, the analysis of the decompiled agent code resulted in the discovery that a client UUID was needed to do anything meaningful with the server. A walk through the execution flow of the agent led the team to the Windows registry where an encrypted string used by the agent was located. As luck would have it, everything needed to decrypt the value was contained within the AD Agent. Putting all the pieces together, the team discovered that a low level user could read registry entries reserved to administrative users, which included the UUID of the agent. This enabled an attacker to gain unauthorized access to agent data and functionality, including screenshots of the Windows session of any system user. RCE would have been cooler, but I love a good information disclosure vulnerability. The research provides a solid foundation to conduct additional testing against the agent and ADAudit server. I feel like there’s more to be uncovered.

Systems/Applications Impacted:

• All ADAudit Plus builds below 7270

Read more: 

• https://www.manageengine.com/products/active-directory-audit/cve-2024-36037.html
• https://nvd.nist.gov/vuln/detail/CVE-2024-36037
• https://www.shelltrail.com/research/manageengine-adaudit-reverse-engineering-windows-rpc-to-find-cve-2024-36036-and-cve-2024-36037-part1/

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!