• Skip to main content
  • Skip to secondary menu
  • Skip to primary sidebar
The Blog of Jorge de la Cruz

The Blog of Jorge de la Cruz

Everything about VMware, Veeam, InfluxData, Grafana, Zimbra, etc.

  • Home
  • VMWARE
  • VEEAM
    • Veeam Content Recap 2021
    • Veeam v11a
      • Veeam Backup and Replication v11a
    • Veeam Backup for AWS
      • Veeam Backup for AWS v4
    • Veeam Backup for Azure
      • Veeam Backup for Azure v3
    • VeeamON 2021
      • Veeam Announces Support for Red Hat Enterprise Virtualization (RHEV/KVM)
      • Veeam announces enhancements for new versions of Veeam Backup for AWS v4/Azure v3/GVP v2
      • VBO v6 – Self-Service Portal and Native Integration with Azure Archive and AWS S3 Glacier
  • Grafana
    • Part I (Installing InfluxDB, Telegraf and Grafana on Ubuntu 20.04 LTS)
    • Part VIII (Monitoring Veeam using Veeam Enterprise Manager)
    • Part XII (Native Telegraf Plugin for vSphere)
    • Part XIII – Veeam Backup for Microsoft Office 365 v4
    • Part XIV – Veeam Availability Console
    • Part XV – IPMI Monitoring of our ESXi Hosts
    • Part XVI – Performance and Advanced Security of Veeam Backup for Microsoft Office 365
    • Part XVII – Showing Dashboards on Two Monitors Using Raspberry Pi 4
    • Part XIX (Monitoring Veeam with Enterprise Manager) Shell Script
    • Part XXII (Monitoring Cloudflare, include beautiful Maps)
    • Part XXIII (Monitoring WordPress with Jetpack RESTful API)
    • Part XXIV (Monitoring Veeam Backup for Microsoft Azure)
    • Part XXV (Monitoring Power Consumption)
    • Part XXVI (Monitoring Veeam Backup for Nutanix)
    • Part XXVII (Monitoring ReFS and XFS (block-cloning and reflink)
    • Part XXVIII (Monitoring HPE StoreOnce)
    • Part XXIX (Monitoring Pi-hole)
    • Part XXXI (Monitoring Unifi Protect)
    • Part XXXII (Monitoring Veeam ONE – experimental)
    • Part XXXIII (Monitoring NetApp ONTAP)
    • Part XXXIV (Monitoring Runecast)
  • Nutanix
  • ZIMBRA
  • PRTG
  • LINUX
  • MICROSOFT

VMware: How to detect the Log4j vulnerability on vCenter with Runecast, and how to patch it manually

17th December 2021 - Written in: runecast, vmware

Greetings friends, what a couple of great days we have been having, right? First the 0day vulnerability on Grafana, which I recommend you to upgrade to the latest version. And now Apache Log4j. I have been waiting to write about it, as the article would be focused on VMware Center, and I wanted to get to the bottom of it, and as you might be aware, the first fix was not enough, so VMware has announced another extra python Script.

Step-by-step on Monitoring with Runecast 6.0.1.0 (includes Apache Log4j Java vulnerability notification), and patching manually vCenter

In the next video, I show you how to detect the Apache Log4j vulnerability on Center with Runecast 6.0.1.0, and we walk through together the two scripts to remediate for now, as a workaround meanwhile VMware works on a final solution, I hope you like it:

Some prerequisites from the official KBs:

  • vCenter High Availability (VCHA) needs to be removed before executing the steps. – https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.avail.doc/GUID-3FB5A1F3-286E-460C-B9F4-9A47E2DFFE8A.html
  • Python script needs to be executed on both vCenter and PSC appliances in environments with external Platform Services Controller (PSC). I am assuming that you do not have anymore external platform services controllers, but just in case you are in 6.5, or 6.7, please be aware.

A quick look at Log4J by NCSC.GOV.UK

What is Log4j?

Modern software can be large, powerful, and complex. Rather than a single author writing all the code themselves as was common decades ago, modern software creation will have large teams, and that software is increasingly made out of ‘building blocks’ pulled together by the team rather than entirely written from scratch.

A team is unlikely to spend weeks writing new code when they can use existing code immediately.

Log4j is one of the many building blocks that are used in the creation of modern software. It is used by many organizations to do a common but vital job. We call this a ‘software library’.

Log4j is used by developers to keep track of what happens in their software applications or online services. It’s basically a huge journal of the activity of a system or application. This activity is called ‘logging’ and it’s used by developers to keep an eye out for problems for users.

What’s the issue?

Last week, a vulnerability was found in Log4j, an open-source logging library commonly used by apps and services across the internet. If left unfixed, attackers can break into systems, steal passwords and logins, extract data, and infect networks with malicious software.

Log4j is used worldwide across software applications and online services, and the vulnerability requires very little expertise to exploit. This makes Log4shell potentially the most severe computer vulnerability in years.

Who is affected by this?

Almost all software will have some form of ability to log (for development, operational, and security purposes), and Log4j is a very common component used for this.

For individuals, Log4j is almost certainly part of the devices and services you use online every day. The best thing you can do to protect yourself is to make sure your devices and apps are as up-to-date as possible and continue to update them regularly, particularly over the next few weeks.

For organizations, it may not be immediately clear that your web servers, web applications, network devices, and other software and hardware use Log4j. This makes it all the more critical for every organization to pay attention to our advice, and that of your software vendors, and make necessary mitigations.

Official KBs to be informed

So, at the moment you can find everything you need on the next two KB:

  • https://kb.vmware.com/s/article/87081
  • https://kb.vmware.com/s/article/87088
  • https://www.vmware.com/security/advisories/VMSA-2021-0028.html

Wait, is my Center version affected? Check by yourself but the answer is YES:

Keep an eye on the VMSA-2021-0028 for more up-to-date information.

Filed Under: runecast, vmware Tagged With: log4j, log4j vmware, vmware 10 cve, vmware fix, vsphere log4j

Reader Interactions

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

  • E-mail
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • YouTube

Posts Calendar

December 2021
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
2728293031  
« Nov   Jan »

Disclaimer

All opinions expressed on this site are my own and do not represent the opinions of any company I have worked with, am working with, or will be working with.

Copyright © 2025 · The Blog of Jorge de la Cruz