CVE-2021-44228 - Log4j RCE 0-day

[ForkWNY]

Yes, but people calling it "the worst security issue ever" have a short memory.

Heartbleed was more critical, because OpenSSL was far more widespread.

i was also around during the Windows XP days where worms could remotely infect machines and automatically spread itself (I forgot the name of the exploit). That was also a more critical security issue.

I believe you're referring to the lsass "Sasser" worm, going back to the Win XP era...that was a particularly bad security flaw.

 

[RMerlin]

I believe you're referring to the lsass "Sasser" worm, going back to the Win XP era...that was a particularly bad security flaw.

That's the one, yes.

 

[jasonmicron]

The Log4j vulnerability is definitely not the "worst threat to modern computing" in history. It's relatively easy to mitigate, pending that there isn't a lot of dependence on older versions of Java. If you can't patch, just disable remote control until a patch can be rolled out.

IMO it can be pretty bad because, unless you're the app developer, you need to wait for the developer to implement those mitigations. And then apply their patch.

Yes, it does seem easy to mitigate ourselves manually but if the app has an update that overwrites your mitigations then it is sort of pointless.

And now there is also this, but at a much lower attack entry point:

NVD - CVE-2021-4104

nvd.nist.gov

 

[jasonmicron]

That's the one, yes.

Hmm. Forgot about Sasser. Nice reminder @ForkWNY !

Sasser (computer worm) - Wikipedia

en.wikipedia.org

As I've learned more about this vulnerability I think it is indeed more critical than initially thought. Not because of the method to remediate - we already know that's easy.

The issue is this isn't a worm. This is an issue with how applications utilize log4jv2 (and seems some instances of v1).

And the only way that I can think of to mitigate is get the application in question using those libraries updated at the developer source. Which is out of reach for most of us unless we actually built the app or portion of the code using log4j.

I'd like to be wrong. Someone tell me I'm wrong. Sorry if I sound a bit panicky, I haven't had much sleep since Thursday since this was disclosed at work.

 

[shabbs]

Yeah this one is very troublesome in how easy it is to exploit and how prevalent it is.

Buddy tripped up Apple...

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

 

[hytekj]

Will be a busy week at my work patching, testing and deploying. Wheeeee... put the kettle on.

Seems even the very old versions of log4j (1.2.x) have scenarios under which they are also vulnerable. We've not hit that in our asset inventory... yet.

source? where did you see 1.2.x might be impacted?

 

[shabbs]

source? where did you see 1.2.x might be impacted?

It's mentioned in the overall CVE. The condition is that you have enabled/use JMSAppender in Apache Log4j 1.2.

See: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

For us, all our 1.2 instances don't make use of JMSAppender so we will upgrade/close those later as jumping from 1.2 --> 2.15 will likely require additional fixes/template updates/testing etc...

 

[itpp20]

Make sure its 2.16 or higher.

 

[RMerlin]

And the only way that I can think of to mitigate is get the application in question using those libraries updated at the developer source. Which is out of reach for most of us unless we actually built the app or portion of the code using log4j.

In many case, the issue can be mitigated just by launching the application with the -Dlog4j2.formatMsgNoLookups=true flag. This is what ElasticSearch did in their 7.16.1 release (note that ElasticSearch wasn't vulnerable due to how it's implemented, but they still added that startup flag just to be 100% safe).

That was the extent of what I had to deal with for my customers: two servers running recent ElasticSearch, updated to the latest versions. I spent more time scanning servers than actually fixing them.

 

[shabbs]

Make sure its 2.16 or higher.

Yeah just saw that now. Ugh.

 

[Jack Yaz]

In many case, the issue can be mitigated just by launching the application with the -Dlog4j2.formatMsgNoLookups=true flag. This is what ElasticSearch did in their 7.16.1 release (note that ElasticSearch wasn't vulnerable due to how it's implemented, but they still added that startup flag just to be 100% safe).

That was the extent of what I had to deal with for my customers: two servers running recent ElasticSearch, updated to the latest versions. I spent more time scanning servers than actually fixing them.

2.16 is needed as that flag isn't enough in all cases https://blog.cloudflare.com/protect...45046-the-additional-log4j-rce-vulnerability/

 

[jasonmicron]

source? where did you see 1.2.x might be impacted?

Here.

NVD - CVE-2021-4104

nvd.nist.gov

Disclosed by Red Hat. Here is the original disclosure:

cve-details

Description​

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

 

[RMerlin]

2.16 is needed as that flag isn't enough in all cases https://blog.cloudflare.com/protect...45046-the-additional-log4j-rce-vulnerability/

Oh great. A second vulnerability. At least Elasticsearch is already covered and does not require further mitigation steps, so I'm already covered with my own customers.

 

[RMerlin]

Moving this discussion to the General Security forum.

 

[shabbs]

Oh great. A second vulnerability. At least Elasticsearch is already covered and does not require further mitigation steps, so I'm already covered with my own customers.

Seems the original 2.15 was not patched... enough... sigh.

Waiting for 2.17... LOL

 

[RMerlin]

I'm having OpenSSL, Heartbleed-era vibes suddenly.

 

[willyburz]

Not my wheelhouse here at all...I kind of understand the bigger implications, but how does this affect personal devices like apple or android phones. What about chromebooks versus work pcs? Router impacts?

What are things you can do with your devices, if it's out of your control?

 

[RMerlin]

Not my wheelhouse here at all...I kind of understand the bigger implications, but how does this affect personal devices like apple or android phones. What about chromebooks versus work pcs? Router impacts?

What are things you can do with your devices, if it's out of your control?

This is largely a server issue. A local workstation may possibly be exploited if it runs an application that makes use of log4j, and there is a way for an end-user to generate a malicious log entry, that would allow him to possibly get privilege escalation. This is highly situational however.

 

[itpp20]

This is highly situational however.

Once most common local places are known expect browser attacks, this ain't just a server problem, btw. I have seen experimental jndi attacks from april this year, ' jndi.portal', ' .......jndi...ldap', ' jndi-appconfig', etc. This ain't a new-new thingie. And as this remains to be used everywhere expect new holes to be found.

 

[alba666]

I'm having OpenSSL, Heartbleed-era vibes suddenly.

Same here. Detection issues in nested jars, compressed jars, etc. are some things I have already read. Plus reprogramming headaches based on legacy version delta.