On December 10, 2021, Apache published details of the CVE-2021-44228 vulnerability in the Log4j utility — an open source Java package managed by Apache. For background, the Log4j utility is a popular logging package that many applications use. With many applications, as users interact with it, the application will log the various actions that are taking place. This is useful for when administrators need to troubleshoot the application or system.
📌 Interested in learning more about our Log4j vulnerability discovery tool or looking for the latest updates? See the bottom of this page for more info on our Log4j resources.
What’s the Expected Impact of the Log4j Vulnerability?
The vulnerability that was published occurs when a specific series of characters are logged with the Log4j logging package. Knowing how web applications work and log-specific activity, threat actors have identified ways to configure web requests to web applications that include the specific set of characters. When that happens, the threat actors are able to execute commands and gain control of the server.
This might seem par for the course. You'd be forgiven for thinking, “oh great, just another vulnerability to deal with. I’ll follow my patching best practices and call it a day."
Not so fast. Here’s the issue. There are a lot of applications that use the vulnerable logging package. Not only do you need to be concerned with your own applications, but also any third party applications you are using that might be storing your data or have access into your environment. Suffice to say, we are in the first inning of a very long ball game where new vendors will be coming forward with new patches for you to apply.
Early indications are calling this one of the greatest Internet vulnerabilities in the last seven years (anyone remember Heartbleed or ShellShock?).
In other words, this is a big deal and should be taken as such. Working exploit code is already public. Threat actors are already scanning the Internet for vulnerable systems. It is only a matter of time before that access is turned into other forms of malicious activity, such as deploying ransomware.
What Are the Next Steps in Dealing with Log4j Vulnerability?
Step 1: Assess Your Internally Developed Applications
If you manage an application or technology stack using the Log4j package:
If you are unsure if your code is vulnerable, the following techniques can be used to determine if you are vulnerable:
Catalog all third-party applications and technology.
Verify whether each one is vulnerable.
This resource contains aggregated vendor statements. If your product is listed, verify whether it is vulnerable. If it is not listed, review the vendor’s website or contact them to determine if they are vulnerable.
Follow the vendor-provided guidance on patching or mitigation.
Many impacted vendors have or will release updates in the coming days to address this vulnerability. Just as important as checking your own applications is keeping up with vendor updates.
Step 3: Secure, Monitor, and Investigate
Ensure your network security technology is blocking all known indicators for this vulnerability.
If you leverage a web application firewall, validate with the vendor that they have signatures to protect against the vulnerability.
Ensure EDR technology is running on all servers.
Investigate systems to determine if they are impacted:
The following tool can be used to determine if the system has potentially been compromised: https://github.com/Neo23x0/log4shell-detector
Review systems for suspicious outbound communication.
Review systems for the installation of malicious files. This could include scripts, webshells, or executable files.
More Log4j Resources from Corvus
In collaboration with CrowdStrike, we've released a Log4j vulnerability discovery solution to help organizations achieve greater certainty they have located and patched every instance of the Log4j utility. Policyholders can request a scan here (or read more about the tool first).