ClickySkip to main content
Need help with a cyber incident now?
Call 24/7: +31 88-2747800

Apache Log4j vulnerability

By 31 January 2022 April 11th, 2023 CERT, SOC, Vulnerability

This live blog contains information regarding vulnerabilities in Apache Log4j. As soon as we have an update, we’ll add it to this post. More information about possible risks and details can be found at the bottom of this blog. Last updated on January 31, 2022.

Status by Tesorion Vendor

When a Tesorion vendor has made a statement about the vulnerability with regard to its portfolio, we have included it below. Sources: github.com/NCSC-NL/log4shell/tree/main/software en gist.github.com/SwitHak.

Update January 31, 2022

17:30 | On the 9th of December 2021, a Proof-of-Concept (POC) exploit for the Apache Log4J library was published. The initial POC exploit is straight forward. However, for successful exploitation of a Log4J based application, the exploit must be tailor made for that application.

Soon after the publication of the POC exploit, attackers were actively exploiting internet-facing VMware Horizon and MobileIron applications. Last week a news article was published stating that attackers are actively exploiting instances of the Unifi Network application. The Unifi Network application is used to manage Ubiquiti software and hardware solutions.

We advise to apply the patches available for the named products as soon as possible. If you have one of these products publicly exposed without the patch or additional measures, it should be consider compromised and does require additional mitigations.

Exploits for the Log4j vulnerabilities are application specific and require specific developments. It is expected more exploits for other applications will be published over time.

CVE summary

CVE Description Affected versions Fixed in version
CVE-2021-44228 The initial JNDI injection and RCE vulnerability in Log4J. Log4j version 2 <=2.14.1 Java8 or later: 2.15.0
CVE-2021-4104 A very similar vulnerability as CVE-2021-44228 that affects Log4j version 1. This is only vulnerable when JMSAppender is enabled. Log4j version 1.X –
CVE-2021-45046 An incomplete fix for CVE-2021-44228 affecting Log4j. Log4j version 2 <=2.15.0 Java8 or later: 2.16.0
Java7: 2.12.2
CVE-2021-45105 DoS vulnerability. Log4j version 2 <= 2.16.0 Java8 or later: 2.17.0
Java7: 2.12.3
Java6: 2.3.1
CVE-2021-44832 RCE vulnerability after adding JDBC Appender in the configuration file. Log4j versie 2 <= 2.17.0 Java8 or later: 2.17.1
Java7: 2.12.4
Java6: 2.3.2

Update December 29, 2021

10:30 | The Apache Foundation has released a new update for Log4J, version 2.17.1. Yesterday there were already some rumours that all versions from 2.0 alpha7 might be vulnerable to a Remote Code Execution (RCE) attack. Today this has been confirmed, and the vulnerability has been registered as CVE-2021-44832 with a CVSS score of 6.6.

Based on the current information, it appears the vulnerability is only exploitable if an attacker can modify the configuration file of Log4J. To modify the configuration file, the attacker needs access to the file and the permission to make changes.

If you are still using version 2.15.0 (or lower), it is recommended to update to version 2.17.1 immediately. Based on the current information, it does not seem necessary to update immediately from version 2.16.0 or 2.17.0 to version 2.17.1. This vulnerability is fixed for Java6 in version 2.3.2 and for Java7 in version 2.12.4.

More information:

CVE summary

CVE Description Affected versions Fixed in version
CVE-2021-44228 The initial JNDI injection and RCE vulnerability in Log4j. Log4j version 2 <=2.14.1 Java8 or later: 2.15.0
CVE-2021-4104 A very similar vulnerability as CVE-2021-44228 that affects Log4j version 1. This is only vulnerable when JMSAppender is enabled. Log4j version 1.X –
CVE-2021-45046 An incomplete fix for CVE-2021-44228 affecting Log4j. Log4j version 2 <=2.15.0 Java8 or later: 2.16.0
Java7: 2.12.2
CVE-2021-45105 DoS vulnerability Log4j version 2 <= 2.16.0 Java8 or later: 2.17.0
Java7: 2.12.3
Java6: 2.3.1
CVE-2021-44832 RCE vulnerability after adding JDBC Appender in the configuration file. Log4j versie 2 <= 2.17.0 Java8 or later: 2.17.0
Java7: 2.12.3
Java6: 2.3.1

Update December 18, 2021

15:00 | NCSC has published several overviews, which are continuously updated in collaboration with various security companies.

Update Log4J 2.17.0
The Apache Foundation has released a new update for Log4J, version 2.17.0. Yesterday there were already some rumours that all versions from 2.0 beta9 might be vulnerable to a Denial-of-Service (DOS) attack. Today this has been confirmed, and the vulnerability has been registered as CVE-2021-45105 with a CVSS score of 7.5.

Based on current information, it appears the vulnerability is only exploitable when a non-default configuration is used. If you are still using version 2.15.0 (or lower), it is recommended to update to version 2.17.0 immediately. Based on the current information, it does not seem necessary to immediately update from version 2.16.0 to version 2.17.0.

More information »

CVE summary

CVE Description Affected versions
CVE-2021-44228 The initial JNDI injection and RCE vulnerability in Log4j. Log4j version 2 <=2.14.1
CVE-2021-4104 A very similar vulnerability as CVE-2021-44228 that affects Log4j version 1. This is only vulnerable when JMSAppender is enabled. Log4j version 1.X
CVE-2021-45046 An incomplete fix for CVE-2021-44228 affecting Log4j. Log4j version 2 <=2.15.0

 

Update December 17, 2021

15:00 | NCSC has published several overviews, which are continuously updated in collaboration with various security companies.

Increased CVSS-score of CVE-2021-45046
The Apache Foundation has increased the CVSS-score of CVE-2021-45046 from 3.7 to 9. Initially, CVE-2021-45046 was identified as a Denial-of-Service (DOS) vulnerability. Previous research also showed the possibility for Data Exfiltration. Additionally, new research shows that an Unauthenticated Remote Code Execution attack is possible. This vulnerability gives the attacker the ability to execute code from a remote system, which has a significantly higher impact. The CVSS scale runs from 0 to 10.

CVE-2021-45046 can only be exploited when a non-default configuration is used. All versions of Log4j from 2.0 to 2.15.0 are vulnerable.

Step-by-step description on scanning with Nextron THOR Lite
Since the Log4j vulnerability became known, our partner Nextron has been sharing methods for the detection of exploitation based on log files. This detection knowledge is included in the Nextron THOR Lite scanner. This scanner requires a registration, but is free to use:

  1. Go to the Nextron website and press the Subscribe and Download button and follow the instructions;
  2. Place the THOR files with the license file on the system to be scanned;
  3. Update the signatures of the scanner:
    • Windows: thor-lite-util.exe update
    • Linux: ./thor-lite-util update
  4. Run the THOR file from the command line as administrator/root:
    • Windows: thor64-lite.exe –allreasons –allhds
    • Linux: sudo ./thor-lite-linux-64 –allreasons
  5. After completion of the THOR scan, report files (.html, .csv, .txt) containing the output are created. Open the .html file and analyze the output for traces of malicious activity.
  6. If traces of malicious activity are identified, our advice is to perform a cross-validation with additional log sources:
    • Firewall logging – Outbound connections to the IP-address/hostnames listed in the THOR results.
    • DNS logging – Resolving for the hostnames listed in the THOR results.
    • Unexpected activities in the log files of the Java applications. Focus on log files written by the Log4J library. Search specifically for empty/odd log lines.

Are there other traces of malicious activity on the system apart from Log4Shell? Examples of malicious activity: virus scanner notifications, new user accounts, unexpected processes, or high usages of resource.

CVE summary

CVE Description Affected versions
CVE-2021-44228 The initial JNDI injection and RCE vulnerability in Log4j. Log4j version 2 <=2.14.1
CVE-2021-4104 A very similar vulnerability as CVE-2021-44228 that affects Log4j version 1. This is only vulnerable when JMSAppender is enabled. Log4j version 1.X
CVE-2021-45046 An incomplete fix for CVE-2021-44228 affecting Log4j. Log4j version 2 <=2.15.0

 

Call to Action

  1. Determine which applications are used within your organisation.
    • Include client applications.
  2. Determine what applications are vulnerable to any of the Log4j vulnerabilities.
  3. Install a patch or apply a workaround when available.
    • Limit network connections when a patch or a workaround is not available.
  4. Check your environment for anomalous outgoing connections, unexpected configuration changes, new user accounts or anomalous system processes.
  5. Consider preserving log files related to any Java based application, for future (forensic) investigations. Full systems backups are a good method to preserve all system artifacts.
    • A working backup is a good practice in general, and especially in this situation.
  6. Run a scan with the Nextron Thor Lite scanner on possible effected systems, to detect potential exploitation.

Update December 16, 2021

12:00 | NCSC has published several overviews, which are continuously updated in collaboration with various security companies.

Version 2.15.0 – Environment variable exfiltration
In a previous update we talked about the possibility to exfiltrate information stored in so-called environment variables through the Log4Shell vulnerability. These variables can contain sensitive information, such as passwords or API keys.

Analysis shows that Log4j version 2.15.0 is still vulnerable to this. We recommend updating to version 2.16.0.

Detected malicious activity
The Log4Shell vulnerability is known for a week now, most Log4j installations have now been identified and provided with a patch or workaround. But were you on time?
Earlier we already gave the tip to preserve log files of Java-based and related applications, for a later investigation. This to prevent the log files from being removed after the log retention period.

Since the Log4j vulnerability became known, our partner Nextron has been sharing methods for the detection of exploitation based on log files. Nextron has made a specific scanner available on Github. This detection knowledge is also included in the Nextron Thor Lite scanner. This scanner requires a registration, but is free to use:

https://www.nextron-systems.com/thor-lite/download/

CVE summary

CVE Description Affected versions
CVE-2021-44228 The initial JNDI injection and RCE vulnerability in Log4j. Log4j version 2 <=2.14.1
CVE-2021-4104 A very similar vulnerability as CVE-2021-44228 that affects Log4j version 1. This is only vulnerable when JMSAppender is enabled. Log4j version 1.X
CVE-2021-45046 An incomplete fix for CVE-2021-44228 affecting Log4j. Log4j version 2 <=2.15.0

 

Call to Action

  1. Determine which applications are used within your organisation.
    • Include client applications.
  2. Determine what applications are vulnerable to any of the Log4j vulnerabilities.
  3. Install a patch or apply a workaround when available.
    • Limit network connections when a patch or a workaround is not available.
  4. Check your environment for anomalous outgoing connections, unexpected configuration changes, new user accounts or anomalous system processes.
  5. Consider preserving log files related to any Java based application, for future (forensic) investigations. Full systems backups are a good method to preserve all system artifacts.
    • A working backup is a good practice in general, and especially in this situation.
  6. Run a scan with the Nextron Thor Lite scanner on possible effected systems, to detect potential exploitation.

Update December 15, 2021

14:00 | NCSC has published several overviews, which are continuously updated in collaboration with various security companies.

Release 2.16.0
In yesterday’s update we discussed the new patch for log4j. This patch disables JNDI by default and removes message lookups. We recommend updating to the 2.16.0 version since an additional attack vector was identified and registered as CVE-2021-45046. Version 2.15.0 is only vulnerable to CVE-2021-45046 with a specific non-default configuration.

Note that previous mitigations involving configuration such as to set the system property log4j2.noFormatMsgLookup to true do not mitigate this specific vulnerability.

Vulnerability CVE-2021-45046 has a CVSS-score of 3.7, and only leads to a potential denial of service (DOS) attack. The CVSS scale runs from 0 to 10.

Log4j version 1
Log4j version 1 is end of support since 2015 but is still widely deployed. By default, it does not offer a JNDI lookup mechanism and is therefore not vulnerable to Log4Shell (CVE-2021-44228). However, it can still be exploited by CVE-2021-4104 in case configuration JMSAppender is enabled, which is not default. Additionally, the attack vector is reduced as it depends on having write access, which is not a standard configuration rather than untrusted user input.

Vulnerability CVE-2021-4104 is similar to CVE-2021-44228 and has a CVSS-score of 6.6 and allows a remote attacker to execute code. The CVSS scale runs from 0 to 10.

CVE summary

CVE Description Affected versions
CVE-2021-44228 The initial JNDI injection and RCE vulnerability in Log4 Log4j version 2 <=2.14.1
CVE-2021-4104 A very similar vulnerability as CVE-2021-44228 that affects Log4j version 1. If JMSAppender and malicious connections have been configured. Log4j version 1.X
CVE-2021-45046 An incomplete fix for CVE-2021-44228 affecting Log4j. Log4j version 2 <=2.15.0

Call to Action

  1. Determine which applications are used within your organisation.
    • Include client applications.
  2. Determine what applications are vulnerable to any of the Log4j vulnerabilities.
  3. Install a patch or apply a workaround when available.
    • Limit network connections when a patch or a workaround is not available.
  4. Check your environment for anomalous outgoing connections, unexpected configuration changes, new user accounts or anomalous system processes.
  5. Consider preserving log files related to any Java based application, for future forensic investigations. Full systems backups are a good method to preserve all system artifacts.
    • A working backup is a good practice in general, and especially in this situation.

Update December 14, 2021

14:00 | NCSC has published several overviews, which are continuously updated in collaboration with various security companies.

An overview of scripts/applications to detect the presence of vulnerable Log4j implementations:
https://github.com/NCSC-NL/log4shell/tree/main/scanning

Release 2.16.0
On the 13th of December the Apache Foundation released a new patch for the Log4J library, disabling JNDI by default and completely removing support for message lookups. This will mitigate the remaining risk of Log4Shell.

Environment variables
Attackers are using Log4Shell to steal environment variables such as cloud credentials or API keys, like AWS_SECRET_ACCESS_KEY, which would enable an attacker to have the same access to your AWS environment.

This data exfiltration is performed by including the environment variables as part of the FQDN used as part of the lookup.

Client exploitation
Currently the main focus of the IT security community is on the exploitation of servers. However, clients including the Log4J library can also be vulnerable, and can be exploited when they connect to a malicious or infected server.

CVE-2021-44228-Scanner
In general there are two methods for detecting the vulnerability. The first one is with the use of a remote scanner against the IP interface of a system, for example with calls to a java-based webserver. Secondly, with a local scan on the file system, to search for the vulnerable library. In general, the second method provides the most reliable results and is therefore recommended.

A local scanner with the name log4j-scan can be used as a vulnerability scanner for CVE-2021-44228. This tool will scan the local file system for the presence of org/apache/logging/log4j/core/lookup/JndiLookup.class and return all files being vulnerable to Log4Shell.

In case of patched versions of Log4J, please make sure it was patched by you. Attackers are observed to patch systems after they successfully compromise the system. This prevents other malicious entities to gain access.

Backups & collect evidence
With the likelihood of a successful compromise due to the Log4Shell vulnerability it is highly recommended to preserve all log files related to the system and Java applications for future forensic investigations. A full system backup will preserve this logging.

A working backup is a good practice in general, and especially in this situation.

Combination of vulnerabilities
For an attacker, to reach their goal , it’s common to chain multiple existing vulnerabilities of different applications and vendors. Log4Shell is no exception and is currently observed in combination with other (recent) vulnerabilities.

Call to Action

  1. Determine which applications are used within your organisation.
  2. Determine what applications are vulnerable to the Log4j vulnerability.
  3. Install a patch or apply a workaround when available.
    • Limit network connections when required.
  4. Check your environment for anomalous outgoing connections, unexpected configuration changes, new user accounts or anomalous system processes.
  5. Consider preserving log files related to any Java based application, for future forensic investigations. Full systems backups are a good method to achieve and preserve all system artifacts.
    • A working backup is a good practice in general, and especially in this situation.

Update December 13, 2021

09:00 | The image below visually shows the potential attack method regarding the Log4j vulnerability and how you can prevent it.

Source: GovCert.ch

NCSC has published several overviews, which are continuously updated in collaboration with various security companies.

Statement Tesorion regarding products

The Apache Log4j vulnerability has no impact on the  products and solutions as mentioned in the statement. All services that used Log4j were identified by Tesorion. We have taken appropriate measures in time to eliminate any threat to them.

Input fields
In our last update we talked about exploiting the vulnerability using input fields. This is correct, but not complete. Any form of information input can be misused by an attacker. For example, a user-agent string or a URL parameter that are sent to a web application.

Call to Action

  1. Determine which applications are used within your organisation. Initially focus on applications that can be accessed directly from the internet, without going through an SSL VPN connection.
  2. Determine what applications are vulnerable to the Log4j vulnerability.
    • Several scan/check scripts are available that can help to identify vulnerable applications. The overview created by the NCSC may be a good start:https://github.com/NCSC-NL/log4shell/tree/main/
    • Avoid using online scanning websites, as they can potentially leak information to malicious parties.
  3. Install a patch or apply a workaround when available.
    • An often-recommended workaround is to start the server with directive ‘log4j2.formatMsgNoLookups’ with the value ‘True’. This can be achieved by adding the text “‐formatMsgNoLookups=True” to the JVM command that starts the application.
    • For critical applications, make sure that the server hosting the application cannot establish connections to the internet. Usually, these connections are not necessary for the application to work. This prevents the cybercriminal from downloading the necessary additional malicious code.
    • If the impact allows, consider turning off critical systems or making them completely inaccessible from the internet.
  4. Check your environment for anomalous outgoing connections, unexpected configuration changes, new user accounts or anomalous system processes.

Detection rules are available to analyse logfiles for traces of misuse. Those rules can be found in the overview of the NCSC – https://github.com/NCSC-NL/log4shell/tree/main/

Update December 12, 2021

16:00 | We updated our blog about the Apache Log4j vulnerability from last Friday with the latest information. The vulnerability has been given the name “Log4Shell”. The risk rating, also known as the CVSS-score, is unchanged: 10. This is the highest possible rating.

The challenge is that Java is like sugar, it’s in everything. Java in combination with Log4j is widely used as a base or as a building block. Different applications from vendors may be vulnerable as a result.

Apache Log4j is a Java library which provides a log framework for applications based on Java. Both Java and the Log4j library are widely used in software applications and services around the world. The vulnerability allows cybercriminals to gain control over the system hosting the Java based applications. In technical terms, this is called an “Unauthenticated Remote Code Execution”.

Exploitation of the vulnerability is relatively easy. The vulnerability can be triggered when an application writes the content of an input field in a log event using the Log4j library. An example is the login screen of an application, where the username is written as a log event when an incorrect login occurs. This makes the username input field usable for exploitation. This vulnerability is not limited to the username input field as mentioned in the example, but to all input fields in an application.

A cybercriminal can only exploit this vulnerability when they have access to the application. Therefore, applications directly accessible on the internet are at great risk.

Currently, both cybersecurity researchers and cybercriminals are actively scanning the internet for vulnerable systems. In doing so, some cybercriminals have already figured out how to exploit certain applications. However, this differs per application. There is no large-scale exploitation of the vulnerability (yet). Exploitation is expected to increase in the coming days.

Call to Action

  1. Determine which applications are used within your organisation. Initially focus on applications that can be accessed directly from the internet, without going through an SSL VPN connection.
  2. Determine what applications are vulnerable to the Log4j vulnerability.
    • Several scan/check scripts are available that can help to identify vulnerable applications.
  3. Install a patch or apply a workaround when available.
    • An often-recommended workaround is to start the server with directive ‘log4j2.formatMsgNoLookups’ with the value ‘True’. This can be achieved by adding the text “‐formatMsgNoLookups=True” to the JVM command that starts the application.
    • For critical applications, make sure that the server hosting the application cannot establish connections to the internet. Usually, these connections are not necessary for the application to work. This prevents the cybercriminal from downloading the necessary additional malicious code.
  4. Check your environment for anomalous outgoing connections, unexpected configuration changes, new user accounts or anomalous system processes.
Log4j Attack Surface

Update December 10, 2021

14:00 | On the 9th of December 2021, Proof-of-Concept exploits for Apache Log4j utility are being shared online. Attackers are currently actively scanning the internet for vulnerable systems. Log4j is developed by Apache Foundation and is widely used in apps and cloud services. The vulnerability registered as CVE-2021-44228 is an unauthenticated remote code execution vulnerability, allowing complete system take over.

Apache Foundation released a new version three days ago, likely patching this vulnerability. However, security researchers already found a way to bypass the patch. The latest version was published earlier today log4-2.15.0-rc2. Applying the patch as soon as possible is advisable.

Reason and background of this blog

This blog contains information about vulnerabilities, the possible risk and advice on how to prevent or limit damage. Below are the possible risks, details and background information.

Potential risk

Attackers are currently actively scanning the internet for vulnerable systems. Log4j is developed by Apache Foundation and is widely used in apps and cloud services. The vulnerability registered as CVE-2021-44228 has a CVSS-score of 10. The CVSS scale runs from 0 to 10. A score of 9.8 or higher is rare and implies a high risk of exploitation with a high impact.

This vulnerability is an unauthenticated remote code execution vulnerability and allows for a complete system take over.

Detail info

The vulnerability allows a remote unauthenticated attacker to directly construct malicious requests to trigger remote code execution. Successful exploitation of this vulnerability will allow for complete system take over by the attacker.

Based on the information from Apache Foundation all versions from 2.0-beta9 to 2.14.1 are affected.
Apache Foundation published a patch on the 9th of December 2021, applying the patch as soon as possible is advisable.

To mitigate the risk, the server can be booted with the directive ‘log4j2.formatMsgNoLookups’ set to ‘true’ by adding ‐Dlog4j2.formatMsgNoLookups=True” to the JVM command that starts the tool. However, this can affect the operation of the application if it relies on lookups when processing and displaying data.

As an alternative to the above mitigating measure, it is also an option to block outgoing sessions as much as possible to prevent an attacker from downloading his payload from a remote server.

Background

A vulnerability impacting Apache Log4j versions 2.0 through 2.14.1 was disclosed on the project’s GitHub on December 9, 2021. The flaw has been dubbed “Log4Shell,” and has the highest possible severity rating of 10. Apache is pervasive and comprises nearly a third of all web servers in the world—making this a potentially catastrophic flaw.

Log4j is an open source Java logging library that is widely used in a range of software applications and services around the world. The vulnerability can allow cybercriminals to take control of any Java-based, internet-facing server and engage in remote code execution (RCE) attacks.

Most login screens in the world typically audit failed login attempts, meaning that virtually every authenticated page using Log4j is vulnerable. Browser search bars are also often logged and expose systems to this flaw.

Exploiting the flaw is fairly trivial. An attacker can exploit the vulnerability by simply sending a malicious code string that gets logged by Log4j. At that point, the exploit will allow the attacker to load arbitrary Java code and take control of the server.

More information:

Subscribe

Do you want to be informed in time? Sign up for our technical updates

Would you like to receive these critical vulnerabilities by e-mail from now on? Enter your e-mail address below.

Tesorion uses your personal data to send out requested information and possibly for contact by telephone and for marketing and sales purposes. You can change your preferences whenever you want. Read our privacy policy for more information.

Sectie