Log4j / Log4Shell – Week 2 Update

We are well into the second week of reaction and remediation associated with the Apache Log4j vulnerability, so I wanted to pause and take a moment to recap what we know, what we should be doing now, and what we should be considering moving forward. Let us start with what we know.

Log4j is a remote code execution (RCE) vulnerability that can force the download of a malicious payload on vulnerable web servers and computers depending on the presence and/or configuration of certain server components.  Specifically, exploitation of the vulnerability requires a single HTTP request containing malicious input from anywhere in the world, to an internet-facing server that is running a vulnerable instance of log4j, or the same HTTP request sent to a vulnerable computer within a compromised local network. The result is a full system compromise, and the exploit requires no authentication.  It is important to stress that the Log4j vulnerability is not limited to Internet-facing web servers only. If a bad actor gains access to a local network, the same HTTP requests can be sent internal to IP-enabled devices on that network to compromise vulnerable systems. This is a very serious potential attack vector, and all of us should be working diligently to ensure all our devices and those of our friends, family, and clients are safe and properly protected.

So what should we be doing now. First and foremost, we should all be scanning our computers, servers, and other IP-enabled devices to look for vulnerable versions of Log4j. At this point, there are numerous scanning tools available from security experts, RMM vendors, and other platforms from which to choose. Please remember that these scanning tools take different approaches to identifying potentially vulnerable systems and devices. Some look for the presence of Log4j associated jar files. Others look for log entries on the device indicating the presence of malicious inbound activity. And then others actually send crafted HTTP requests looking for vulnerable system responses. Given these different detection methods, make sure to understand your scan results and take the time to verify the findings before you start pulling systems, servers, and devices offline.

Once you verify the presence of a vulnerable Log4j component, the next step involves determining why the component is present on that system or device and then reaching out to the application or device vendor to find updates, patches, and/or mitigation instructions. Log4j is so ubiquitous in applications, servers, and IP-enabled appliances, and application vendors and IoT vendors have embedded it and leveraged it hundreds of different ways, so vendor support may be a necessity to ensure you properly remediate the problem.

Once you have remediated the Log4j vulnerability on all your IP-enabled systems and devices, what do you do next? It is at this point that we all need to stop, document what we have done, take stock of what worked and what did not, and then be prepared to do it all over again in the future. The Log4j vulnerability is not going away. Scanning for this particular vulnerability needs to become part of your overall vulnerability management program. You will inevitably purchase new applications, devices, and systems and you need to ensure Log4j, if used, is properly updated (version 2.16 or later at this point in the component evolution). Also, as you work with your application vendors moving forward, some may try to convince you that the risk of Log4j only applies to web-exposed servers and devices. This statement is simply not true. Push back against these statements. Push back hard.

Nothing I have said about vulnerability management in this article is new, and nothing is particularly unique to Log4j. Scan your networks regularly (at least quarterly – more frequently if possible) and review those scan reports. Remediate your findings. If a finding cannot be remediated, budget for a replacement application or device. Keep your applications, components, and operating systems up to date. Cybercriminals are not going away. They don’t take vacations, and they don’t care how many other projects you are working on that prevented you from vulnerability remediation this month or this quarter. The threats are real and we all have to keep playing great defense. Good Luck!

The following is a great webpage from U.S. CERT on Log4j and associated resources:

https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance