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.
[“source=rackspace”]