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:
- We need a clear understanding of our software dependencies and code deployments.
- 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.
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.
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.
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:
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
LunaSecLog4Shell Update: Second log4j Vulnerability Published (CVE-2021-44228 + CVE-2021-45046)
December 19, 2021
Y Combinator - Hacker News
We also wrote a Log4Shell payload that will in-memory "hot patch" your server against Log4Shell.
December 15, 2021
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
Log4j remediation tools
December 15, 2021
Log4j memes
December 15, 2021
