<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=2815180&amp;fmt=gif">

Log4j Vulnerability Explained: Longterm Guidance for InfoSec Leaders and Teams

Understand the risks posed by the vulnerability and take steps to secure your systems against similar exploits. 

Cybersecurity researchers and professionals have run out of superlatives to describe the Log4j vulnerability discovered in early December. 

Cybersecurity and Infrastructure Security Director Jen Easterly called it the “most serious” vulnerability she’s seen in her career, and that it could take years to properly address. The NVD gave it a 10/10 CVSS score – the highest rating possible, reserved for the most critical and wide-ranging vulnerabilities. 

Software vendors and their partners and customers have been working around the clock to find out how this vulnerability changes their security profile. Many have already released stop-gap workarounds to keep critical systems secure until a more permanent solution is available. 

However, cybersecurity experts are still investigating the full extent of the vulnerability itself. This limits the actions that enterprise security teams and their partners can take right now. 

How the Log4j Vulnerability Works 

Log4j is an open-source software tool that records events and communicates them to system administrators and users. These diagnostic events include errors and routine system operations, which are committed to a log. 

The vulnerability abuses a feature of Log4j designed to customize the way log messages are formatted. This allows attackers to abuse the servers hosting these logs and submit arbitrary code directly on the target device. 

This is an extremely dangerous vulnerability for several reasons: 

  • Log4j is everywhereAll software uses logging to some extent. Log4j is a popular and widespread open-source logging solution for Java, itself one of the most popular programming languages. Almost all software written in Java uses the Log4j library, and almost all enterprise tech stacks include software that uses Java. 
  • It is simple to exploit. Abusing Log4j to gain unauthorized access to a target system requires very little technical skill. Attackers don’t need sophisticated software or special expertise to launch an attack. Attackers can exploit the Log4j vulnerability simply by typing a string of characters into a chat window – which then arrives in a log and gets interpreted as a command. 
  • Patching is piecemeal. There is no one-size-fits-all solution for patching the Log4j vulnerability. Log4j is often bundled with other pieces of software, so you may have multiple copies of the library hidden throughout your network. Reputable tech vendors like Castra have already released custom-built search parameters, rules, and signatures for detecting Log4j vulnerabilities in their systems – but not every tech vendor is as quick or responsive. 

Assessing the Full Impact of Log4j Will Take Time

It can help to think of Log4j as part of the software supply chain. Copies of the library may reside on your own Java-based enterprise applications, but they may also reside on vendor applications or even legacy products that you use. It is integral to all the most popular cloud-based business applications, so you can’t simply run a search for all files named “Log4J” and hope to get an accurate idea of how reliant your organization is on it.  

As a result, many InfoSec leaders and their teams must wait until their vendors confirm the use of Log4j in their Java applications and release an appropriate patch to prevent exploitation. 

In the meantime, enterprise IT teams need to comb through all their own applications to determine whether any of them rely on Java applications that use the Log4j library. Even for a meticulously organized enterprise with excellent asset management protocols in place, this is a painstaking, time-consuming process that may take months to resolve with confidence.

What Should InfoSec Leaders Do for Now? 

Enterprises, tech vendors, and their partners are running comprehensive security audits of their applications, and InfoSec leaders need to do the same. Employers must turn their attention to remote workers, ensuring they update personal devices and routers, since these are vulnerable entry points into enterprise applications and databases. 

Beyond running audits on their own tech stack, InfoSec leaders must rely on reputable managed detection and response (MDR) vendors who can help them catch and mitigate Log4j exploits in real-time. 

Secure your Tech Stack Against Log4j Vulnerabilities 

Castra has taken great lengths to verify its security tech stack for Log4j exposure. We've asked our partners to confirm whether their software is vulnerable to Log4j exploits and independently verified their responses: 

  • Exabeam is fully patched against the Log4j vulnerability. The company has been very responsive towards its user community, releasing workarounds for its Site Collector, SOAR, and On-Premises solutions, although there are reports of the company’s On-Premises solutions causing client issues. 
  • Our ticketing system, ManageEngine’s Service Desk Plus is not affected by the Log4j vulnerability. 
  • Wazuh Cloud is not impacted, but on-premises users will need to run a quick fix to patch their systems. This is easy to do using the software’s remote command scheduling functionality. 
  • Zabbix is an open-source monitoring tool that is not affected by the Log4j exploit. 
  • Atlassian has already patched its cloud products against the Log4j vulnerability. Confluence is safe to use. 
  • Thycotic is an endpoint privilege management solution that is not affected by the Log4j vulnerability. 
  • AT&T’s event-driven USM Anywhere SIEM platform is not affected, since it uses a version of Log4j that cannot execute commands from log data. 
  • Anomali Lens, Match, and ThreatStream are not affected. Anomali has lists of IPs and C2 nodes exploiting this vulnerability, so Castra users can detect Log4j-related threats using this platform. 
  • Palo Alto Networks’ Cortex protects users from Log4j vulnerabilities, and the platform has detection rules for Log4j exploit signatures throughout user networks. 

 

With a tech stack that offers cutting-edge detection and response to new threats, Castra users are equipped to identify and protect against Log4j exploits effectively. Castra customers can reliably detect and remediate these problems with the help of our diligent, highly trained security specialists. 

Can we help your team with Log4j? Contact us.