Lessons from Log4Shell: Mapping Code Dependencies and Investigating Code Deployments


Let me open by saying that If you are currently remediating the Log4Shell vulnerability in your environment, this article is not designed for you, although some things may be helpful. Please feel free to reach out to us for any advice we can provide in your efforts! Our community Slack workspace is free to join and has a channel called #rapid-response-log4shell, where our security team and community members are collaborating to provide resources and mitigation advice. Some of the most useful resources are linked at the bottom of this blog. Now back to business!

As the industry continues to move forward from this discovery and remediation efforts, we can begin to think about lessons learned since the discovery of CVE -2021-44228.

There are undoubtedly dozens if not hundreds of lessons we could attempt to outline here, but I am going to focus on two that have been raised by many customers recently:

  1. We need a clear understanding of our software dependencies and code deployments.
  2. We also need to know where vulnerable code is deployed to determine the impacted surface (or blast radius).

JupiterOne customers can use our platform to assess their vulnerability to Log4Shell, depending on the types of data they ingest. Specifically, they can model the relationships between assets if they are ingesting software dependency data from Github.

JupiterOne is a CAASM solution built on a graph database to model relationships between assets - including software-defined assets like code repositories, code modules, vulnerabilities, findings, and more. The ability to model asset relationships is native to a knowledge-graph data model.

Software Dependencies

Our internal security leadership has been among the early proponents of the SBOM, and we were the first security startup to publish ours publicly. JupiterOne treats CodeRepos and CodeModules as assets in your inventory or nodes in the graph. The dependencies between repos and modules are relationships, or edges, in the graph.

Let’s look at our internal data from our open-sourced, npm-inventory library, a library used to model npm dependencies into the JupiterOne knowledge-graph. Via the knowledge-graph we can inspect a repository (security-policy-templates) and see other repositories that use it, npm_packages it uses, pull requests made via GitHub, users that are allowed access, encrypted secrets, and more.

Log4Shell Dependency Map - JupiterOne 01

Image 1: Software-defined assets related to a code repository

While this is a node.js example leveraging our open source repository, JupiterOne also ingests data from GitHub, including their dependency graph, and can allow you to quickly query for code dependencies.

If you use JupiterOne as your source of truth for software dependency data, ingesting log4j dependencies turns into a single query.

Find CodeRepo that uses CodeModule with displayName = ‘log4j’
Log4Shell Dependency Map - JupiterOne 02

Image 2: CodeRepo uses CodeModule

Context around Findings

Software defined assets and code dependencies are just two categories of assets that JupiterOne models relationships for. Most of our customers use us to monitor cloud infrastructure. If you are hosting your infrastructure in AWS, GCP, Heroku, or Azure, JupiterOne automatically ingests the latest configurations and relationships between your cloud assets. This includes not just virtualized hardware, but also users, access, and data storage.

Many of us can benefit from more aggressive egress filtering, which is not a native capability for all major cloud hosting providers. We need to know where we have egress filtering and vulnerabilities since it can buy time to fix issues, even if they're unpatched and exploitable.

Let’s look at an example of an instance on AWS called test-application. Imagine if we just had an IP Address or instance ID as the result of a detection. JupiterOne does a bulk of the initial investigation for us. It automatically discovers relationships to storage volumes, access roles, security groups, subnets, VPCs, ACLs, NAT gateways, load balancers, functions, the internet, and more. It also evaluates assets for configuration best practices, and allows us to create alerts on custom configuration checks.

Log4Shell Dependency Map - JupiterOne 03

Image 3: One-click blast radius

Putting it Together

The dream scenario for a vulnerability like Log4Shell is to know where in our code vulnerabilities exist, and where we have actually deployed that vulnerable code in our infrastructure. Basically, both of the above scenarios we’ve looked at combined in one.

Ultimately, JupiterOne can already be a great source of truth for asset inventory and code dependencies mapping. JupiterOne is also perfect for monitoring cloud configurations and resource relationships including network and access. We will continue to push the bar by discovering and building those cross-functional code to infrastructure relationships for application security. Let’s look at the following example query:

Find *  that relates to aws_instance  that deployed CodeRepo  that uses CodeModule with displayName = 'log4j'

Here we have found anything related to an AWS instance that has deployed code, which uses log4j. The relationship between the repository and the instance is the new piece of information that enables a single query. The relationship between code and infrastructure can be enriched programmatically from your CI/CD pipeline and the time of build/deploy via JupiterOne’s “Create-and-Update” API.

Log4Shell Resources

Log4Shell - JupiterOne - 01

LunaSecLog4Shell Update: Second log4j Vulnerability Published (CVE-2021-44228 + CVE-2021-45046)
December 19, 2021  

Log4Shell - JupiterOne - 02

Y Combinator - Hacker News
We also wrote a Log4Shell payload that will in-memory "hot patch" your server against Log4Shell.
December 15, 2021

Log4Shell - JupiterOne - 03

Trend Micro
This web-based tool can help identify server applications that may be affected by the Log4Shell (CVE-2021-44228, CVE-2021-45046) vulnerability.
December 17, 2021  

Log4Shell - JupiterOne - 05

Log4j remediation tools
December 15, 2021  

Log4Shell - JupiterOne - 04

Log4j memes
December 15, 2021

Akash Ganapathi
Akash Ganapathi

Akash Ganapathi comes from an enterprise security, data privacy, and data analysis background, working exclusively in the B2B software solutions space throughout his career. He is currently a Principal Security Solutions Architect at JupiterOne.

Keep Reading

Mitigate CVE Risks Faster with Asset Visibility | JupiterOne
May 16, 2024
Mitigate CVE Risks Faster with Asset Visibility

Discover how JupiterOne addresses critical vulnerabilities with asset inventory, relationship mapping, and actionable insights for enhanced security.

Introducing Continuous Threat Exposurement Management | JupiterOne
April 30, 2024
Introducing Continuous Threat Exposure Management with JupiterOne and watchTowr

Introducing Continuous Threat Exposure Management (CTEM) with JupiterOne and WatchTowr: A Proactive Approach to Cybersecurity

Why Your Business Needs Cloud Asset Management
April 10, 2024
Why Your Business Needs Cloud Asset Management

Organizations are transitioning to the cloud faster than ever to keep up with the changing consumer and business climate. According to Gartner, by 2023, 40% of all

15 Mar 2022
One line headline, one line headline

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud eiut.

15 Mar 2022
One line headline, one line headline

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud eiut.

15 Mar 2022
One line headline, one line headline

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud eiut.