1 Background:
On February 3rd, 2023, the French CERT-FR brought attention to the ESXiArgs Ransomware campaign that continues to be used to target enterprises worldwide. This French advisory called out two vulnerabilities, both with Remote Code Execution capabilities, as being the vulnerabilities that the attackers targeted. A brief description of the two vulnerabilities is as follows:
a) VMware CVE-2020-3992: A malicious actor residing in the management network who has access to port 427 on an ESXi machine may be able to trigger a use-after-free in the OpenSLP service resulting in remote code execution
b) VMware CVE-2021-21974: A malicious actor residing within the same network segment as ESXi who has access to port 427 may be able to trigger the heap-overflow issue in OpenSLP service resulting in remote code execution
2 Controversy about targeted vulnerability
While the French CERT stood behind its finding, many in the industry have doubts whether these two vulnerabilities are the one powering the ESXiArgs campaign.
A quick reading of the description of the CVE shows that the bad actor needs to be inside the victim network and even more importantly must have access to VMware ESXi Server on Port 427. How does a bad actor that is remotely located become an insider? Clearly, there needs to be yet another remote code execution vulnerability in a public facing application that would have allowed the bad actor to penetrate the victim enterprise’s network perimeter. The Doubting Thomas’s point of view does have some merit. The last epitaph in this story hasn’t been written yet.
3 CISA’s Warning:
As more and more enterprises report being affected by the ESXiArgs ransomware campaign, CISA, took notice and released, into its global Github repository, a best-effort recovery script for the ESXiArgs Ransomware campaign. Unfortunately, the disclaimer “While CISA works to ensure that scripts like this one are safe and effective, this script is delivered without warranty, either implicit or explicit. Do not use this script without understanding how it may affect your system. CISA does not assume liability for damage caused by this script” diluted the enthusiasm a script like this would have ordinarily received.
4 Lots of Food for Thought from this Saga
This campaign and its handling thus far made us ponder the following:
4.1 Smoking Gun or Just a Coincidence?
When exploit code for a critical vulnerability is just one Google search away, even relatively unskilled attackers get empowered. It turns out that the exploit code (deliberately not hyperlinked here) for CVE-2020-3992 was posted on GitHub on the same day that French CERT posted its warning. The timing of this all makes one wonder – how thin is the line dividing ethics and putting third-party enterprises at risk?
4.2 Can we even patch fast enough?
Given that the two vulnerabilities enumerated by the French CERT require local privileges, the bad actor clearly leveraged yet another (unknown at this time) remote code execution vulnerability to infiltrate the enterprise’s perimeter. Only after that could the bad actor have leveraged either one of the two or perhaps even some other VMware remote code execution vulnerability. A quick search in the NVD database throws up scores of vulnerabilities in VMware’s ESXi servers that could have been equally contributory. One thing that is abundantly clear is that vulnerabilities with Remote Code Execution (RCE) capabilities have been and will continue to be the nemesis of the enterprise.
A Security Control is needed to stop a bad actor in zero or near zero-dwell time, even if an RCE vulnerability hasn’t been patched for some exigent reason. In fact, depending on a patch to save the day is just wishful thinking. Why? Because bad actors are increasingly being able to exploit vulnerabilities within minutes of public disclosure, especially when exploit code gets posted on the Internet. What enterprise can patch its software infrastructure in minutes of finding out about a vulnerability?
4.3 Can a generic Compensating Control be used to defend against a random RCE Vulnerability?
If the vulnerabilities cited by the French CERT are responsible, we must wonder why the victim enterprises didn’t patch in the past three years. Especially ones with such a massive blast radius as the VMware ESX server vulnerability. After all, one vulnerability was disclosed in 2020, and the other one in 2021. There better be a very strong reason to continue to ignore such a vulnerability.
There is a good reason that enterprises do not patch vulnerabilities early on. Almost every enterprise host will experience business discontinuity when the ESXi Server needs to be patched. Which CIO wants to go tell the CEO that they intend to take a maintenance window that will shut down the operations of the entire company? Given that scores of RCE vulnerabilities are reported into the NVD every day, the infrastructure may spend more time in the maintenance window than generating revenue.
When it comes to trading patching for business continuity, we all know how that cookie will crumble. This tradeoff begs the question - what if there were a Compensating Control that could protect the workload without having to live through the recurring patching nightmare? Wouldn’t it be the best of both worlds if that were possible?
4.4 Is winning the cyber battle if we continue to chase after Attacker tactics, techniques, and procedures (TTPs) a lost cause?
EDRs monitor predefined system call sequences to determine if the application executed some MITRE TTPs associated with attacker activity. When the EDR observes such a TTP, it doesn’t immediately blow the alarm; instead, it waits for a while to see if the app throws up more such TTPs.
Why? MITRE has defined a series of operations in its ATT&CK framework as being indicative of attacker activity. Unfortunately, many such operations are also executed routinely by a pristine application. For example, MITRE defines “escalation of privileges” as an operation indicative of an attacker at work. Almost all browsers will escalate privilege routinely during their normal functioning. An aggressive EDR could easily flag such normal activity on the part of an app as an attack. Declaring that an app is under attack too early results in false alarms, and declaring too late results in even greater dwell time for the bad actor.
Once the volume of TTPs exceeds a certain threshold in a predefined time interval, the EDR declares the application under attack. One leading EDR functions as follows: if the application being monitored executes the sleep function over 500 times in a 5-minute interval, the EDR concludes with a medium probability that the app is malicious.
Bad actors have figured out various techniques that individually and collectively game the EDR algorithm.
Today’s attackers are cashing in on this time-based vulnerability in EDR solutions. They are increasingly turning to Millisecond Malware that “explodes” in a second or two using hitherto unseen procedures (which is the “P” in the MITRE TTP). It takes some ransomware a mere second or two to complete their agenda.
If tracking TTPs using EDRs is the only control we use, there is no hope of winning the battle against attackers. A paradigm shift in mindset is needed. This shift involves seeking out and deploying those Security Controls that do not get caught up in knots when it comes to distinguishing between an Application’s Intent and an Attacker’s Intent. An attacker can change their intent on a dime, but an application is rigid in that its code does not change during the lifetime of the app.
What is not needed is a Security Control that draws on attacker-related artifacts, be it the signature of a file-based malware, some YARA Rule, or even some Threat Feed that acts as training data for the AI/ ML Engine of the security control. What is needed, instead, is a Security Control that can extract and impose the application’s intent precisely and in real-time and therefore is totally immune to the millions of shenanigans an attacker can resort to.
5 Conclusion
Virsec’s VSP Platform has been designed so that it will protect applications even if the app is not patched. Therefore, it can act as a generic compensating control for RCE vulnerabilities. Unlike EDRs, VSP tracks application intent, which is highly predictable, as opposed to tracking attacker intent which can change on a dime. And it can do so today.
The typical US enterprise’s boardroom should be asking itself the question – should we roll over and give up and accept that the attacker will always win, or is there something we can do to actively defend ourselves? We as a nation do not subscribe to the sit back and accept defeat philosophy. We, therefore, believe that the boardroom should seek out and invest in Security Controls that can withstand the havoc that known-or-unknown, patched-or-unpatched remote code execution vulnerabilities will inevitably unleash.
To take the battle forward, please contact or visit us at www.virsec.com.
