Introduction
Security researchers recently disclosed the vulnerability CVE-2021-44228 in Apache’s log4j, which is a common Java-based library used for logging purposes. Components such as Struts2, Kafka etc. make use of log4j library.
JNDI
The Java Naming and Directory InterfaceTM (JNDI) is an application programming interface (API) that provides naming and directory functionality to applications written using the JavaTM programming language. It is defined to be independent of any specific directory service implementation. Thus a variety of dir.ectories–new, emerging, and already deployed–can be accessed in a common way
The latest CVE-2021-45046 vulnerability was discovered just a day after the release of the Log4j version 2.16.0 on December 14 receiving the CVSS Score of 3.7. Later, due to the highly assessed risks it poses, it received the Critical security impact rating with a score dramatically increased to 9.0.
Multiple CVE have been reported on the Log4j Library listed below:
CVE-2021-44228
Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 JNDI features used in the configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
Vulnerability Type – Remote Code Execution
Base CVSS Score – 10.0
Severity – Critical
Versions Affected – All versions from 2.0-beta9 to 2.14.1
CVE-2021-45046
It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI Lookup pattern, resulting in an information leak and remote code execution in some environments and local code execution in all environments; remote code execution has been demonstrated on macOS but no other tested environments.
Vulnerability Type – Remote Code Execution
Base CVSS Score – 9.0
Severity – Critical
Versions Affected – All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2
CVE-2021-45105
Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack.
Vulnerability Type – Denial of Service
Base CVSS Score – 7.5
Severity – High
Versions Affected – All versions from 2.0-beta9 to 2.16.0
Detection
Scan for Log4j with open-source/Commercial tools
>>Burp (Pro): Burp has extended an own version of Log4j Library scan to detect whether the version being used is vulnerable or not.
>>Anchore: the ability to scan a large number of packaged dependency formats, identify their existence, and report if they contain vulnerabilities. Able to scan JAR files, especially nested layers of JAR files.
>>Syft: scan the Java project and shows that it includes specific version of Log4j library.
>>Grype: Scanner that has the ability to tell us which specific vulnerabilities our software contains. When you include a dependency in your application you can also identify the vulnerabilities that the dependency contains, and so on through multiple levels of nesting. Grype can scan the software directly.
Mitigation Measures
When updates are available, agencies must update software using Log4j to the newest version (2.17.0 or 2.17.1), which is the most effective and manageable long-term option. Where updating is not possible, the following mitigating measures can be considered as a temporary solution and apply to the entire solution stack.
>>Disable Log4j library. Disabling software using the Log4j library is an effective measure, favoring controlled downtime over adversary-caused issues. This option could cause operational impacts and limit visibility into other issues.
>>Disable JNDI lookups or disable remote codebases. This option, while effective, may involve developer work and could impact functionality.
>>Disconnect affected stacks. Solution stacks not connected to agency networks pose a dramatically lower risk from attack. Consider temporarily disconnecting the stack from agency networks.
>>Isolate the system. Create a “vulnerable network” VLAN and segment the solution stack from the rest of the enterprise network.
>>Deploy a properly configured Web Application Firewall (WAF) in front of the solution stack. Deploying a WAF is an important, but incomplete, solution. While threat actors will be able to bypass this mitigation, the reduction in alerting will allow an agency SOC to focus on a smaller set of alerts.
>>Apply micropatch. There are several micropatches available. They are not a part of the official update but may limit agency risk.
