CVE-2021-44228 - Log4j RCE 0-day

[shabbs]

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.

Yeah, everyone's server logs are now showing a crap ton of scanning and attempts with those calls from bots just trolling the internet looking for exploitable endpoints.
This week has not been very fun.

 

[shabbs]

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.

One of our apps was using pre-built EAR files from a vendor and we found a vulnerability inside that.

Yay.

 

[RMerlin]

Once most common local places are known expect browser attacks

Good point. This might easily lead to data theft.

 

[shabbs]

I don't know what's worse... this log4j issue or navigating my company's change management process.

 

[sfx2000]

One of our apps was using pre-built EAR files from a vendor and we found a vulnerability inside that.

Yay.

Lucky for me - we migrated from Log4j 1.2 to logback years ago...

Not for security purposes, but for performance - logback outperforms Log4j 1.x and 2.x by a good margin...

DId do a SW BOM scrub, just in case with upstream packages, but we dodged the bullet there this time.

For those who do have to remediate, I really can understand the amount of work it takes to fully fix the issue...

 

[shabbs]

Yeah, I think a lot of orgs will re-visit their logging tools and reliance on log4j/log4j2 after all this.

I'm still baffled at the introduction of the JNDI feature that enabled this issue. Was it just a "nice to have" that went sideways with an unexpected fallout...

 

[shabbs]

So uh... log4j 2.17 is now needed... I am not making this up.

We're literally deploying 2.16 now to our alternate site and I got the update.

FML.

 

[shabbs]

Info: https://www.bleepingcomputer.com/ne...o-log4j-216-surprise-theres-a-217-fixing-dos/

I mean, at this rate, I'm ready to just wait for 2.18....

I think we'll look to move to logback.

 

[RMerlin]

My guess is it's a crappy design. And once the focus was put on it and security experts started digging, then all the holes suddenly started to appear. Like what happened with OpenSSL in the Heartbleed craze.

 

[shabbs]

Yep. When the world is looking... everything gets exposed.
Feel bad for all the teams that went crazy last weekend getting 2.15 out for our internet facing apps, then again this weekend getting 2.16 out only to hear "Oh, hey, 2.17 please.... and ASAP."

 

[sfx2000]

I mean, at this rate, I'm ready to just wait for 2.18....

I think we'll look to move to logback.

uggh...

and as folks looked deeper, seems like logback does have some issues, see CVE-2021-42550

Anyways - note sent off to the vendor's SRE team to schedule a window...

Google put together a nice explainer - and yeah, IMHO, it does tend to poke a stern finger at the JVM community in general, I think we have not see the last of these kinds of issues...

Understanding the Impact of Apache Log4j Vulnerability

Posted by James Wetter and Nicky Ringland, Open Source Insights Team Editors Note: The below numbers were calculated based on both log4j-co...

security.googleblog.com

 

[shabbs]

and as folks looked deeper, seems like logback does have some issues, see CVE-2021-42550

LOL! Well, logback was based on log4j I think so... if there was historical issues, they may have come across.

Just can win.

Can we just have a logger that logs? We'll take care of the rest with Splunk.

 

[shabbs]

Well, at least that logback CVE is "moderate" and not high or critical...