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
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • Apache Log4j 2

    Apache Log4j 2 is a versatile, feature-rich, efficient logging API and backend for Java.

  • 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:

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

    WorkOS logo
  • 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.org/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

    Discontinued 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

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
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