Log4Shell: The New ‘Heartbleed’
Category
News, Vulnerabilities
Risk Level
A critical vulnerability (known as Log4Shell) in the widely used and popular Java logging Library, Log4j, was publicly disclosed by researchers on December 9th, 2021 sending public and private sector organizational security teams scrambling to understand whether their services and networks were affected, and the potential impact if they should be found to be using the vulnerable library. The 0-day vulnerability has been exploited in the wild already with growing attempts by threat actors to exploit other applications and services dependent on the library, and given the pervasiveness of its use, organizations should consider this a critical priority and act fast in determining whether they are impacted, and deploy the recommended mitigations to reduce the risk of their systems and networks being next.
“What is Log4j?”
Log4j is an open source, Apache maintained Java-logging library that is used across the globe in popular applications and services. Log4j was developed to provide a Java logging framework to standardize the process of logging on the Java platform. Until the Java Logging API was added, the Java Development Kit (JDK) did not include a logging framework, and thus many turned to the open source Log4j to serve their needs.
“Got it. But how does the exploit work?”
The Log4Shell vulnerability can be exploited remotely by any hackers if certain pre-conditions are met, allowing them to execute arbitrary code, known as “remote code execution” or RCE for short. Because Log4j allows network lookups through the Java Naming and Directory Interface (JNDI) to obtain services from an LDAP server, it will interpret log messages as crafted URLs and load them. When the Log4j implementation loads or fetches the URL, it may also potentially execute any malicious code obtained from the attacker’s malicious LDAP server, with the privileges of the program running the vulnerable Log4j implementation.
Below is a graphic representation of the attack flow, as well as some possible mitigations (in red) produced by the Swiss Government Computer Emergency Response Team (CERT).
Source: Swiss Government CERT
“Ok, but how do I protect myself and my organization?”
There are three steps you need to take immediately:
1. Assess whether your products or applications are affected
First, organizations should take inventory of their products, applications and services and determine whether the Log4j logging library is in use. Teams responsible for product and application development should check their codebases and dependencies to verify whether they are utilizing the Log4j library in support of Java based applications and services.
In addition to verifying the status of your own products, applications, and services, it would be wise to utilize your communication channels with third party vendors to validate whether the products or services your organization has procured are using the vulnerable Log4j package and affected. If it is determined that a vendor product or service is using a vulnerable package, requesting confirmation or notification when remediation actions are completed by the vendor are firmly within your rights as a customer, and we would encourage you to monitor the status of affected vendors in their remediation efforts accordingly.
Online tools have been made available to check the status of your own products and applications such as:
Additionally, several repositories have been created to track vulnerable software where you may check to see if any vendor provided or managed software are affected:
The Netherlands’ National Cyber Security Centrum Repository of Affected Software
Techsolvency’s Running List for Customer-Controlled Components
2. Patch as soon as possible!
Organizations should prioritize internet facing software / devices over internal only facing. Apache recommends applying the available patch version for the Log4j library to at least version 2.16.0 for those implementations utilizing Java 8, and to at least version 2.12.2 for those implementations utilizing Java 7.
The latest versions of Log4j 2 (for Java 8 only) are available from the Apache Logging Service site
Version 2.12.2 of Log4j 2 (for Java 7) is available from the ASF Archive Repository
3. Alternative Mitigations
Where the above patches cannot be applied, organizations should isolate the application / system from the internet and review and apply the best mitigations possible from the list below, courtesy of the Swiss Government CERT:
For versions >= 2.10: Set log4j2.formatMsgNoLookups to true
For releases from 2.0 to 2.10.0: Remove the LDAP class from log4j completely by issuing the following command:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
For certain Java Virtual Machine (JVM) Versions, it is possible to set com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false to mitigate the vulnerability. Some JVM versions already have this as the default setting.
Additionally, many WAF providers and IDS/IPS vendors have already created rules and filter sets to identify attempts to exploit the vulnerability. These filters or rules should be downloaded and / or applied through organizational change management to further mitigate the risk.
For additional information on mitigations and the latest security information related to the Log4j vulnerability, you can monitor the official Apache Logging Services page for Log4j.
“Where can I get more information?”
Not sure if you fully understand the implications of Log4Shell to your environment, whether you’re affected by it, or how to get started with mitigation? Don’t worry, Hive Systems can help! We have extensive experience in risk identification, remediation / mitigation planning, and implementation that will not only help you lower the overall risk to your organization but also give you peace of mind in the process.
Follow us - stay ahead.
Read more of the ACT
