Why am I here? Welcome back to the Bug Report! For those in the audience unfamiliar with our shtick, we compile a shortlist of the top vulnerabilities every month. For this month, and in light of Valentine’s Day, I humbly offer this short poem for our readers:
Roses are red,
violets are blue,
Even with love and RCE payloads in the air, we’ve managed to survive the month of February without an industry-wide meltdown. However, some impactful vulnerabilities have been released and identified as being used in the wild. So, without further ado, sit back, grab your leftover conversation hearts, and let’s dive into the following CVEs:
- CVE-2021-21974 – VMware ESXi
- CVE-2022-39952 – Fortinet FortiNAC
- CVE-2023-25136 – OpenSSH
- CVE-2023-23530 + CVE-2023-23531 – Apple macOS and iOS
CVE-2021-21974: You still haven’t patched your ESXi box?
What is it?
You read that correctly; this is a CVE from 2021 that has been exploited extensively in the wild these past few weeks. The latest ransomware surge has resurrected this CVE, returning it to the top 10 this month. This particular issue is a heap overflow in VMware ESXi’s OpenSLP (Service Location Protocol) service, a way that devices can share what services they host and discover others. Successful exploitation allows for arbitrary code execution.
As mentioned, this older CVE has been resurrected by ransomware gangs actively exploiting it. Consider yourself vulnerable if your organization runs an ESXi server that hasn’t been updated since February 2021. Figure 2, courtesy of VMware’s February 2021 security advisory, lists the specific versions that address the issue for ESXi server 6.5, 6.7, and 7.0.
Figure 2: CVE-2021-21974 Response Matrix.
At the same time, this issue is around two years old, and a surprising number of vulnerable ESXi instances are exposed to the internet. To investigate how many lazy sysadmins are out there, we ran a simple Shodan scan looking for ESXi servers still running the vulnerable versions. According to our search, we discovered over 48,000 servers, as seen in Figure 3.
Figure 3: Shodan scan for vulnerable ESXi servers.
It is worth noting that this number is inflated by the fact that we did not verify how many of the 48k vulnerable instances also had the SLP port exposed. However, we have identified thousands of positive detections across the globe.
@ACEResponder has compiled a simple-to-follow series of questions to determine if your ESXi server has been compromised:
Figure 4: A simple IoC check. (Image credit @ACEResponder)
There is also publicly available POC code online, which I suspect is the basis for many of these ransomware gangs exploiting this vulnerability.
What can I do?
As you may have guessed, a patch is available, along with workarounds for those who cannot patch. If you can’t patch right this second, we’re happy to inform you that mitigation is as simple as disabling the SLP daemon; instructions for accomplishing this can be found here. Of course, Trellix has you covered with relevant signatures (for both the vulnerability and the ransomware being deployed) across our various products, from Endpoint Security to Network Security to Helix; more information can be found here.
Prior to ESXi 7.0 U2c, the SLP daemon is enabled and listening on port 427 by default. Thus, it is recommended, even with the official patch, to disable this daemon if you haven’t already. On the subject of mitigations, this is also an excellent time to mention that it is essential to have offsite backups, even for VMs. ESXi allows for taking snapshots and exporting VMs, which should be done regularly for critical systems.
CVE-2022-39952: Fingers crossed that zip only contains an appliance key
What is it?
CVE-2022-39952—publicly released on February 16th, 2023—allows for arbitrary file writes with root permissions. This vulnerability affects Fortinet FortiNAC software, best described in their words: „FortiNAC is a zero-trust access solution that oversees and protects all digital assets connected to the enterprise network, covering devices from IT, IoT, OT/ICS to IoMT.“ However, there seems to be a mix-up between zero-trust and zero-auth, as this vulnerability allows an unauthenticated user to have an arbitrary write anywhere on the system. The arbitrary write originates from an unprotected file upload designed for users to upload an „appliance key“ as a zip file.
Well, we know for a fact that threat actors care about this one. Which means that if your organization uses the FortiNAC access solution, you likely have a lot of catching up to do in the caring department. We try to abstain from determining the criticality of a CVE based on CVSS alone; however, this one is a stunner with a 9.8 out of 10. This high score is primarily because it is very trivial to exploit. The unsanitized upload is processed with a script (Figure 5), which changes the directory (cd) to the root folder, allowing the extraction to write to any location. Then, the vulnerable script instructs the unzip command to overwrite any existing files without confirmation with the -o flag.
Figure 5: The vulnerable script that allows for arbitrary system write.
With the simplicity of the vulnerability, there are already multiple POCs available on the web, and I would expect to see many scanners looking for vulnerable versions to exploit over the internet. One indicator of compromise (IoC) to look for is the line „Running config ApplianceXML“ in the log file „/bsc/logs/output.master.“
What can I do?
It is imperative to patch the system as soon as possible. You can find all affected versions and patch information here. As no available workarounds exist at the time of this writing, patching is the only surefire remediation for this vulnerability. That being said, Trellix Network Security also has your back with detection for CVE-2022-39952 via rule „Fortinet Fortinac CVE-2022-39952 keyUpload.jsp RCE.“ Those using Trellix IPS are also covered via signature ID 0x452c4b00.
CVE-2023-25136: Good thing my organization is still running OpenSSH v0.11
Figure 6: There is no cloud; it is often just someone’s Linux server.
What is it?
This vulnerability was introduced in version 9.1 of OpenSSH, allowing an unauthenticated user to crash the service via a double-free bug. Currently, the exploitation attempts have only resulted in a Denial of Service (DoS); however, this bug has excellent potential, as the attacker can control the instruction pointer (IP/RIP). This also jibes with the CVSSv3 rating, which has Integrity and Confidentiality impacts both marked as High, which is not common for a simple DoS. We will be keeping a close eye on this CVE to see if anyone can make a useful exploit out of it.
The statement „There is no cloud, it’s just someone else’s computer“ could easily be changed to „someone else’s Linux computer,“ as Linux systems are still the most prevalent server operating system. The most common way for administrators to remotely manage and update Linux systems is through SSH, which makes CVE-2023-25136 a big deal.
As mentioned, SSH is a widespread way of remotely managing servers. Furthermore, OpenSSH’s implementation is the most popular and the default SSH server/client installed on all major Linux distributions. I would be surprised if any organization didn’t have at least one machine listening on port 22, SSH’s default listening port. The good news is that many distributions of Linux don’t update to the bleeding edge very often, meaning that most SSH servers deployed today are probably on older versions of OpenSSH that are unaffected by this issue. For instance, the latest long-term support (LTS) version of Ubuntu 22.04 is still on OpenSSH version 8.9p1.
What can I do?
It is best to double-check each system with an exposed SSH port and verify it is not running OpenSSH version 9.1. If any of them are, following the recommended procedure to update your system’s software should suffice, and a reboot most likely will not be needed. If you would like to get more information on this issue, OpenWall has included a ton of detail here, and if you want to see the git commit that fixed the issue, that can be found here.
While the developers could not successfully exploit this issue, it doesn’t mean that it is impossible to exploit. During the bug’s reproduction, control of the RIP register was obtained, which allowed the execution to jump to any address in the OpenSSH binary’s address space. Because this vulnerability may be successfully exploited in the future, you can breathe a sigh of relief knowing that Trellix Network Security has you covered with signature “OpenSSH server 9.1 CVE-2023-25136 Double-Free Vulnerability.”
CVE-2023-23530 + CVE-2023-23531: Wow, this hacker must be a genius! 😉
Disclaimer: While we try not to toot our own horn too much on this publication, we genuinely believe this research done by our Advanced Research Center deserves a spotlight this month.
Apple takes many precautions to eliminate all forms of dynamic code execution by using code signing and scripting languages like AppleScript. Austin Emmitt of our Advanced Research Center has discovered a new vulnerability class that would allow attackers to bypass these restrictions and gain dynamic code execution. CVE-2023-23530 and CVE-2023-23531 are classified as elevation of privilege (EoP) bugs that will enable an attacker to bypass security mechanisms and run arbitrary code in the context of several platform applications with varying privileges.
This should be of concern if your organization uses Apple’s *OS, meaning iOS (iPhones, iPads) or macOS (MacBooks, iMacs, Macs). These CVEs are within a new class of bugs for Apple products and have introduced a significant breach to the *OS security model. If you are an Apple security nerd, this may sound similar to what was taken advantage of in the ForcedEntry exploit utilized by Pegasus, spyware developed by the Israeli cyber-arms company NSO Group, as both our original research and the primitives used by ForcedEntry exploit the dynamic nature of NSPredicates. With our team bringing this vulnerability to light, more bugs are expected to be discovered and secured.
What can I do?
A small amount of malicious code can exploit either of these vulnerabilities. Because the base primitive of NSPredicates is not inherently hostile, an application downloaded from the App Store could be an attack vector used by bad actors. It would be wise to upgrade macOS to 13.2 and iOS to 16.3 or greater, which addresses these vulnerabilities, as soon as possible. The official Apple security advisory can be found here.