Security
Headlines
HeadlinesLatestCVEs

Headline

Ongoing VMware ESXi Ransomware Attack Highlights Inherent Virtualization Risks

The global assault on vulnerable VMware hypervisors may have been mitigated by updating to the latest version of the product, but patch management is only part of the story.

DARKReading
#vulnerability#mac#apple#git#intel#rce#vmware#ssh#zero_day

Organizations using older versions of VMWare ESXi hypervisors are learning a hard lesson about staying up-to-date with vulnerability patching, as a global ransomware attack on what VMware has deemed “End of General Support (EOGS) and/or significantly out-of-date products” continues.

However, the onslaught also points out wider problems in locking down virtual environments, the researchers say.

VMware confirmed in a statement Feb. 6 that a ransomware attack first flagged by the French Computer Emergency Response Team (CERT-FR) on Feb. 3 is not exploiting an unknown or “zero-day” flaw, but rather previously identified vulnerabilities that already have been patched by the vendor.

Indeed, it was already believed that the chief avenue of compromise in an attack propagating a novel ransomware strain dubbed “ESXiArgs” is an exploit for a 2-year-old remote code execution (RCE) security vulnerability (CVE-2021-21974), which affects the hypervisor’s Open Service Location Protocol (OpenSLP) service.

“With this in mind, we are advising customers to upgrade to the latest available supported releases of vSphere components to address currently known vulnerabilities,” VMware told customers in the statement.

The company also recommended that customers disable the OpenSLP service in ESXi, something VMware began doing by default in shipped versions of the project starting in 2021 with ESXi 7.0 U2c and ESXi 8.0 GA, to mitigate the issue.

Unpatched Systems Again in the Crosshairs

VMware’s confirmation means that the attack by as-yet unknown perpetrators that’s so far compromised thousands of servers in Canada, France, Finland, Germany, Taiwan, and the US may have been avoided by something that all organizations clearly need to do better — patch vulnerable IT assets — security experts said.

“This just goes to show how long it takes many organizations to get around to patching internal systems and applications, which is just one of many reasons why the criminals keep finding their way in,” notes Jan Lovmand, CTO for ransomware protection firm BullWall.

It’s a “sad truth” that known vulnerabilities with an exploit available are often left unpatched, concurs Bernard Montel, EMEA technical director and security strategist for security exposure management firm Tenable.

“This puts organizations at incredible jeopardy of being successfully penetrated,” he tells Dark Reading. “In this case, with the … VMWare vulnerability, the threat is immense given the active exploitation.”

However, even given the risks of leaving vulnerable systems unpatched, it remains a complex issue for organizations to balance the need to update systems with the effect the downtime required to do so can have on a business, Montel acknowledges.

“The issue for many organizations is evaluating uptime, versus taking something offline to patch,” he says. “In this case, the calculation really couldn’t be more straightforward — a few minutes of inconvenience, or days of disruption.”

Virtualization Is Inherently a Risk

Other security experts don’t believe the ongoing ESXi attack is as straightforward as a patching issue. Though lack of patching may solve the problem for some organizations in this case, it’s not as simple as that when it comes to protecting virtualized environments in general, they note.

The fact of the matter is that VMware as a platform and ESXi in particular are complex products to manage from a security perspective, and thus easy targets for cybercriminals, says David Maynor, senior director of threat intelligence at cybersecurity training firm Cybrary. Indeed, multiple ransomware campaigns have targeted ESXi in the past year alone, demonstrating that savvy attackers recognize their potential for success.

Attackers get the added bonus with the virtualized nature of an ESXi environment that if they break into one ESXi hypervisor, which can control/have access to multiple virtual machines (VMs), “it could be hosting a lot of other systems that could also be compromised without any additional work,” Maynor says.

Indeed, this virtualization that’s at the heart of every cloud-based environment has made the task of threat actors easier in many ways, Montel notes. This is because they only have to target one vulnerability in one instance of a particular hypervisor to gain access to an entire network.

“Threat actors know that targeting this level with one arrow can allow them to elevate their privileges and grant access to everything,” he says. “If they are able to gain access, they can push malware to infiltrate the hypervisor level and cause mass infection.”

How to Protect VMware Systems When You Can’t Patch

As the latest ransomware attack persists — with its operators encrypting files and asking for around 2 Bitcoin (or $23,000 at press time) to be delivered within three days of compromise or risk the release of sensitive data — organizations grapple with how to resolve the underlying issue that creates such a rampant attack.

Patching or updating any vulnerable systems immediately may not be entirely realistic, other approaches may need to be implemented, notes Dan Mayer, a threat researcher at Stairwell. “The truth is, there are always going to be unpatched systems, either due to a calculated risk taken by the organizations or due to resource and time constraints,” he says.

The risk of having an unpatched system in and of itself may be mitigated then by other security measures, such as continuously monitoring enterprise infrastructure for malicious activity and being prepared to respond quickly and segment areas of attack if a problem arises.

Indeed, organizations need to act on the assumption that preventing ransomware “is all but impossible,” and focus on putting tools in place “to lessen the impact, such as disaster recovery plans and context-switched data,” notes Barmak Meftah, founding partner at cybersecurity venture capital firm Ballistic Ventures.

However, the ongoing VMware ESXi ransomware attack highlights another issue that contributes to an inherent inability for many organizations to take the necessary preventative measures: the skill and income gaps across the globe in the IT security realm, Mayer says.

“We do not have enough skilled IT professionals in nations where wealthy companies are targets,” he tells Dark Reading. “At the same time, there are threat actors across the globe who are able to make a better living leveraging their skills to extort money from others than if they took legitimate cybersecurity work.”

Mayer cites a report by the international cybersecurity nonprofit (ICS2) that said to secure assets effectively, the cybersecurity workforce needs 3.4 million cybersecurity workers. Until that happens, “we need to ramp up training these workers, and while the gap still exists, pay those with the skills around the world what they are worth, so they don’t turn to being part of the problem,” Mayer says.

Related news

Keep Tier-One Applications Out of Virtual Environments

Crafty bad actors can infect all of an organization's virtual machines at once, rendering tier-one applications useless.

CVE-2023-33953: Security Bulletins

gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks: - Unbounded memory buffering in the HPACK parser - Unbounded CPU consumption in the HPACK parser The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client. The unbounded memory buffering bugs: - The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb. - HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse. - gRPC’s metadata overflow check was performed per frame, so ...

New ESXiArgs Ransomware Variant Emerges After CISA Releases Decryptor Tool

After the U.S. Cybersecurity and Infrastructure Security Agency (CISA) released a decryptor for affected victims to recover from ESXiArgs ransomware attacks, the threat actors have bounced back with an updated version that encrypts more data. The emergence of the new variant was reported by a system administrator on an online forum, where another participant stated that files larger than 128MB

CISA Offers Recovery Tool for ESXiArgs Ransomware Victims

By Deeba Ahmed The recovery tool is available on GitHub for free. This is a post from HackRead.com Read the original post: CISA Offers Recovery Tool for ESXiArgs Ransomware Victims

CISA Releases Recovery Script for Victims of ESXiArgs Ransomware

The malware has affected thousands of VMware ESXi hypervisors in the last few days.

VMware Disputes Old Flaws at Root of ESXiArgs Ransomware Attacks

By Deeba Ahmed The refutation came days after Europe and North America were rattled by ESXiArgs Ransomware attacks. This is a post from HackRead.com Read the original post: VMware Disputes Old Flaws at Root of ESXiArgs Ransomware Attacks

VMware Finds No Evidence of 0-Day in Ongoing ESXiArgs Ransomware Spree

VMware on Monday said it found no evidence that threat actors are leveraging an unknown security flaw, i.e., a zero-day, in its software as part of an ongoing ransomware attack spree worldwide. "Most reports state that End of General Support (EoGS) and/or significantly out-of-date products are being targeted with known vulnerabilities which were previously addressed and disclosed in VMware

Global Ransomware Attack on VMware EXSi Hypervisors Continues to Spread

The fresh "ESXiArgs" malware is exploiting a 2-year-old RCE security vulnerability (tracked as CVE-2021-21974), resulting in thousands of unpatched servers falling prey to the campaign.

Two year old vulnerability used in ransomware attack against VMware ESXi

Categories: Exploits and vulnerabilities Categories: News Categories: Ransomware Tags: VMware Tags: ESXi Tags: Nevada Tags: ransomware Tags: Linux Tags: CVE-2021-21974 Over the weekend, several CERTs warned about ongoing ransomware attacks against unpatched VMware ESXi virtual machines. (Read more...) The post Two year old vulnerability used in ransomware attack against VMware ESXi appeared first on Malwarebytes Labs.

New Wave of Ransomware Attacks Exploiting VMware Bug to Target ESXi Servers

VMware ESXi hypervisors are the target of a new wave of attacks designed to deploy ransomware on compromised systems. "These attack campaigns appear to exploit CVE-2021-21974, for which a patch has been available since February 23, 2021," the Computer Emergency Response Team (CERT) of France said in an advisory on Friday. VMware, in its own alert released at the time, described the issue as an

CVE-2022-1941: Security Bulletins  |  Customer Care  |  Google Cloud

A parsing vulnerability for the MessageSet type in the ProtocolBuffers versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 3.21.5 for protobuf-cpp, and versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 4.21.5 for protobuf-python can lead to out of memory failures. A specially crafted message with multiple key-value per elements creates parsing issues, and can lead to a Denial of Service against services receiving unsanitized input. We recommend upgrading to versions 3.18.3, 3.19.5, 3.20.2, 3.21.6 for protobuf-cpp and 3.18.3, 3.19.5, 3.20.2, 4.21.6 for protobuf-python. Versions for 3.16 and 3.17 are no longer updated.

CVE-2021-21974: VMSA-2021-0002

OpenSLP as used in ESXi (7.0 before ESXi70U1c-17325551, 6.7 before ESXi670-202102401-SG, 6.5 before ESXi650-202102101-SG) has a heap-overflow vulnerability. 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.

DARKReading: Latest News

Cross-Site Scripting Is 2024's Most Dangerous Software Weakness