Log4j, Log4Shell, public exploits, oh my!
Limor Sylvie Kessem, CISM, CCISO
Cyber Crisis Management Global Lead @ IBM Consulting | Certified CISO
The internet is heaving with information about a major security vulnerability in the Log4j logging library. Some say it will "haunt the internet for years". Let's unpack and see what needs to be done at this time:
Log4j is a Java-based logging utility, part of the Apache Logging Services. Imagine writing your daily activities into a notebook - that notebook is Log4j. Developers and programmers use it to keep track of events in applications and servers.?These logs can be very detailed and are also often used in detecting issues and even attacks. As such, Log4j is used extensively throughout enterprise networks, which is what makes any issue with it ever more impactful.
This ubiquitous logging library, in specific versions, is vulnerable to remote code execution. The vulnerability was announced on December 9, 2021 by Chen Zhaojun of the Alibaba Cloud Security Team. It was reported as CVE-2021-44228, a.k.a. Log4Shell. This is a high-severity vulnerability that affects the core function of Log4j, and a publicly available exploit. Publicly available exploit means that your organization has likely already seen numerous scan attempts looking for vulnerable places to exploit and potentially gain initial foothold. Researchers noted that the exploit can be further used to read server environment variables. As such, if Git credentials, AWS keys (or other secrets) are static, they can be stolen without needing full RCE.
What's Vulnerable?
All Apache log4j versions from 2.0 up to and including 2.14.1 and all frameworks (e.g. Apache Struts2, Apache Solr, Apache Druid, Apache Flink, etc.) that use these versions, are vulnerable. That includes popular services like iCloud, Steam, and Minecraft.
There's a rolling list of all affected software on GitHub, it is provided by NCSC-NL, the national CERT of the Netherlands. If you don't know where you might have issues, you can run an X-Force scanner we have posted to GitHub. This is a Burp Pro extension that adds log4shell checks to Burp Scanner. It was written by Daniel Crowley of IBM X-Force Red.
领英推荐
What can you do now?
In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
Remain Vigilant
The Log4j vulnerability is complex; simply patching is not always simple. With an untold number of places where the Java framework could be using Log4j indirectly, it's not a straightforward inventory. This means a large variety of places where vulnerable versions are being used, and places where intricate dependencies can prevent immediate patching. It will take time before all versions are updated. Keep this in mind in working your risk management program.
For more on this and other emerging cybersecurity research, keep up to date with X-Force. IBM Security’s team of hackers, responders, researchers, intelligence analysts and investigators, is following the finding closely and will provide more information as our research unfolds. The Log4j vulnerability is being tracked in this?IBM X-Force Exchange Collection?and will be updated should additional information become available.
NOT LOOKING FOR WORK DISABLED/RETIRED Experienced Hardware, Software, Quality Engineer
3 年The overreaction to this "disaster" which was introduced in the current version is really eye opening. I have nothing but scorn for all the orgs that tossed engineering best practices in the toilet and let their developers write, test and deploy their own code without the slightest independent quality assurance whatsoever. I'm looking at you AWS, OCI and every other org that sacrificed quality assurance for expediency. I've been doing this since the 80's. If this is a "disaster" for your org because you don't have one clue about what is running in your production catalog, you don't have QA or release management or a change board, you deserve to reap the rich reward of failure. They deserve to fail. That's the price you pay for the hubris of acting like your devs were too good for SDLC standards and best practices. I hope those companies are subject to endless public ridicule for being a gaping security hole in the national security infrastructure. They deserve to fail.