CVE-2021-21974 – VMware ESXi OpenSLP heap-overflow vulnerability

Why return to a 2021 vulnerability?

After the return of the CVE-2021-35394 vulnerability that we recently talked about following its active use by various botnets, it is now the turn of the CVE-2021-21974 to make headlines. The cause: the use of this vulnerability in a ransomware campaign targeting VMWare hypervisors.

On February 3rd, the OVH team warned of an attack on VMWare hypervisors, followed shortly by a CERT FR alert.

Shortly thereafter, organizations in various countries also issued alerts, such as the ACN in Italy or the CERT AT in Austria.

As confirmed by VMWare this is not a new vulnerability (0-day) but a vulnerability from two years ago.

The main vulnerability involved is CVE-2021-21974, a heap-overflow vulnerability in the OpenSLP component embedded in VMWare hypervisors.

Some details

OpenSLP proposes an implementation of the SLP protocol which is a service location service, allowing to transmit to a client information about services and their locations. A client requests information about a service, and the service returns a URL.

Among the features of the SLP protocol, there is a type of request, the directory agent advertisements, which allows a server to advertise itself as a Directory Agent, a component that keeps service advertisements in cache. The vulnerability lies precisely in this type of request. When receiving a message of this type, the message contains the length of the URL as well as the URL itself.

The vulnerability lies precisely in this type of request. When receiving a message of this type, the message contains the length of the URL as well as the URL itself.

However, the field containing the URL is read until the detection of a null character, if this one is not present, the reading will continue in the following fields but will be copied in a buffer having the expected size of the URL. This allows to divert the execution flow of the program and thus to obtain an arbitrary code execution.

In the case of this large-scale attack, arbitrary code execution was used to deploy a new ransomware called EsxiArgs because of the .args extension of the files created when encrypting them.

However, other ransomwares also seem to use this mode of infection like the Royal ransomware.

Detection and solution

The Sigflow rule with sid 2044114 allows to detect the attempts of exploitation of this vulnerability. This rule is available since February 03.

pastedGraphic.png

 

In its updated alert, CERT FR also provided information on procedures for recovering certain encrypted files:

 

On February 07, CISA published a script to facilitate this procedure:  https://github.com/cisagov/ESXiArgs-Recover .

 

Like the procedures published so far, this rebuilds VMDKs from information that has not been encrypted, so there is a possibility of failure.

 

As CISA states, it is essential to review and understand the actions performed by the script before executing it.

However, it should be noted that since February 8, a new strain of the EsxiArgs ransomware has appeared, making encrypted files unrecoverable.
In addition, some reports indicate that some servers have been reinfected despite the disabling of the SLP service, which raises doubts about the infection method.

VMWare has also updated the note about EsxiArgs (https://core.vmware.com/esxiargs-questions-answers#who-is-affected-by-this)indicating that attackers are probably using all available vulnerabilities.

 

Versions concerned

  • ESXi versions 7.x antérieures à ESXi70U1c-17325551
  • ESXi versions 6.7.x antérieures à ESXi670-202102401-SG
  • ESXi versions 6.5.x antérieures à ESXi650-202102101-SG

 

Author : Purple Team Gatewatcher

 

 

Resources