On Dec. 9, 2021, a remote code execution (RCE) vulnerability in Apache log4j 2 was traced. This was being exploited in the wild. Public proof of concept (PoC) code was released, and subsequent investigation revealed that exploitation was incredibly easy to perform. When these reports were received, it appeared that the vulnerability had already been exploited by threat actors “in the wild” and that no patch was available to fix the zero-day exploit.
Log4j is a popular Java library developed and maintained by the Apache foundation. The library is widely adopted and used in many commercial and open-source software products as a logging framework for Java. The vulnerability (CVE-2021-44228) is critical, as it can be exploited from remote by an unauthenticated adversary to executed arbitrary code (remote code execution – RCE).
Common Vulnerability Scoring System (CVSS) evaluates vulnerabilities based on their severity score and the criticality of this vulnerability is scored as a 10 (10 out of 10).
The vulnerability results from how log messages are being handled by the log4j processor. If an attacker sends a specially crafted message like, this may result in loading an external code class or message lookup and the execution of that code, leading to a situation that is known as Remote Code Execution (RCE).
What does Log4j do?
Apache log4j is a reliable, fast and flexible logging framework written in Java. It is part of the Apache Logging Services, a project of the Apache Software Foundation. Log4j is one of the several Java logging frameworks.
log4j is a tool to help the programmer output log statements to a variety of output targets. In case of problems with an application, it is helpful to enable logging so that the problem can be located. With log4j it is possible to enable logging at runtime without modifying the application binary. The log4j package is designed so that log statements can remain in shipped code without incurring a high-performance cost.
How does Log4Shell work?
Log4Shell exploits a Log4j feature that allows users to specify custom code for formatting log messages generated by Log4j.
This feature allows Log4j library to, for example, log not only the username associated with each attempted login to the server but also the user’s real name, if a separate server holds a directory linking user names and real names. To do so, the Log4j server has to communicate with the remote server holding the real names.
Unfortunately, this kind of code can be used for more than just formatting log messages. Log4j allows third-party servers to submit software code that can perform all kinds of actions on the targeted servers. This opens the door for malicious activities such as stealing sensitive information, taking control of the targeted server, and sending malicious content to other users communicating with the affected server.
The Log4j library is everywhere
A major concern about Log4Shell is the position of the Log4j library in the software ecosystem. Log4j is very widely used because logging is a fundamental part of most software. In addition to being used in popular games such as Minecraft and cloud services such as Apple iCloud and Amazon Web Services, it is used in a wide range of software development tools and security tools.
As a result, hackers have a wide range of targets to choose from: home users, service providers, source code developers and even security researchers. Apple, Microsoft, Amazon, Google, and other large companies can patch their web services rapidly to prevent hackers from exploiting them, but there are many other companies that take much longer, and some that aren’t even aware they need to patch.
Potential damage
Hackers are scanning through the internet to find vulnerable servers and setting up servers that can deliver malicious payloads. To perform an attack, they query services (for example, web servers) and attempt to trigger a log message (for example, a 404 error). The query includes maliciously crafted text, which Log4j processes as instructions.
These instructions can create a reverse shell, which allows the attacking server to remotely control the targeted server, or they can make the target server part of a botnet. Botnets use multiple hijacked servers to carry out coordinated attacks on behalf of the hackers.
Log4Shell is already being abused by many hackers. Hackers are still finding new ways to exploit the vulnerability even after it was first noted on Dec. 9, 2021.
How to detect the Log4j vulnerability in your applications?
1. Log4j-Scanner –The Cybersecurity and Infrastructure Security Agency (CISA) has announced the release of a Log4j-Scanner for identifying web services impacted by two Apache Log4j remote code execution vulnerabilities and its open source and you can easily download this scanner from the Github.
For more details please refer following URL.
https://github.com/fullhunt/log4j-scan
2. Huntress also developed a tool that is able to detect these types of vulnerabilities within an application. The source code can be downloaded from Github or you can use the Hunter Log4Shell Vulnerability Tester directly to detect the vulnerability in your application.
For more details please refer following URLs.
https://github.com/huntresslabs/log4shell-tester
https://log4shell.huntress.com/
3. Detecting the Vulnerability with Qualys WAS – Customers can detect Apache Log4j Remote Code Execution vulnerability (CVE-2021-44228) with Qualys Web Application Scanning using QID 150440, 15044.
For more details please refer following URL.
https://blog.qualys.com/vulnerabilities-threat-research/2021/12/15/is-your-web-application-exploitable-by-log4shell-cve-2021-44228-vulnerability
4. Web Application Firewall – Even though it is possible to block the known exploits with a web application firewall, it is very difficult to catch all possible exploit strings. There have been a number of ways researchers have shown to build nested and obfuscated payloads in order to bypass proposed WAF filtering rules since the flaw was disclosed. As a result, WAF and IPS vendors constantly update their Log4Shell signatures, so this is a quick and temporary solution to block known exploits, or it can be used as an additional layer of defence on top of other mitigations.
Today, there are many tools available to detect vulnerabilities in Log4j, and by doing some basic research, you can easily find these types of tools online.
What versions of Log4j are vulnerable?
- CVE-2021-44228: All Log4j versions from 2.0-beta9 through 2.12.1, and 2.13.0 through 2.14.1 (also includes 2.15.0-rc1) are vulnerable.
- CVE-2021-45046: Log4j versions from 2.0-beta9 through 2.15.0
- CVE-2021-45105: Log4j versions from 2.0-beta9 to 2.16.0
Have these vulnerabilities been patched?
- Yes, Java 8 or later users are advised to update to Log4j 2.17.0 as soon as possible. However, due to the incompleteness of the fix offered in 2.15.0, Apache released subsequent Log4j versions 2.16.0, 2.17.0 which users are strongly advised to apply.
- For Java 7, users should upgrade to version 2.12.2.
Mitigation
- Log4j 1.x mitigation
- Log4j 1.x is not impacted by this vulnerability.
- Log4j 2.x mitigation
- Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).
- For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
- Log4j 1.x mitigation
Note:
- Only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.
- Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this.
Recently, Harbinger helped an employee benefits product to test, and identify security gaps in their web application. We analyzed the system architecture during the early stages of development and performed end-to-end security testing of the web application. The result? The early detection and resolution of security flaws helped with reduced application security vulnerabilities and protection against future attacks like private data leakage.
To know more, we suggest you download the case study, titled “Preventing Data Breaches with End-to-End Web Application Security Testing.”
