Log4j vulnerability - WST

If you have been on the internet at any point in the last couple weeks, you have no doubt heard about the log4j (Log4Shell, CVE-2021-44228) vulnerability making waves through the consumer and enterprise environment. To help underscore the seriousness of the issue, note that the CISA has directed all federal agencies to remediate the issue on their systems by 5:00 pm EST on December 23, 2021 (https://www.cisa.gov/news-events/directives/ed-22-02-mitigate-apache-log4j-vulnerability-closed). While the attack surface is large, the attack appears to be manageable with proper patching and possible configuration changes.

This still leaves the question, “Am I vulnerable? How can I know?” This is where things can get tricky, because log4j is a logging software used for many web applications and services. The CISA is maintaining a list of affected software and services at https://github.com/cisagov/log4j-affected-db

If you have the resources to hunt for the issue in your own environment, various tools have been released to help track down if log4j is in use, as well as the version of log4j running. Manually searching for files named log4j or looking for any files utilizing the vulnerable function (JndiLookup.class) is an effective way to figure out if you’re running the potentially vulnerable service; however, it’s not particularly easy to do at scale. While log4j version 1.0 is unaffected by this vulnerability, all 2.0 versions below 2.15 are vulnerable to this attack and could be exploited. Version 2.15 partially fixed the issue but is still vulnerable to a denial-of-service attack, so it is recommended to update everything to 2.17 or later.

As with any vulnerability that comes to light, the best thing you can do is not panic, assess your systems, and update accordingly. Any vendor managed applications or systems should also be remediated if applicable, so reach out to your vendors if you have not already.

Authored by: Mark Fromme, eCPPTv2