Log4j: What is it and how can you identify it?
written by: Matthew Watkinson, CIO, Secure Sense
Log4j CVE-2021-44228 Public Disclosure
On Thursday December 9th, 2021, a Remote Code Execution (RCE) vulnerability was disclosed [CVE-2021-44228] affecting the Log4j library in versions between 2.0 and 2.14.1. Log4j is a heavily utilized logging class used in the Java programming language. Because of the widespread use of the log4j library in various java applications, this vulnerability has had a significant impact in modern infrastructure and applications across the internet. The nature of this vulnerability leads to relatively easy exploitation through unauthenticated means, with the ability to gain full control of a system in an environment. Since the library is used for logging, the vulnerability can potentially be exploited if an attacker can get a malicious payload into a log that is monitored on a system that has log4j installed.
Log4Shell in a Nutshell
The vulnerability exists in the way that java allows 3rd party libraries to be included in code, and the way that log4j interprets data. Although there should be a clear delineation between what is considered code and what is considered data, due to this vulnerability, code may be injected into something that would otherwise be considered data, allowing for java to include a remote class and execute it.
This is particularly bad because the log4j library is handling logs and anything that passes logs to the log4j library can effectively pass code along in the log4j call. Web servers often log things such as HTTP Requests, URLs, and User agent strings which can all be manipulated to include malicious payloads and trigger call-backs, which will then import malicious code and run it.
Log4Shell at Secure Sense
Secure Sense Solutions identified a small collection of systems that are used to deliver some of our managed services that were affected by the Log4j vulnerability, however compensating controls in place prevented any exploitation of these vulnerabilities. The vulnerabilities were promptly remediated to ensure that remote library inclusions are disabled in all systems and analysis of these systems has confirmed that there was no exploitation or unauthorized access in the environment.
All of our managed service customers have had notifications sent to them through the appropriate channels, and all systems have been remediated and validated that there are no indicators of compromise of the once affected systems.
Identifying Log4Shell in your environment
There are a number of ways that this vulnerability may be identified in your environment. The first of which is to check your software inventory. Log4j versions from 2.0 to 2.14.1 inclusive are all affected by the vulnerability.
Many vulnerability scanners are able to detect the log4j vulnerability, either through checking system inventories for library versions, or through unauthenticated scans where the actual vulnerability is executed to validate the callback functionality. Our Vulnerability Management customers have this tool at their disposal as part of their managed service.
For a more manual process, there are tools out there such as log4shell-scanner plugin for burpsuite, CanaryTokens or even a very simple web server listening in the appropriate port with access logging enabled can be used to detect vulnerable hosts in your environment.
Should you need help with identifying log4shell vulnerabilities in your environment, or any other assistance in securing your organization, reach out to email@example.com
Secure Sense is the security provider that cares. We are a team of experts with a passion for IT and protecting your organization is what motivates us daily. If you have questions or want to learn more about how we can improve your organization’s security, our services or just want to chat security please give us a shout.