A Truesec investigation

Log4j – How To Secure Your VMware Horizon, UAG and vCenter Servers Against the Log4Shell Vulnerability (CVE-2021-44228)

Log4Shell is a critical (10.0 CVSS) vulnerability that affects thousands of products running Apache Log4j. VMware vCenter Server, Horizon and VMware UAG (Unified Access Gateway) are some of them and since Horizon/UAG are sometimes reachable from the entire internet, they will most likely get attacked if they’re not urgently secured.

(Update 2021-12-11, 21:00 CET: Workaround for UAG has just been announced, see link below)

(Update 2021-12-12, 17:00 CET: Added information about a workaround for vCenter Server)

(Update 2021-12-17, 10:30 CET: Added information about Horizon patches being released, and the updated information about vCenter patching)

(Update 2022-01-27, 15:30 CET: Added information about vCenter Server 7.0 patches being released)

Step 1 – VMware Horizon/UAG

Identify which UAG or Horizon components are reachable from the internet, and start with those. Consider cutting them off from the internet, both for incoming and outgoing traffic, until the patch/workaround is fully implemented.

Patches have now been released. Upgrade to the following versions, if you can:

  • Horizon 8 version 2111
  • Horizon 7 versions 7.13.1, 7.10.3

If you can’t upgrade, implement the latest workarounds: Workaround for UAG: VMware KB #87092. Workaround for Horizon Server: VMware KB #87073

After securing the internet-accessible servers, follow the instructions above and implement the patch/workaround for the remaining Horizon server(s) and then the Horizon agents. The workaround has to be implemented on all agents, including the master image(s) used for cloning.

Step 2 – vCenter Server

After that, proceed with the rest of your VMware systems running Log4j: vCenter Server, WS1 Access / Identity Manager, Log Insight, etc.

Since 2022-01-27 there are patches released for vCenter Server Appliance 7.0, but if you are still on 6.5 or 6.7 you need to perform the workarounds described below. The 7.0 patches are included in 7.0 U3c (7.0.3 build 19193900), which also includes additional security patches for cURL, Tomcat, OpenSSL etc.

The workaround for vCenter Server is available at: VMware KB #87081. Note that the workaround needs to be re-run to also cover CVE-2021-45046! Download and run the updated script if you haven’t already done it.

For vCenter Server, there is a Python script available that automates the workaround changes: VMware KB #87088 (VCSA only).

vCenter Server for Windows (which I hope you are not still running) also has a workaround released: VMware KB #87096

The remaining workarounds can be found in the VMSA-2021-0028 main article, which is updated as new products/patches/workarounds get added. The workarounds are slightly differently implemented for each VMware product, but they were initially mostly based on adding the option ‘-Dlog4j2.formatMsgNoLookups=true’ to the Log4j configuration, but has since been updated to instead delete or disable the vulnerable component .

Monitor the VMSA-2021-0028 article for information about patches being released. When the patches become available, make sure you test and install them. A tested patch is usually better than a temporary workaround, especially now that some workarounds have been deemed to not fully protect against all variants of attacks (CVE-2021-45046 (mitre.org)).

Take this opportunity to perform the necessary steps to prevent your ESXi hosts from executing ransomware: Secure Your VMware ESXi Hosts Against Ransomware

Step 3

Check the rest of your environment for vulnerable systems using Log4j and upgrade/patch/mitigate them. Start with the systems that are reachable from the internet. Check with your other software vendors regarding whether they are vulnerable or not. A good starting list of vendor articles can be found at https://gist.github.com/SwitHa…

Watch our video ‘What You Need to Know About the Log4Shell / Apache Log4j Injection Vulnerability (CVE-2021-44228)‘:

Step 4

Check for possible compromise and malicious
activity in your environment. Where are your Horizon components placed,
and where could an attacker have gone from there if they compromised
those servers/clients? Check for suspicious connections to the internet, lateral movement, processes, downloads, and other Indicators of Compromise using your EDR and logs. More details are available in our blog post: Log4j / Log4Shell Explained – All You Need to Know

Contact us if you need help with forensics or incident response! The contact details are on this page: Current cyber attack? | Get instant incident response – Truesec

References

More information about which VMware products are vulnerable to Log4Shell, their workarounds, and patches is being added to the advisory and FAQ:

Note that there is also a list of VMware products that are *not* affected by Log4Shell: VMware KB #87068. At the time of writing, the following products are some of the ones on the list:

  • VMware vSphere ESXi
  • VMware vCloud Director
  • VMware NSX Advanced Load Balancer (Avi)
  • VMware Software-Defined WAN (SD-WAN)
  • VMware Tanzu Kubernetes Grid
  • VMware App Volumes
  • VMware ThinApp
  • Dynamic Environment Manager (DEM)
  • Workspace ONE Unified Endpoint Management (UEM)
  • VMware Workstation
  • VMware Fusion

Good Luck!

Cybersecurity