Top 7 lessons from the 2021 Log4j vulnerability

The Log4Shell (CVE-2021-44228) zero-day vulnerability in the Java logging framework Log4j (versions 2.0 to 2.14.1) was revealed on December 9, 2021. The Apache Foundation assigned the maximum CVSS score of 10 to Log4Shell, as millions of servers and, potentially, billions of devices came at risk. Security professionals around the world began patching the vulnerability and scanning their systems to rule out any potential breach.

How attacks happen

• The vulnerability is an input validation vulnerability, where lookups are processed automatically, in this instance, through the Java Naming and Directory Interface (JNDI) feature.
• An attacker hosts a vulnerable Java class in a remote server.
• The attacker injects a vulnerable log message that loads a class from their server into the application, which executes the vulnerable code in the target server.
• Since formatting is nestable, the cascade of events can be serialized to expose a large volume of data quickly.
• Since Log4j is used in both client and server applications, it makes them equally vulnerable as any user input can be parsed by Log4j.

Though the Apache team has removed the vulnerability, and for additional security, also disabled the remote lookup facility from Log4j v 2.16.0 onwards, the safest versions are now Log4j 2.17.1 and later. Due to the extensive usage of Log4j as a preferred logging framework, and because Java runs on about 3 billion devices, the Log4Shell vulnerability continues to be relevant in 2022 as IT security teams race to thwart repeat attack attempts, and higher penalties are expected to be levied for non-compliance. A holistic approach is needed to fix all internet-exposed components, including third-party integrations. 

How to fix it

• Patch first. Then, apply firewalls, and disable remote lookups. All internet-facing code with old versions of Log4j needs urgent scanning and fixing, including a comprehensive resolution across all the instances across cloud servers.
• Consider the Isolate, Minimize, Monitor, and Active defense (IMMA) model.
• Attackers always leave footprints. Comb for CPU spikes, unauthorized configuration changes, unexpected logs, and commands, unnatural behavior in network connections, volume spikes, or suspicious interruptions.

Seven lessons

1. Embrace a DevSecOps culture where developers, security professionals, and operations teams develop strong collaboration and work together to discuss, spot, fix, and avoid vulnerabilities.
2. Choose approved, robust troubleshooting tools, and avoid free tools from unverified online sources, as they might worsen the situation and expose your systems to further exploits. Know your attack surface, and run static code analysis to spot vulnerabilities at the source code level.
3. Adopt secure software development practices. Focus on developing lean code. Provide unexpected features as opt-in features to reduce loopholes further. Design simple software libraries, and compose further libraries on top of it in a robust manner, stripped of unnecessary functionalities.
4. Implement a prompt, centralized, and automated patching routine of software versions, and thorough monitoring of all exposed components to stay ahead of vulnerabilities.
5. Scan the use of Log4j across all systems. Ubiquity, longevity, prevalence, and unmonitored usage of Log4j across such a huge number of instances have made this a global issue. Look into every library, open-source and closed, for similar vulnerabilities, and fix them proactively before the attackers find them.
6. Enforce a Zero Trust model in your data management practices, which is a philosophy built on the principle of least privilege of "verify first, then trust".
7. Use open-source wisely. Since Log4j is open source, criticisms are that it is untested, unsecure legacy code, and often written under time constraints by more than one developer attempting to address conflicting requirements. However, the silver lining about open source is that because it is freely available, it can be readily fixed and shared by the community.

Understand that the Log4j vulnerability is only one of many, and more are waiting to be exposed. Security experts warn that though the worst might seem to be over, it is always wise to be vigilant and stay aware of the latest security threats. The overall remedy lies in not just patching Log4j to the latest releases, but also in running a thorough scan of all IT systems with exposed servers and cloud components. A thorough revision of security practices to establish a new codebook is imperative.

Cloud monitoring solutions, including Site24x7, understand the seriousness of the vulnerability and immediately scan our systems to rule out exploits. Also, when applications face the Log4j vulnerability, Site24x7 APM Insight's built-in Java agent immediately detects and displays them on the central APM console.