SEIMs and Other Forensic Tools Vulnerable to Log4j Exploits
Vulnerable Log4j versions can be found is SEIMs and forensic tools like Splunk, Graylog, Autopsy and Ghidra, turning the defenders tools against them.
This article was last updated on 2022-01-03.
After several Log4j vulnerabilities (known as Log4shell or LogJam in the tech press) were publicly exposed, IT teams around the globe have been rushing to patch all of their applications against the flaws. Log4j is an very popular open source software library for implementing logging in Java applications. The first discovered flaw, tracked as CVE-2021-44228, allows logged data to include remote lookup that would then download and execute arbitrary code from a remote server, which is known as a Remote Code Execution (RCE) vulnerability. Many security tools such as Splunk, Graylog, Autopsy, and Ghidra use Log4j to generate usage and diagnostic logs.
Tools commonly used by information security professionals to investigate breaches could be leveraged to cause a security breach.
Overview of Log4j vulnerabilities in late 2021
Anyone who can contribute data that is logged, for example an HTTP URI, User- Agent header, or form field can execute code on the web server, application server, and/or database server that that logged it. The same technique can also be leveraged against desktop applications. The exploit is so trivial to use and so damaging that it earned a solid 10.0/10.0. Common Vulnerability Scoring System (CVSS) score, which is a measurementof how severe a vulnerability is. Soon, CVE-2021-44228 was being exploited by everyone from state-sponsored threat actors to Minecraft trolls.
After a patch was released for CVE-2021-44228, two more vulnerabilities were discovered by the community that were each patched separately. CVE-2021-45046 also allows remote code execution, but only when Log4j is configured in a specific, non-default way by the application that is using it for logging. CVE-2021-45105 allows for a Denial of Service (DoS) via infinite recursion.
On 2021-12-28 another Log4j vulnerability was discovered, CVE-2021-44832. While it is technically a Remote Code Execution (RCE) vulnerability, an attacker must already have access to be able to modify a config file to create the conditions necessary for the exploit to work, with the main risk of giving an insider threat plausible deniability.
This is like worrying about someone hot wiring your car when they already have working keys.
| CVE | CVSS 3.x Score | Venerable Versions | Fixed in Versions | Description |
|---|---|---|---|---|
| CVE-2021-44228 | 10.0 | 2.0-beta9 through 2.12.1 and 2.13.0 | 2.15.0 | Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 JNDI features used in 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. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0, this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects. |
| CVE-2021-45046 | 9.0 | 2.0-alpha1 through 2.15.0 | Log4j 2.16.0 (Java 8) and 2.12.2 (Java 7) | It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to 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. Log4j 2.16.0 (Java 8) and 2.12.2 (Java 7) fix this issue by removing support for message lookup patterns and disabling JNDI functionality by default. |
| CVE-2021-45105 | 7.5 | 2.0-alpha1 through 2.16.0 (excluding 2.12.3) | 2.17.0 (Java 8) and 2.12.3 (Java 7) | Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3) did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted. This issue was fixed in Log4j 2.17.0 and 2.12.3. |
| CVE-2021-44832 | 6.6 | 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) | Log4j2 versions 2.17.1, 2.12.4, and 2.3.2. | Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2. |
Timeline of events surrounding Log4j exploits
- 2021-11-24: Chen Zhaojun at Alibaba reported the first Log4j vulnerability directly to the Log4j team via email
- 2021-12-08: Chen informs the Log4j team that the venerability is being openly discussed on Chinese social media
- 2021-12-09: Log4j 2.15.0 released to fix CVE-2021-44228
- 2021-12-13: Log4j 2.16.0 released to fix CVE-2021-45046
- 2021-12-15: CISA crated guidance and a growing, community-sourced list of affected applications
- 2021-12-18: Log4j 2.17.0 released to fix CVE-2021-45105
- 2021-12-28: Log4j versions to address CVE-2021-44832 are released
Leading SIEM products affected
Security Information and Event Management (SIEM) products collect logs from every possible source across an entire enterprise, store them centrally, and index them for searching. Once the logs are stored and indexed, a SIEM provides correlation, dashboards, reporting, and alerting. It is the cornerstone of Information Security Operations.
Unfortunately, leading SIEM products such as Splunk, Graylog, and Elastic all use Log4j, and are affected by the Log4j vulnerabilities. This is particularly dangerous, because in order to function properly, a SIEM needs to collect logs from a variety of sources, at least some of which will include arbitrary user input. Additionally, anything that sends logs to a SIEM needs network connectivity to that SIEM, so if the network is not designed with attention to detail, a compromised SIEM would likely have access to broad swaths of networks.
Have some malware with your forensics
The Log4j vulnerabilities also highlight why forensics and malware analysis systems should always be airgapped.
Not even the NSA is immune from shipping vulnerable code. Their open source reverse engineering platform, Ghidra uses Log4j for logging, and it was vulnerable. Analyzing malicious file can trigger an exploit. Ghidra is mostly used for analyzing malicious binaries, so the odds of this happening are very high. Ghidra 10.1.1 fixes this by using Log4j version 2.17.0.
However, some third-party distributions, such as CERT have not updated to this version yet.
Autopsy is a popular open source digital forensics toolkit that also uses Log4j. on 2021-12-22, Autopsy 4.19.3 was released, which uses Log4j 2.16.0. That fixes the two RCE vulnerabilities, but leaves the possibility of a DoS exploit until an Autopsy release that uses Log4j 2.17.0 or higher.
China wants a private database of crowdsourced 0-day vulnerabilities
In China, it is required by law to report any vulnerabilities to the government first, before anyone else – even before the affect product vendor. This undermines responsible disclosure of vulnerabilities, and gives the Chinese government the opportunity to exploit them long before they become outside knowledge. The government punished Alibaba for not following this policy by suspending a lucrative contract to provide cloud computing services. In response, China’s Amazon-like eCommerce and cloud computing giant has promised to follow the policy in the future. It is easy to imagine a situation where someone in China finds another critical flaw in some other commonly used product – without warning the rest of the world.