Finding the applications impacted by the Apache Log4j vulnerability
A critical vulnerability in the popular application programming language, Java, specifically a utility of that language (developed by Apache Software Foundation), Apache Log4j, is actively being exploited by attackers. The vulnerability has been labelled “Log4Shell”. While the Java programming language is less popular these days, it is still in very broad use in enterprise systems and web applications. As Log4j houses regularly referenced code that is stored and called upon by the programming language, it is regarded as a library or “utility”.
A prototype, or working example of the exploit for the vulnerability, tracked as CVE-2021-442281, was released on December 9, 2021 while Apache Log4j developers were still involved in creating and testing a patched version. Attacks started soon thereafter. This made the vulnerability (or flaw) a zero-day issue at the time of exploitation (since it was exploited before the patched version was released). Apache has since released Log4j 2.15.0, which includes a fix.
The patched version of the library was delayed because researchers found a way to bypass the initially proposed fix, so it required additional work and review – while the attacker took advantage of the exploit.
While the vulnerability only affects Java-based applications that use the Log4j library directly, it also impacts Java programming “components” and “development frameworks” that rely on that library, including, but not limited to Apache Solr, Apache Struts2 and Apache Kafka. To translate, when a programming language is created, it will generally come with libraries and repeatable groups of code that all programmers would have to set up if they were creating a new application. Instead of each developer creating these, they are provided by the programming language. Log4j is an example of such a library.
The exploit was first seen on sites hosting Minecraft servers, where it was discovered that attackers could trigger the vulnerability by posting chat messages. A tweet from the security analysis company GreyNoise2 reported that the company has already detected numerous servers searching the internet for machines vulnerable to the exploit.
If the Log4j vulnerability is exploited before mitigating actions are applied, it can lead to remote code execution. This means attackers can take advantage of the Log4j flaw by inserting contents in the Log4j library and then substituting that old content for that new content where desired. It also allows them to delete or encrypt files and hold them for ransom. Any function the impacted asset can do, attackers can do as well with the exploit. Anything that uses a vulnerable version of Log4j to log user-controlled data can be attacked.3 From Log4j 2.15.0 forward, this behavior is disabled by default.
The bottom line: If a user can generate a request including content that was specifically crafted, and if that request was logged through Log4j, the vulnerability could be exploited. And, since most applications are designed to accommodate user input in a variety of ways, the ability to exploit via this vulnerability is very simple to execute. Given the time taken to ensure that all vulnerable machines are updated, Log4Shell remains a pressing threat.
The attack surface is estimated to be sizeable, as some of the components impacted are extremely popular and are utilized by millions of enterprise applications and services. Although it may be easy to identify well documented applications using the library, it may take time to find other Java applications in the environment utilizing the Log4j library that are not well-documented. As a result, experts are anticipating a long tail on this vulnerability. For example, many appliances and pre-packaged software utilize Java – indicating that companies need to ask their vendors when those applications will be patched.
Companies will likely be busy for months chasing down applications that need to be patched. Unfortunately, failing to patch actively exploited flaws in a timely manner has resulted in major breaches in the past, an example of which was the 2017 Equifax breach which involved the failure to patch an actively exploited Java Struts2 vulnerability.
Immediately review your company’s inventory of applications, especially publicly accessible applications, to determine whether they utilize the Apache Log4j library. Implement mitigations (apply the Apache fix, etc.) as soon as possible for those applications that were identified.
While patching may be difficult, it is still the number one action to take today. Apache released version 2.15.0-rc1, quickly followed by 2.15.0-rc2 after a bypass was discovered. Apache has also suggested mitigations for those who cannot patch.
Additionally, this situation begs for the active use of a software bill of materials for all applications. A software bill of materials should describe the components included in the application, the version and build of the components in use, and the license types for each component. If this were available for all applications, finding those other applications that might be utilizing Java components and development frameworks using these other Java utilities would be a very simple exercise and a significant time-saver.
If exploited, the vulnerability allows remote code execution on vulnerable servers, giving an attacker the ability to import malware that would completely compromise machines. That means business interruption. Business leaders should understand the impact of business interruption on specific business processes and the potential losses that could result. Understanding what percent of the workforce and what resources would be impacted based on the business processes impacted is vital. For example, would the organization be able to operate that process or process(es) to any reasonable extent given the loss of applications operating on impacted servers? Because it may not be easy to determine the “unknown” applications affected by the Log4j event, answering these questions will be difficult.
Because this event may have a long tail, it may take months before the full impact of an event can be identified. Initial indications are that this is a systemic, widespread vulnerability that has major implications. Working with your broker to understand the exploit, its impact and how to fully maximize the cyber coverage that may be available will be critical.
Operational resilience is essential in any crisis. As this event and other recent incidents have illustrated, preparedness and backup plans must be built into every facet of operational and third-party management.
Business leaders should always consider backup alternatives, being mindful of cost/benefit tradeoffs. Documenting, planning, and testing chosen alternative(s) is crucial, as events such as Log4Shell continue to highlight the fragility of systems, processes and company security environments and the wide-ranging impacts incidents like this could have.
Decision makers need to determine whether this type of event is likely to impact their organization. It is essential to define potential scenarios, and think through how operations would be impacted, mindful that the processes impacted will differ, organization to organization. Business leaders can help themselves to properly prepare for these and other types of events by taking advantage of Willis Towers Watson’s Cyber Analytics Consulting Team. Our consultants can guide you in understanding your risk, identifying actions to reduce risk, understanding what attributes are driving risk, discussing how risk can be transferred, and defining the value of insurance, all leveraging leading decision-support tools with industry experienced resources.
As a global leader in human capital solutions, risk advisory and broking services, we are well prepared to assess your cyber vulnerabilities, protect you through best-in-class solutions and radically improve your ability to successfully recover from future attacks.
1 https://www.csoonline.com/article/3122971/whats-in-your-code-why-you-need-a-software-bill-of-materials.html
2 https://www.theverge.com/2021/12/10/22828303/log4j-library-vulnerability-log4shell-zero-day-exploit
3 https://securityintelligence.com/posts/apache-log4j-zero-day-vulnerability-update/
4 https://www.wired.com/story/log4j-flaw-hacking-internet/
Willis Towers Watson hopes you found the general information provided in this publication informative and helpful. The information contained herein is not intended to constitute legal or other professional advice and should not be relied upon in lieu of consultation with your own legal advisors. In the event you would like more information regarding your insurance coverage, please do not hesitate to reach out to us. In North America, Willis Towers Watson offers insurance products through licensed subsidiaries of Willis North America Inc., including Willis Towers Watson Northeast Inc. (in the United States) and Willis Canada, Inc. (in Canada).
