<img src="https://ws.zoominfo.com/pixel/0nVRFDqEc4KEsx6wmKaS" width="1" height="1" style="display: none;">

BTB’s Guide to the Log4j Vulnerability

2021 has been a busy year for us here at BTB Security, and it doesn’t look like things will change anytime soon. Just as many organizations began winding down for the annual holiday season, news of a recently-discovered critical software vulnerability broke. Described by Jen Easterly, director of the U.S. Cybersecurity and Infrastructure Security Agency (CISA) as “the most serious vulnerability I have seen in my decades-long career,” this software bug is ubiquitous, easy to exploit, and one that enables remote code execution, meaning that attackers can use it to take full control of an affected system.

Now known as CVE-2021-44228 (though numerous related CVEs have, and will continue to be discovered), the vulnerability involves a flaw in Log4j, which is part of an open-source logging library that’s widely used in consumer and enterprise software applications as well as cloud services. Maintained by the Apache Software Foundation, the Java logging framework that includes Log4J is commonplace within the software that we all rely on every day — including cloud storage from Google, Amazon, Microsoft and iCloud, software from Oracle, Salesforce and IBM, and the popular video game Minecraft.

The Log4j vulnerability: What you need to know

The Log4j vulnerability is especially devastating because it combines three traits that pose major challenges for security and vulnerability management teams:

  • it’s ubiquitous
  • it’s hard to find within software
  • it enables attackers to run arbitrary code (including a shell), which means they can execute code, even remotely and without credentials.

This vulnerability impacts systems and services that use the Java logging library Apache Log4j versions 2.0 to 2.16 (though this has, and may again, change to include later versions as some quickly released “fixes” have been incomplete). This includes the majority of services and applications that were written in Java, which has been — together with C — the programming language of choice for developers in large enterprises and tech companies for the past 20 years. Because the Log4j library is often buried deep within strings of dependencies, it can be extremely difficult to find and patch this particular vulnerability.

“It’s especially dangerous because it’s in everything,” says Matt Wilson, Chief Information Security Advisor at BTB Security. “If you stop what you’re doing right now and try to identify all the software you have that leverages Java, you’re almost guaranteed to miss some. Finding and patching this vulnerability will need to be an iterative process that takes place over time. It’s going to be a gift that keeps on giving.”

CISA published an alert urging administrators to apply the Apache-recommended mitigations on December 10, but security researchers suggest that the vulnerability was already being exploited in the wild. Cybersecurity vendor CheckPoint said that its team had observed more than 60 different variations on the original exploit within a 24-hour period, estimating that attackers had already attempted to use it to gain access to networks within half the major corporations in the world. It’s probable that hackers have already made hundreds of thousands of attempts to identify vulnerable devices.

Protecting your organization: What you should do

We’re urging our clients to immediately patch all vulnerable software, it’s the most important step. Secondly, consider running a vulnerability scan for Log4j as soon as possible. However, it’s important to note that this bug is easy for vulnerability scans to miss. This means that a “clean” vulnerability scan does not guarantee that your organization isn’t vulnerable. Instead, you’ll need to repeat the scan regularly — we recommend on a daily basis — for the foreseeable future as additional plugins are released that may improve the scan’s reliability.

In addition, we encourage you to:

  • Create a software asset inventory if you haven’t already done so; if you have a software asset inventory, review it to find all instances of Java within your environment.
  • Review the Software Bill of Materials (SBOM) for all software that’s been purchased or included in contracts for your organization. If available, this can be very helpful.
  • Pay attention to vendor notifications, advisories, and alerts. Update vulnerable software immediately or as soon as possible.
  • Communicate with your internal development teams. Together, you can review source code repositories and complete a software composition analysis to help you find instances of Log4j use.

We’ve been conducting ad-hoc external and internal scans to help our RADAR clients identify vulnerable hosts. Of course, RADAR clients will continue to benefit from the in-depth visibility, advanced detection, and automated response capabilities that our platform makes possible.

While security monitoring can’t prevent attackers from initially exploiting the Log4j vulnerability, it can prevent attacks from progressing from precursor activities to full-scale breaches. With an advanced Managed Detection and Response (MDR) service like RADAR, you can be confident that there’s always a set of expert eyes watching over your network, looking out for indicators of compromise (IoCs), including those associated with this flaw.

Want to keep up with the latest news on Log4j and other relevant threat intelligence? Follow btb_alerts on Twitter. Or set up a free consultation with a member of our team of experts today.

 

Contact Us

Related Posts