Skip to main content

Hi Everyone,

 

Vulnerabilities wait for no-one, so whilst some are enjoying a weekend off, others are patching to protect against the latest risk. Log4j.

 

This post has two objectives. Firstly I’m sharing my write up regarding the issues I’m aware DO have an impact to VMware, secondly what does this mean to the Veeam products…

 

First up: VMware

I don’t often dedicate a blog post to a particular security vulnerability, but since it has scored a perfect 10 CVE rating, it’s important to be aware ASAP.

VMware have identified multiple products that utilise the Apache technology that are vulnerable to the Log4j vulnerability.

 

What is this “Log4j” vulnerability?

A Remote Code Execution (RCE) has been discovered in Apache’s Log4j Java Library. It is possible to insert maliciously crafted strings into fields that will be logged, which then leverages the “message lookup substitution” function of Log4j to execute code. This can be used to deploy and execute payloads, or execute commands at a heightened privilege level.

This is trivial to reproduce now the vulnerability has been confirmed to exist, hence the high score. This vulnerability isn’t exclusive to VMware.

 

What can I do?

Firstly, keep an eye on this VMware page for the latest updates and patch your systems as updates become available. It’s also a good idea to firewall your systems to prevent unauthorised access to limit any attack footprint. But restricting the footprint is of no substitute for a patch.

Finally, if you’re one of those people living on the edge with an externally accessible vCenter, odds are good you’ve already been compromised, get it off the internet now and check!

 

Second, What about Veeam?

I posted on the Veeam R&D forum this morning regarding Veeam’s vulnerability status regarding this, and thankfully it appears Apache isn’t used by any Veeam product, however the Veeam security team are still investigating.

 

I’ll cross-post any important updates but you can see the thread yourself here.

 

Hopefully Veeam won’t be impacted by this one as it’s honestly one of the scarier vulnerabilities I’ve ever seen due to how widespread this is.

 

Finally, a shout-out to @regnor as he was going to post about this himself if I hadn’t already! More eyes on these topics is always a good thing and I’m sure he’ll follow up with any insights that I’ve missed!

 

—UPDATE—

 

Veeam have confirmed via the R&D forum and via a KB that none of their products are impacted (thanks @Mildur )

https://www.veeam.com/kb4254

:warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning:

Nearly full list of whats vendor/products are affected:

https://github.com/NCSC-NL/log4shell/tree/main/software

 :warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning::warning:

grazie Signore


Unfortunately, there’s a new second CVE that’s need a new patch.

https://nvd.nist.gov/vuln/detail/CVE-2021-45046

Yes, log4j 2.16.0 is needed now. And who knows if this is the last issue :sunglasses:

Unfortunately this is getting worse. At first there was concern this would result in Denial of Service attacks, now the CVE severity is expected to be increased from 3.7 to around 9 as limited Remote Code Execution (RCE) has been discovered.


Great post @MicoolPaul ! It has been a hell of a week regarding this issue, to mitigate the infrastructure of the customers...


Not sure if helpful, but INE posted this video about how log4j is exploited and how can be mitigated (double patch, the only first still permit DOS)

 


Thanks for sharing @marcofabbri, the more people know; the better they can apply the right mitigations.

 

Upon further review the second patch can cause DOS and RCE, but RCE so far has only been proven via macOS it seems.


VMware started to offer fixes for their VDI products:

https://www.vmware.com/security/advisories/VMSA-2021-0028.html

They also updated their workaround KB-article for the new finding, @MicoolPaul mentioned:

https://kb.vmware.com/s/article/87081. There is a new script to remove Java classes.


If interested: Here is a list of all HPE products NOT affected:

https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-a00120086en_us

Here is a list of all affected HPE products and versions:

https://support.hpe.com/hpesc/public/docDisplay?nlaid=HPGL_ALERTS_3009925&docId=emr_na-hpesbgn04215en_us


Comment