VMSA-2022-0004

  Three days ago another critical vulnerability has been announced by VMware around CVE-2021-22040, CVE-2021-22041 that are about the virtual machine USB controllers that let the "malicious actor with local administrative privileges on a virtual machine may exploit this issue to execute code as the virtual machine's VMX process running on the host." All ESXi versions 6.x and 7.x and Fusion 12.x and Workstation 16.x are vulnerable against this exploit. Fortunately there is a released patch to fix the issue (for example ESXi7.0 Update 3c), although there is a workaround for the mentioned vulnerabilities too. If you need to read more information: VMSA-2022-0004

However there is an attached file in the link below that you can use to list all VMs with connected USB controller and also remove them automatically: KB87617.

 

Log4Shell (Log4j) or Log 4 Hell ?!

 

From four days ago we did whatever we could do to make secure many infrastructures against the recent RCE (remote code execution) zero-day vulnerability: Apache log4j. Especially we focused on virtualization environments and critical components like vCenter Servers, vRealize Suite, Horizon View Connection Server's Apache Tomcat, and Unified Access Gateway (UAG). I truly confess it's a bad situation, very very bad. Personally, I believe that no exploit was worse than this in 2021, because there are many solutions from a variety of vendors that use Apache as the web App (and subsequently log4j as the Apache's logging component): From Cisco, VMware, Dell to many Industrial Applications of OT Networks.

The log4j is a Java-based logging framework of Apache web services, but its default JNDI feature (Java Naming & Directory Interface) is the primary point of this zero-day. The severity rate of this vulnerability is critical (10/10) that was publicly announced on Dec 9th, 2021 by the developer team and led them to release of the CVE-2021-44228.

All versions below 2.14.1 are vulnerable by default. However, in the last day Apache Software Foundation (ASF) announced the second vulnerability CVE-2021-45046 that version 2.15.0 can be affected too. So, the suggested workarounds are not enough and cannot address this catastrophic exploit lonely. SANS said: "The new version 2.16.0 has been made available to completely fix the issue (so far at least)"

As ASF explained about the Apache log4j 2 update: "In version 2.16.0 the message lookups feature has been completely removed. Lookups in configuration still work. Furthermore, Log4j now disables access to JNDI by default. JNDI lookups in configuration now need to be enabled explicitly. Also, Log4j now limits the protocols by default to only Java, LDAP, and LDAPS and limits the LDAP protocols to only accessing Java primitive objects. Hosts other than the localhost need to be explicitly allowed."

This vulnerability lets the attacker execute RCEs on target without authentication, which potentially is a high risk that you should never ignore. However, VMware announced VMSA-2021-0028 which listed all the exploitable products and also their current workarounds and possible fixes. Of course, there are many other products that are under investigation to find further weaknesses against the possibility of this vulnerability. So, I strongly recommend executing any immediate remediation action, because the situation is still @#$%ed up and one of the best choices is the following FAQ of this "In the Wild" exploit.

At last, you should be aware that in most products you cannot handle directly this issue and need to review the vendor's provided solution to fix it. While these actions are not enough to protect against the attacker's activities, but it was mentioned on many FAQs that adding this line: "-Dlog4j2.formatMsgNoLookups=true" has no require to revert back to the latest setting. So, it seems the patching will roll the products forward and is accommodated with the provided workarounds. Then I think it's not just a temporary solution.

Checkout the vulnerability (CVE-2021-21985)

 In the following of mentioned vulnerabilities in this post: VMSA-2021-0010 I prepared a video about how to check our vCenter server's vulnerability against the CVE-2021-21985 through the published NSE-Checker script in the corresponding GitHub link. But truly I forgot to publish it after a month ... LOL :) However, Now it's time to watch it:

YouTube: https://youtu.be/uMsZSVZJTBc

Instagram: https://www.instagram.com/tv/CQ1tdf4g8jD 

 

VMSA-2021-0002

 Around two weeks ago VMware announced a new series of RCE (Remote Code Executions) about some of products, especially two primary components of vSphere in versions of 6.5, 6.7, 7.0: ESXi and vCenter Server, and also Cloud Foundation (3x, 4.x). Three CVEs has been published for these security vulnerabilities and most of them is related to the HTML5 version of vSphere client (HTTPS:443). Because it will give the attackers unrestricted access to execute commands. To read more about these security breaches (CVE-2021-21972, CVE-2021-21973, CVE-2021-21974) you can read the VMSA-2021-0002.

In the following I mentioned a brief of their known targets:

21972: Let the attacker execute an RCE with unrestricted privileges on the VCSA via accessing port 443 on the network.

21973: Let to attacker send a POST request to VCSA HTML5 on port 443, and lead to information disclosure because of an SSRF (Server Side Request Forgery) vulnerability.

21974: Grant the attacker access to the ESXi via RCE on port 427 to trigger the heap-overflow issue in OpenSLP service.

Also for more information about another vulnerability about the vSphere Replication, read the VMSA-2021-0001

 

VMSA-2019-0005

VMware Security Advisory announced some security issues with critical severity and published appropriate hotfix updates for its relevant products that may has been compromised by this bug: VMware ESXi, Workstation & Fusion. Also vulnerabilities are about:
1. Virtual USB 1.1 Universal Host Controller Interface (UHCI) out-of-bounds read/write and Time-of-check Time-of-use (TOCTOU)
2. Intel E1000 / E1000E vAdapters out-of-bounds write (Fusion/workstation)
3. Unauthenticated APIs (Fusion only)

As VMware said: Exploitation of these issues may let an attacker to execute code on the host from a virtual machine.
CVE Numbers of these security problems are:

   CVE-2019-5514

   CVE-2019-5515

   CVE-2019-5518

   CVE-2019-5519

   CVE-2019-5524

For more information about this issue and other new recently issues, please refer to VMSA-2019-0005 on the VMware Security Advisory portal.