Log4J Vulnerability

[stereo_grabb 0]

Is there any information on ESET Protect and Log4J CVE-2021-44228?

[Marcos 5,070]

We don't use Log4J in our products so they are not affected by the vulnerability.

[itman 1,659]

This is a 10.0 rated critical vulnerability:

Quote

Yesterday, December 9, 2021, a very serious vulnerability in the popular Java-based logging package Log4j was disclosed. This vulnerability allows an attacker to execute code on a remote server; a so-called Remote Code Execution (RCE). Because of the widespread use of Java and log4j this is likely one of the most serious vulnerabilities on the Internet since both Heartbleed and ShellShock.

It is CVE-2021-44228 and affects version 2 of log4j between versions 2.0-beta-9 and 2.14.1. It is not present in version 1 of log4j and is patched in 2.15.0.

But, if you work for a company that is using Java-based software that uses log4j you should immediately read the section on how to mitigate and protect your systems before reading the rest.

How to Mitigate CVE-2021-44228

To mitigate the following options are available (see the advisory from Apache here😞

1. Upgrade to log4j v2.15.0

2. If you are using log4j v2.10 or above, and cannot upgrade, then set the property

log4j2.formatMsgNoLookups=true

3. Or remove the JndiLookup class from the classpath. For example, you can run a command like

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

to remove the class from the log4j-core.

https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/

Edited December 11, 2021 by itman

[bvj 1]

14 hours ago, Marcos said:

We don't use Log4J in our products so they are not affected by the vulnerability.

That's irrelevant in terms of mitigating the vulnerability at the endpoint.

[itman 1,659]

It also should be emphasized that patching is the best mitigation against this vulnerability:

Quote

"While the best mitigation against this vulnerability is to patch log4j to 2.15.0 and above, in Log4j version (>=2.10) this behavior can be mitigated by setting system property log4j2.formatMsgNoLookups to true or by removing the JndiLookup class from the classpath," Cybereason explains on the Logout4Shell GitHub Page.

"Additionally, if the server has Java runtimes >= 8u121, then by default, the settings com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase are set to “false”, mitigating this risk.

This may sound like a helpful tool to quickly neutralize the vulnerability in an environment you manage. Still, there are obvious concerns that threat actors or grey hat hackers will co-opt it for illegal behavior.

It is common for threat actors to breach a device and patch vulnerabilities to block other hackers from taking over a compromised server.

There is also concern that security researchers may use the vulnerability to remotely fix servers, even though doing something like this is considered illegal.

However, this has not stopped grey hats from using exploits to take vulnerable devices offline. In the past, we saw the BrickerBot malware take vulnerable routers offline, and gray hates exploiting Internet-connected printers to issue warnings to take them offline.

https://www.bleepingcomputer.com/news/security/researchers-release-vaccine-for-critical-log4shell-vulnerability/

Edited December 11, 2021 by itman

[MrWrighty 6]

17 minutes ago, bvj said:

That's irrelevant in terms of mitigating the vulnerability at the endpoint.

Why, it’s not up to Eset to patch endpoints.

[bvj 1]

2 minutes ago, MrWrighty said:

Why, it’s not up to Eset to patch endpoints.

Another irrelevant entry. 

[MrWrighty 6]

5 minutes ago, bvj said:

Another irrelevant entry. 

So instead of spouting irrelevance, suggest what they do for endpoints not under their control.

[bvj 1]

3 minutes ago, MrWrighty said:

So instead of spouting irrelevance, suggest what they do for endpoints not under their control.

The issue concerns the endpoints under ESET protection! 
 

InfoWorld How to detect the Log4j vulnerability in your applications
https://www.infoworld.com/article/3644492/how-to-detect-the-log4j-vulnerability-in-your-applications.html

Kaspersky Critical vulnerability in Apache Log4j library
https://www.kaspersky.com/blog/log4shell-critical-vulnerability-in-apache-log4j/43124/

CrowdStrike Log4j2 Vulnerability “Log4Shell” (CVE-2021-44228)
https://www.crowdstrike.com/blog/log4j2-vulnerability-analysis-and-mitigation-recommendations/

ESET
"We don't use Log4J in our products so they are not affected by the vulnerability."
"it’s not up to Eset to patch endpoints."

 

 

[TonyK 3]

18 hours ago, bvj said:

The issue concerns the endpoints under ESET protection! 
 

InfoWorld How to detect the Log4j vulnerability in your applications
https://www.infoworld.com/article/3644492/how-to-detect-the-log4j-vulnerability-in-your-applications.html

Kaspersky Critical vulnerability in Apache Log4j library
https://www.kaspersky.com/blog/log4shell-critical-vulnerability-in-apache-log4j/43124/

CrowdStrike Log4j2 Vulnerability “Log4Shell” (CVE-2021-44228)
https://www.crowdstrike.com/blog/log4j2-vulnerability-analysis-and-mitigation-recommendations/

ESET
"We don't use Log4J in our products so they are not affected by the vulnerability."
"it’s not up to Eset to patch endpoints."

 

 

 

 

You're comparing apples to oranges here:

 

ESET Endpoint products (inclusive of 'Server-branded' AV engines - unaffected, they don't use apache- the installs do not place any form of Apache on these systems

 

--------

Your endpoints aren't at risk directly, if you're solely utilizing HTTP Proxy to distribute content to those systems or connectivity to ESET's public servers, then there is a potential issue (though again ESET saying they don't utilize those components)

 

ESET PROTECT (management console) - there are two web-engines on this system:

The TOMCAT engine, which runs the front-end ESET PROTECT UI Webpage, again not applicable

The only component that is potentially impacted is the APACHE HTTP PROXY component, ESET did release 9.0.10.2 of the Protect console -- but those not wanting to download a gig to update a 12MB install, the literal only change is that under the HTTP Proxy component download, that is showing 2.4.51.0 for downloads

 

So there is either potential on the Log4J or just simply keeping up with the latest release of Apache (which being a security company, makes sense)...

 

In the time it took to explain this, updating the 12mb installer and hopping your config file changes, you'd be done 

 

And the statement is correct about it's not up to ESET to patch endpoints is true -- you deploy your own version updates to your endpoints (though if you're already running 9 on console and endpoints, automation for workstation-version ESET is already in place)

[itman 1,659]

Also this vulnerability is applicable to non-commercial installations:

Quote

Swedish video game developer Mojang Studios has released an emergency Minecraft security update to address a critical bug in the Apache Log4j Java logging library used by the game's Java Edition client and multiplayer servers.

The vulnerability is fixed with the release of Minecraft: Java Edition 1.18.1, which is now rolling out to all customers.

"This release fixes a critical security issue for multiplayer servers, changes how the world fog works to make more of the world visible, and fixes a couple of other bugs," the company said today.

"If you are running a multiplayer server, we highly encourage you to upgrade to this version as soon as possible."

https://www.bleepingcomputer.com/news/security/minecraft-rushes-out-patch-for-critical-log4j-vulnerability/

Edited December 13, 2021 by itman

[ChrisTG74 0]

Sorry, but the answer "We don't use Log4J in our products so they are not affected by the vulnerability. " already answered the question. There is no vulnerbility. I just did some test against the ESET Protect server and can confirm that it is obviously not affected by this exploit.

Any further steps that may be needed on your side to make things save again, that are caused by vulnerbilities in 3rd party software like applications on your server and desktops, are beyond what ESET is bound to provide.

Crying for them to do so is like taking a car company in account for someone killing people by driving too fast trough the city.

[Marcos 5,070]

More information here:

https://support.eset.com/en/alert8188

[100 2]

2 hours ago, Marcos said:

More information here:

https://support.eset.com/en/alert8188

"As of December 11th, the Network Attack Protection feature in ESET security products on Windows was updated to detect the vulnerability. ESET has been blocking attempted attacks from 14:24 CET the same day."

https://twitter.com/cyb3rops/status/1469601401143803905

 

[mahume 0]

On 12/11/2021 at 9:39 AM, Marcos said:

We don't use Log4J in our products so they are not affected by the vulnerability.

Are you sure?

I think there is log4j used in tomcat for ESMC...

[bvj 1]

22 hours ago, TonyK said:

 

Your endpoints aren't at risk directly

 

You realize the ESET business/enterprise line covers servers, right?  

And I never mentioned anything about patching.
 

If this isn't ESET's problem, why the following?   To appease the "uninformed"?

https://support.eset.com/en/alert8188-information-regarding-the-log4j2-vulnerability?ref=esf
 

As of December 11th, the Network Attack Protection feature in ESET security products on Windows was updated to detect the vulnerability. ESET has been blocking attempted attacks from 14:24 CET the same day.

 

Interesting that ESET was on it from Day Zero despite the ridiculous and irrelevant company responses that were posted.

 

[bvj 1]

22 hours ago, TonyK said:

  You're comparing apples to oranges here:

 

Is this an apple or an orange?  And do you know which ESET software uses tomcat?  

./usr/share/java/tomcat/log4j.jar

 

[Marcos 5,070]

1 hour ago, bvj said:

Is this an apple or an orange?  And do you know which ESET software uses tomcat? 

 Tomcat uses juli, not log4j:

[jboddy 0]

Just ran some of the Windows detection scripts on my Protect server - with Apache HTTP server -  and no Log4j found.

[BrianMorris 15]

I figured I'd jump in for fun! I tried to test for the vulnerability:

(as Marcos keeps saying, they don't use log4j; also, if an endpoint tries to USE the exploit, it will be stopped -- that's cool)

[MartinK 378]

Mentioned detection is network-based, so it will be blocking all such attempts, regardless of their target and possible impact or presence of vulnerability.

Also log4j presence in ESET PROTECT was mentioned, without any further details - in case ESET PROTECT Appliance was meant, log4j present there (and not used by ESET PROTECT services) is of older and unaffected version.

[Marcos 5,070]

There is also a write-up on this vulnerability available at https://www.welivesecurity.com/2021/12/13/log4shell-vulnerability-what-we-know-so-far/.

[itman 1,659]

Since multiple forum threads are currently active on this vulnerability, ESA is affected by it:

Quote

Elasticsearch utilized by the ESET Secure Authentication (ESA) reporting engine is partially affected by the CVE-2021-44228 vulnerability found in the log4j2 library

https://support.eset.com/en/kb8190-vulnerability-log4j2-in-the-reporting-engine-elasticsearch-of-eset-secure-authentication?ref=esf

Eset is currently working on a hotfix for it:

Quote

As Peter has mentioned please visit the page where it is all covered with a recommendation from the Development Team. However, meanwhile we are preparing a hotfix for this vulnerability and it should be available this week.

https://forum.eset.com/topic/30706-log4j-eset-secure-authentication/?do=findComment&comment=143877

[itman 1,659]

Time to patch again!

Quote

Last week, version 2.15 of the widely used open-source logging library Log4j was released to tackle a critical security hole, dubbed Log4Shell, which could be trivially abused by miscreants to hijack servers and apps over the internet.

That release closed the hole (CVE-2021-44228) by disabling by default the Java library's primarily exploitable functionality: JNDI message lookups. Now version 2.16 is out, and it disables all JNDI support by default, and removes message lookup handling entirely for good measure, hopefully finally preventing further exploitation.

This is needed because version 2.15 is still exploitable in certain non-default configurations, and this moderate-severity oversight has earned its own bug ID: CVE-2021-45046.

https://www.theregister.com/2021/12/14/apache_log4j_2_16_jndi_disabled/

Edited December 15, 2021 by itman

[itman 1,659]

Quote

Ditch Log4j 2.15: DNS exfiltration & RCE possible

Log4j 2.15.0 might contain even more severe vulnerabilities than the ones discovered so far, which is why 2.16.0 is by far a safer bet.

Because of CVE-2021-45046 described above, the maximum impact from the flaw initially appeared to be DoS, but that assumption is evolving, BleepingComputer has learned.

Cloud security firm Praetorian demonstrated how Log4j 2.15.0 versions could still be abused for DNS-based data exfiltration from external hosts, and is working with Apache towards a coordinated disclosure.

In an email interview with BleepingComputer, Praetorian's principal security engineer, Anthony Weems sheds more light on the research:

"The Praetorian blog post is in response to CVE-2021-45046, which applies to Log4j version 2.15. The CVE description states that—when using a specific type of Pattern Layout—this vulnerability can lead to a denial of service. The reason they state it is DoS only is due to the localhost allowlist," Weems tells BleepingComputer.

"We've developed a bypass for this 'localhost' allowlist and sent the details to Apache. At minimum, this means systems that are vulnerable to CVE-2021-45046 are not just vulnerable to DoS, but also DNS exfil of potentially sensitive environment variables."

https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/

Edited December 17, 2021 by itman