CISA Log4j Emergency Directive, Experts Weigh In

CISA today has issued an emergency directive giving all federal agencies until December 23rd to patch systems and assess their internet-facing networks for the Apache Log4j vulnerability. The directive comes in response to the “active exploitation by multiple threat actors” of the Log4j bug, which emerged December 10th.  Experts with Gurucul and Cyvatar offer perspective.

Notify of
2 Expert Comments
Most Voted
Newest Oldest
Inline Feedbacks
View all comments
Saryu Nayyar
Saryu Nayyar , CEO
InfoSec Expert
December 20, 2021 12:23 pm

<p>CISA has issued Directive 22-02, directing Federal agencies to address or mitigate the vulnerability found in the Log4J logging library if they are using it. The consensus seems to be that this is the worst security flaw to arise in a software library in years.</p>
<p>Every organization should have a mitigation plan in case something like this comes up again in the future. Whether it be to shut down the offending piece of software, or immediately patch it and tests the patch before it goes back into production, teams need to be prepared for a positive response within hours or even minutes. And this goes far beyond Federal agencies into the private sector, too.</p>

Last edited 6 months ago by Saryu Nayyar
Ryan Moorman
Ryan Moorman , Principal Cydekick
InfoSec Expert
December 20, 2021 12:27 pm

<p>Don’t cancel your holiday plans because of CVE-2021-44228 Log4Shell in log4j.  Log4shell is a zero-day vulnerability that exploits the popular java logging framework called Log4j by logging data including user input leading to the unauthorized installation of code on the server.</p>
<p>Simply put, you blindly trust the user input data coming from outsiders and open up your server to sneaky tricks. This vulnerability has been found in versions 2.0-beta9 up to 2.15.0. <a href=\"\" target=\"_blank\" rel=\"noopener\" data-saferedirecturl=\"\">2.16.0</a> is the latest version that is stable and recommended for an upgrade.</p>
<p>Log4Shell, formerly known as CVE-2021-44228, is primarily because of what NIST calls improper input validation. It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allow attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack.</p>
<p> Log4j 2.15.0 makes a best-effort attempt to restrict JNDI LDAP lookups to localhost by default. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This vulnerability was first reported to Apache organization by Alibaba’s security team on Nov 24th, 2021 which was later made public on Dec 9th, 2021.</p>
<p>Here’s how to mitigate the risk. Whether you are impacted by this vulnerability or not, it just makes more sense to play safe than to be sorry. The following are the steps you can take to mitigate the risk due to Log4j vulnerabilities:</p>
<li>Upgrade to version 2.16.0 that disables JNDI by default. A user needs to explicitly enable it.</li>
<li>Configure the firewall to watch TCP connections</li>
<li>Checking on the vendor software version. Unfortunately, you can’t do much with vendor software unless an update is available from their end. The security patch must be provided by the vendor to their software. When the update is available, download and install the update</li>
<li>Scanning remote endpoints by triggering DNS query.</li>

Last edited 6 months ago by Ryan Moorman
Information Security Buzz
Would love your thoughts, please comment.x