Everything You Need to Know to About the Log4j Vulnerability

The last couple of months have been a lot to manage for security teams, and many will continue to struggle with ensuring a holistic response. First, it’s essential to understand the technical underpinning we’re working with to understand recent events.

Twenty-one years ago, Log4j v1 emerged as a standard logging library for Java™ applications, and now with Log4j v2, it’s one of several logging services for a vast number of Java-based services. It is distributed as part of the open-source Apache Software Foundation® License to provide applications a straightforward mechanism to log application & user-generated data from within an application.

Additionally, within log4j, there is something called Java Naming and Directory Interface (JNDI) class, which provides object and variable lookup resolution. This resolution process is where the exploits can be launched, and these infections range from simple mass scanning within the network looking for other hosts to infect, all the way to installing backdoors that can exfiltrate data. 

The Log4j Vulnerability

What allowed these exploits to occur was specific to vulnerable code within the JNDI lookup function class and present dating back to 2013 revisions. However, only recently, on Nov. 24, 2021, a security researcher discovered the vulnerability and brought it to the public eye.

The vulnerability allowed attackers to easily send commands to servers that, if vulnerable, would execute whatever command sent their way. In addition, it included one of the most critical classes of infections, a Remote Code Execution (RCE) which gives attackers full remote access to the host system to launch anything they want.

Shortly after the vulnerability public announcement, threat actor groups began writing software that would scan for and exploit the vulnerability at scale across the internet. Some even distributed the code for free so other nefarious actors or nation-states could seek out vulnerable targets as well.

On Dec. 9 and Dec. 10 of 2021, vulnerability databases, produced by the vulnerability identification & management companies, had published the vulnerability to deliver awareness to the community. However, bots were already scanning and exploiting wherever they could find the weak systems by then.

In the coming weeks, with the additional level of attention, more vulnerabilities were discovered within the Log4j libraries, and security and development teams worked throughout December 2021 to address the findings. Below are all current vulnerabilities around Log4j v2:

How to Secure Your Network

To keep organizations safe from exploits around Log4j, our security team recommends the following actions: 

Patch Early and Patch Often

Specifically, for Log4j, the most current patch level version is 2.17.1. Treat this as a learning opportunity. If not already in place, use this time to build a system or systematic process to ensure that future versions of all applications, software, code, workstations, and servers stay up to date by scanning patching with a regular cadence. 

Develop Zero Trust

Treat the inside of a network just like the outside, untrusted network. For example, develop a zero trust or least privilege approach that only grants access and permissions when required and only to those that truly require it for business continuity. Also, isolate workloads from each other. If there is no need for an application or system to communicate, deny that traffic by default. 

Assume the Worst

Assume all RCE based vulnerabilities can lead to worm-able-based infections, meaning that through the victim server, other servers risk exploitation. Assume that your systems and networks will be compromised.

Remove the Code

If patching to the latest code revision of Log4j based applications is not possible, consider removing the JDNI lookup class function. However, proceed here with caution as it might cause some applications not to function as intended. 

Investigate Malicious Activity

If you’re running a vulnerable version of log4j, look for indicators of attack or indicators of compromise. For example, the vulnerability could include creating new users, unexpected log activity, abnormally high resource utilization, or strange network traffic entering and exiting your workloads. 

Security Testing

Conduct purple team exercises, where the red team attacks and the blue team verifies visibility and ensures defenses like EDR and IPS work as intended. If not, tune it accordingly and run it again. 

Tracking. Tracking. Tracking.

Create a system to track your network, including assets, users, and vendor software. If suddenly new unknown assets, users, or software are found, and it’s unclear why investigate it. Track it down because it had to originate from somewhere. 

Solving Together

It’s time to put a roadmap in place. Start with these five questions.

1) How would your organization respond?

2) Would your critical logs already be stored off-device for investigation?

3) Could the application or database be restored from backup in a timely fashion?

4) Would anyone on the team know how to create a forensically sound image?

5) Are roles and responsibilities in place, so each member knows who to contact or what to do? 

Cybersecurity has always been critical, but it’s taken on new urgency as the number and intensity of cyberattacks have escalated. But all too often, organizations believe they have a handle on complex security challenges, and the perception is far from reality. Our recent survey of 1,400 global IT leaders found many are overconfident in their security capabilities.

The Rackspace Technology® “Is Cybersecurity Meeting Today’s Intensifying Challenges?” white paper provides insight into how IT leaders can assess their current cybersecurity posture and create a security strategy that can stand up to today’s increasingly complex cyberthreat landscape.