Log4j, Log4Shell, public exploits, oh my!

Log4j, Log4Shell, public exploits, oh my!

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?

  • Follow your risk program to prioritize upgrading everywhere you can right now.
  • Apache has released fixes, but log4j-2.15.0-rc1 is still vulnerable. Upgrade to log4j-2.15.0-rc2. Test any upgrades, there is no stable release yet. Note that Log4j version 1 is not supported and was not validated against this vulnerability. V1 reached end of life back in 2015.
  • Keep dependencies in mind: The patched version of log4j 2.15.0 requires a minimum of Java 8. If there are place where you did not auto-update, and are still using Java 7, you will need to upgrade to Java 8.
  • If you can't upgrade/patch, mitigate and/or use compensating controls. Apache released the following mitigation note:

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.

  • Make sure you enabled egress filtering at the edge of the network, and set a default-deny policy. If you have servers exposed to the internet, ensure that they can only create network connections to explicitly approved destinations. Setting a 'default-deny' firewall rule to prevent servers from creating unapproved connections can help reduce the risk of successful compromise.
  • Update WAF rules per your specific vendor/implementation.
  • Keep following new information, patches, and vendor updates applicable to your org.

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.

Barbara Godin

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.

回复

要查看或添加评论,请登录

Limor Sylvie Kessem, CISM, CCISO的更多文章

社区洞察

其他会员也浏览了