What You Need to Know About the Log4j Vulnerability

cyber security

Written by Dan Callahan

I am a Senior Technical Advisor to CGNET. Formerly, I managed our Cybersecurity and Cloud Services businesses, and provided consulting to many clients over the years. I wear a lot of hats. Professionally, I'm a builder of businesses. Outside of work, I'm a hobby farmer, chef, skier, dog walker, jokester, woodworker, structuralist, husband and father.

December 22, 2021

Oops. As if an actual virus was not bad enough, now IT Managers find out about the log4j vulnerability. I am going to discuss what you need to know and do about the log4j vulnerability. I will also discuss what problems like the log4j vulnerability say about the use of open-source software. If you have already addressed this vulnerability, congratulations! You may want to skip to my discussion about open-source implications. If you are just learning about the log4j vulnerability, read on and check out some of the linked information… you have some work to do!

What is the Log4j Vulnerability?

Log4j is an Apache log file utility. It was developed as an open-source project and is widely used by developers. (Working with log files is a common need for application developers.) Developers added the ability to request a lookup and return variable information via the Java Naming and Directory Interface (JDNI). Hackers can use this function to launch Remote Code Execution attacks. Worse, if the hacker controls the relevant Domain Name System (DNS) zone, the log4j vulnerability will attempt DNS resolution for any lookup requests—essentially telling the hacker where to find sensitive information. This video from the SANS Institute provides a nice explanation of the log4j vulnerability and steps you can take to prevent or mitigate attacks.

The problem with the log4j vulnerability is that log4j is used in all kinds of applications. Log4j is used low in the Open Systems Interconnect “stack”. This means the log4j vulnerability may be present in any application running on Apache Linux. The log4j vulnerability was reported at the beginning of December, and reports of hacks started arriving by mid-December.

The Remediation Response: Find and Patch

Fortunately, the log4j vulnerability has been resolved via a patch that is now available.

If you cannot patch your systems yet, you can disable remote lookups. You can also implement a firewall rule that prevents remote connection requests to servers that would not normally talk to your server.

CISA has released a utility that you can use to find instances of log4j. Grab the utility and use it to scan for and discover log4j instances. If the log4j instance is using the 1.x software release, it is not susceptible to the log4j vulnerability. If the log4j instances are on the 2.x software release, you will need to apply the patch.

In addition to looking for log4j files, you can look for these suspicious activities.

  • A spike in CPU usage
  • A persistent connection to a server
  • An unauthorized configuration file change

These activities might be legitimate, but they might also be indicators of an attempt to exfiltrate data.

What Are the Implications for Open-Source Software?

Imagine an infection (listeria, salmonella, botulism, etc.) that gets into the world’s soybean supply. Think about all the products (beyond hummus!) that use soy in one form or another. Now imagine that there are few restrictions to the flow of soy throughout the world. You have an infectious agent that is part of many food and consumer products, with little ability to track or stop the spread of this agent.

(Gee, I am just full of happy news today!)

As my friends at IO Active have pointed out, the log4j vulnerability was created when volunteer coders modified log4j, with no oversight. It is doubtful that there was any high-level design review conducted. There was no change control, asking about the potential impacts and a rollback plan.

Unfortunately, IT Managers cannot avoid the problem of questionable open-source software by using purchased software or services. Open-source software sits below applications that are developed using software development best practices. As I have discussed previously, IT Managers must ensure that they understand how their applications are architected. They must hold application providers accountable for the ultimate quality and security of those applications. Taking these actions will not prevent problems like the log4j vulnerability. But taking these actions will make it easier to avoid some problems and successfully remediate others.


You May Also Like…

You May Also Like…


Submit a Comment

Your email address will not be published. Required fields are marked *

Translate »
Share This