What is Log4Shell?

Log4Shell is a critical vulnerability that affects the Log4J Java logging library (versions 2.14.0 and earlier) bundled into the Apache logging services. The vulnerability allows remote code execution (RCE) by a malicious actor on any system that leverages the vulnerable library and permits outbound network access.

How can I tell if my organization’s applications are affected?

  1. The quickest way to identify your organization’s susceptibility is to reference the software bill of materials (SBOM) for each of its applications. An SBOM captures all the internal and external software components used to construct an application and are usually incorporated as an automated step in an organization’s continuous integration continuous delivery (CI/CD) pipeline. Unfortunately, SBOMs are not as ubiquitous as security practitioners wished they were. Luckily, there are other methods of identifying the vulnerable library.
  2. Leverage authenticated vulnerability scans to identify installed software versions. Tools like Qualys and Nessus have plugins designed to pinpoint the vulnerable software.
  3. Test your own applications! BurpSuite has published the Log4Shell Scanner BApp extension that enables security practitioners to self-identify vulnerable applications in their organization: https://github.com/silentsignal/burp-log4shell

 

The BApp extension generates two types of exploit payloads that validate vulnerable servers: synchronous and asynchronous. These payloads are inherently not malicious but gather enough information to prove susceptibility. Leveraging the extension is relatively straight-forward and individual user-controllable inputs can be assessed quickly.

What do you mean “these will continue to surface”?

The terrible thing about the Log4Shell vulnerability is that it successfully evades both static application security testing (SAST) and dynamic application security testing (DAST) tools. Log4Shell is a logic-based vulnerability. Meaning, when libraries like Log4J are developed, it requires a trained security-oriented developer doing manual code reviews to recognize the vulnerable code.

These are the most difficult vulnerabilities to detect in applications but often carry the most critical impact when they arise.

How can my organization protect itself and our products against vulnerabilities like Log4Shell moving forward?

Product security is not so different from organizational security. Meaning, the same mindset that applies to protecting your organization can be leveraged to build safer, more secure applications. Here’s some guidance on building resiliency through defense in depth:

Strategic:

  • Cultivate a culture of least-privilege. The blast-radius of RCE can be greatly reduced if services are running with highly restricted privileges in locked down environments.
  • Conduct table-top exercises to simulate “what-if” scenarios. Log4Shell is the perfect example that it’s not if attackers gain access to your systems, it’s when.
  • When developing new applications, integrating new libraries, or adding new features to existing applications, conduct threat modeling and maintain software’s bill of materials (SBOM).
    • Commercial SBOM tools are fantastic, but if you’re looking to crawl or walk before you run, consider OWASP’s CycloneDX.
  • Conduct penetration testing on external facing applications, especially those that are business-critical.

Tactical:

  • If you detect Log4Shell on your internet-facing services, isolate the affected servers and conduct incident response. Adversaries have almost certainly found it before you did and are actively exploiting your environment.
  • Patch! Leveraging your SBOM, software inventory systems or vulnerability scans, identify all systems running vulnerable versions of Log4J and update.
  • Implement stringent network access controls for any internet facing server, especially those leveraging Log4J. Unless a business justification exists, unrestricted outbound network access is reckless and must be disabled.