Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Scout APM - Less time debugging, more time building
  • SonarQube - Static code analysis for 29 languages.
  • SaaSHub - Software Alternatives and Reviews
  • Apache Log4j 2

    Apache Log4j 2 is an upgrade to Log4j that provides significant improvements over its predecessor, Log4j 1.x, and provides many of the improvements available in Logback while fixing some inherent problems in Logback's architecture.

    Vulnerability researcher here.

    It's really hard for vulnerabilities as simple as this one to stay under wraps. When the patch went out 12 days ago [1], many vulnerability researchers were able to look at it and identify the root cause within minutes. Exploits started going out over a week ago before the CVE was released. Good security orgs started patching on December 7th/8th. All the chaos started on December 9th when people started leaking the poc on twitter.

    The same thing happens to google chrome when they release a patch for a security vulnerability. Very skilled researchers can produce a POC and exploit given the patch alone [2]

    [1] https://github.com/apache/logging-log4j2/commit/d82b47c

  • grype

    A vulnerability scanner for container images and filesystems

    This article[1] probably seems like a bit of convenient self-promotion from Anchore - but the two tools grype and syft

    https://github.com/anchore/grype

    https://github.com/anchore/syft

    Turned out to be very helpful in easily looking through folders, installed services (in particular an installed mobile device manager running on windows) and container images.

    [1] https://www.infoworld.com/article/3644492/how-to-detect-the-...

    Submitted to hn as:

  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • syft

    CLI tool and library for generating a Software Bill of Materials from container images and filesystems

    This article[1] probably seems like a bit of convenient self-promotion from Anchore - but the two tools grype and syft

    https://github.com/anchore/grype

    https://github.com/anchore/syft

    Turned out to be very helpful in easily looking through folders, installed services (in particular an installed mobile device manager running on windows) and container images.

    [1] https://www.infoworld.com/article/3644492/how-to-detect-the-...

    Submitted to hn as:

  • interactsh

    An OOB interaction gathering server and client library

    https://github.com/projectdiscovery/interactsh

    They seem to exfiltrate data. If you see these files hosted in your projects, then you are probably part of it now.

  • Logout4Shell

    Use Log4Shell vulnerability to vaccinate a victim server against Log4Shell

    The two examples showcase the potential of the RCE. The JNDI endpoint answers with a serialized java class:

    a) https://github.com/Cybereason/Logout4Shell where a class is self-healing the log4j vulnerability by reconfiguring it

    b) https://twitter.com/marcioalm/status/1470361495405875200 where the payload is opening an application (calculator) on the host system

  • jdk8u

    https://wiki.openjdk.java.net/display/jdk8u (by openjdk)

    > whatever it returned would just get inserted as a string into the log output, no big deal.

    Once you can inject anything that gets resolved, you have an information disclosure vulnerability unrelated to the RCE.

    If I can just DNS resolve any ${env} variable from the JVM, a lot of systems are compromised by just exposing the env or system variables configured for runtime.

    Just getting your $AWS_ACCESS_KEY_ID and $AWS_SECRET_ACCESS_KEY env vars can compromise your bucket (sure, that is a really unsafe setup now, but it was almost the standard a few years ago over configuring it explicitly).

    So a logging system which will merely resolve a hostname derived from a variable was bad enough to compromise many systems.

    The serialization loophole was fixed in a jdk8 update.

    https://github.com/openjdk/jdk8u/commit/006e84fc77a582552e71...

    But even with that in place, the information disclosure of java System or env properties is bad enough to break actual systems in prod.

  • log4shell

    Operational information regarding the log4shell vulnerabilities in the Log4j logging library.

    Site author here. While I consider my page to provide useful color, and I validate and summarize and cache info updates locally to add value ... it won't scale for long. It's really a stopgap - to buy defenders time until better efforts emerge.

    A few efforts likely to become higher leverage than mine, because they can be driven by pull requests:

    * https://github.com/NCSC-NL/log4shell - already quite comprehensive

  • SonarQube

    Static code analysis for 29 languages.. Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts