ESXIArgs

ESXIArgs

Executive Summary

ESXiargs is a vulnerability that affects VMware ESXi hypervisors. It was discovered in 2020 and allows an attacker to execute code with elevated privileges on a vulnerable system, potentially leading to full compromise of the host and any virtual machines running on it. This vulnerability is caused by a flaw in the way ESXi handles certain arguments passed to the virtual machine monitor (VMM), and can be exploited by sending specially crafted network packets to a vulnerable system. To mitigate the risk of ESXiargs attacks, VMware has released security patches for affected versions of ESXi, and it is recommended that users apply these updates as soon as possible. Additionally, it is important to follow general security best practices, such as keeping systems and software up to date and properly configured, to minimize the risk of successful attacks.

Advisory

Involved:  CVE-2021-21974, CVE-2020-3992, CVE-2019-5544

Root Cause: VMWare ESXi’s OpenSLP

Impact

Encrypt .vmdk.vmx.vmxf.vmsd.vmsn.vswp.vmss.nvram.vmem

Prevention:

1.We blocked the OpenSLP port (427) between internet and the servers with ESXI installed. Customer can deactivate the filtering rule in their management interface if the use of port 427 is required for whatever reason.

Version:

7.0 before ESXi70U1c-17325551, 

6.7 before ESXi670-202102401-SG, 

6.5 before ESXi650-202102101-SG

Technical detail

The OpenSLP vulnerability in VMware ESXi refers to a security vulnerability that was discovered in the Simple Service Discovery Protocol (SSDP) implementation of the OpenSLP library used by VMware ESXi. This vulnerability allows an attacker to remotely execute arbitrary code on the ESXi host by sending specially crafted SSDP packets to the affected system.

The OpenSLP vulnerability affects VMware ESXi versions 5.5, 6.0, 6.5, and 6.7. An attacker can exploit this vulnerability by sending malicious SSDP packets to the ESXi host, which can cause a buffer overflow and allow the attacker to execute arbitrary code on the system. The code executed by the attacker can be used to install malware or ransomware on the ESXi host, potentially compromising all virtual machines running on the affected system.

The code execution can be achieved through various techniques such as stack buffer overflow, heap buffer overflow, or other memory corruption techniques. When the attacker’s code is executed on the ESXi host, it can potentially install malware or ransomware on the system, compromising all virtual machines running on the affected host.

The Heap Overflow Bug (CVE-2021-21974) exists only in VMware’s implementation of SLP. Here is the simplified pseudocode:

__int64 __fastcall SLPParseSrvUrl(int srvurllen, const char *srvurl, _QWORD *a3) 

{ 

// ... 

  obuf = calloc(1uLL, srvurllen + 53LL); 

  if ( !obuf ) 

    return 12LL; 

  v6 = strstr(srvurl, ":/"); // <-- (5) 

  if ( !v6 ) 

  { 

    free(obuf); 

    return 22LL; 

  } 

  memcpy((char *)obuf + 41, srvurl, v6 - srvurl);  // <-- (6) 

// ... 

}

To address the vulnerability, VMware has released patches that modify the OpenSLP library’s implementation of the SSDP protocol to properly handle incoming SSDP packets and prevent buffer overflows. The patches also include additional security measures, such as stack canaries, to further mitigate the risk of successful attacks.

srvurl comes from network input, but the function does not terminate srvurl with a NULL byte before using strstr(). The out-of-bounds string search leads to a heap overflow at (6). This happened because VMware did not merge an update from the original OpenSLP project.

The Patch for CVE-2021-21974

Six weeks later, the third patch (build- 17325551) was released. It addressed the root cause of the heap overflow bug by checking the length before the memcpy

.__int64 __fastcall SLPParseSrvUrl(int srvurllen, const char *srvurl, _QWORD *a3) 

{ 

// ... 

  v5 = srvurllen + 5; 

  obuf = calloc(1uLL, v5 + 48LL); 

  if ( !obuf ) 

    return 12LL; 

  v6 = strstr(srvurl, ":/"); 

  if ( !v6 || v5 - 1 < (unsigned __int64)(v6 - srvurl) )   // return with error if the length is too large 

  { 

    free(obuf); 

    return 22LL; 

  } 

// ... 

}

It’s important for organizations running vulnerable versions of VMware ESXi to apply the patches as soon as possible to protect against this and similar attacks. Additionally, they should implement strong security measures, such as firewalls and intrusion detection systems, to minimize the risk of attack. Regular backups and disaster recovery planning are also important to ensure that organizations can quickly recover from a successful attack.

How to started

ESXiargs ransomware is a malicious software that infects systems running VMware ESXi, a popular virtualization platform. The ransomware is designed to target virtual machines (VMs) running on the affected host and encrypt their data, making it inaccessible to the user.

The attack typically starts with the attackers gaining access to the ESXi host, which they can do through various means such as exploiting vulnerabilities in the software, using stolen credentials, or through phishing scams. Once they have access, they can deploy the ransomware, which will then infect and encrypt the VMs running on the host.

args ransomware is typically advanced and difficult to reverse, making it important for organizations to have a robust backup system in place to quickly recover from an attack. The attackers typically demand a ransom payment in exchange for the decryption key, which is required to restore access to the encrypted data.

In terms of the technical implementation, ESXiargs ransomware typically works by using a combination of symmetric and asymmetric encryption algorithms to encrypt the data on the targeted virtual machines. The ransomware generates a unique encryption key for each affected VM, which is then encrypted using the attacker’s public key. This means that the attackers hold the only copy of the private key required to decrypt the encrypted data.

Once the encryption process is complete, the ransomware will usually display a ransom note on the affected VMs, informing the user of the attack and the ransom demand. The note may also contain a deadline for payment and instructions on how to contact the attackers to arrange payment.

It’s important to note that paying the ransom does not guarantee that the attackers will provide the decryption key, and it also funds and encourages the attackers to continue with these malicious activities. As such, organizations should focus on implementing strong security measures and having a disaster recovery plan in place to minimize the impact of a ransomware attack.

How to restore

If your files have been encrypted by a ransomware variant that uses the esxiargs encryption method, it is not possible to restore the encrypted files without paying the ransom or having a backup of the encrypted files. Ransomware attacks are a serious threat to your data, and paying the ransom is not recommended, as it only encourages the attackers and does not guarantee that you will get your files back.

Here are the steps you can take to restore encrypted files if you have a backup:

  • Disconnect your computer from the internet to prevent any further spread of the ransomware.
  • Locate and restore the backup of your encrypted files to a separate location.
  • Scan your computer using a reputable antivirus software to remove the ransomware.

If you do not have a backup, your best course of action is to contact a professional data recovery service that specializes in ransomware attacks. These services may be able to help you restore your encrypted files, but it will likely come at a high cost.

In any case, it is always recommended to keep regular backups of your important files and to have strong security measures in place, such as up-to-date antivirus software, to prevent future attacks.

Of course you can use CISA’s ESXiArgs script for recovery encrypted file in some cases.

CISA’s ESXiArgs script is based on findings published by the third-party researchers mentioned above. Any organization seeking to use CISA’s ESXiArgs recovery script should carefully review the script to determine if it is appropriate for their environment before deploying it. This script does not seek to delete the encrypted config files, but instead seeks to create new config files that enable access to the VMs. 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.

Usage:

  • Download this script and save it as /tmp/recover.sh. For example, with wget: wget -O /tmp/recover.sh https://raw.githubusercontent.com/cisagov/ESXiArgs-Recover/main/recover.sh
  • Give the script execute permissions: chmod +x /tmp/recover.sh
  • Navigate to the folder of a virtual machine you would like to decrypt (you may browse these folders by running ls /vmfs/volumes/datastore1). For instance, if the folder is called example, run cd /vmfs/volumes/datastore1/example
  • Run ls to view the files. Note the name of the VM (e.g. if there is a file example.vmdk, the name of the VM is example).
  • Run the recovery script with /tmp/recover.sh [name], where [name] is the name of the virtual machine determined in step 4. If the virtual machine is a thin format, run /tmp/recover.sh [name] thin.
  • If successful, the decryptor script will output that it has successfully run. If unsuccessful, this may mean that your virtual machines cannot be recovered.
  • If the script succeeded, the last step is to re-register the virtual machine.
  • If the ESXi web interface is inaccessible, take the following steps to remove the ransom note and restore access (note that taking the steps below moves the ransom note to the file ransom.html. Cconsider archiving this file for future incident review).
  • Run cd /usr/lib/vmware/hostd/docroot/ui/ && mv index.html ransom.html && mv index1.html index.html
  • Run cd /usr/lib/vmware/hostd/docroot && mv index.html ransom.html && rm index.html & mv index1.html index.html
  • Reboot the ESXi server (e.g., with the reboot command). After a few minutes, you should be able to navigate to the web interface.
  • In the ESXi web interface, navigate to the Virtual Machines page.
  • If the VM you restored already exists, right click on the VM and select “Unregister”.
  • Select “Create / Register VM”.
  • Select “Register an existing virtual machine”.
  • Click “Select one or more virtual machines, a datastore or a directory” to navigate to the folder of the VM you restored. Select the vmx file in the folder.
  • Select “Next” and “Finish”. You should now be able to use the VM as normal.

If needed, the script will save encrypted files in a new encrypted_files folder within each virtual machine’s directory.

Conclusion

It is important for organizations to implement strong security measures, such as regular backups and software updates, to protect against ransomware attacks. Additionally, they should have a disaster recovery plan in place to ensure they can quickly recover from an attack, if necessary.

It’s recommended to take preventive measures, such as:

  • Regularly back up critical data and store the backups offline
  • Keep software and operating systems up to date with the latest patches and security updates
  • Train employees on how to recognize and avoid suspicious emails and attachments
  • Use strong and unique passwords, and regularly change them
  • Implement a comprehensive security solution, such as antivirus software, firewalls, and intrusion detection systems.

It’s highly discouraged to pay the ransom, as it does not guarantee that the attackers will provide the decryption key, and also it funds and encourages the attackers to continue with these malicious activities.

References