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 under 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 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 version is now Log4j 2.17.1 and up. Due to the extensive usage of Log4j as a preferred logging framework (Java runs on nearly 3 billion+ devices), the Log4Shell vulnerability continues to be relevant in 2022, as IT security teams race to beat repeat attack attempts, and on the other hand, potentially high penalties are expected to be levied for non-compliance. This needs a holistic approach to fix all internet-exposed components including third-party integrations.
How to fix it
- Patch first. Then, apply firewalls, disable remote lookups. All internet-facing code with old versions of Log4j need urgent scanning and fixing, including a comprehensive fix 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, or unnatural behavior in network connections, volume spikes, or suspicious interruptions.
- Embrace a DevSecOps culture where developers, security professionals, and operations teams develop strong collaboration and work together to discuss, spot, fix, and avoid vulnerabilities.
- Choose approved, robust troubleshooting tools and avoid free tools from unverified online sources, as they may 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.
- 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.
- Implement a prompt, centralized, and automated patching routine of software versions and a thorough monitoring of all exposed components to stay ahead of vulnerabilities.
- 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.
- 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".
- Use Open Source wisely. Since Log4j is open source, a criticism is that its unfounded, legacy code is unsecure and used by many developers without thinking. However, the silver lining about open source is that because it is freely available, it can be readily fixed and shared by the community.
It is also prudent to understand that the Log4j vulnerability is only one of many, and more are waiting to be exposed. Experts warn that though the worst may seem to be over, it is too soon to carry on as usual. 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 code book is also imperative.
Cloud monitoring solutions, including Site24x7, understand the seriousness of the vulnerability, and immediately scan their systems to rule out exploits. Also, when applications face the Log4j vulnerability, Site24x7's APM Insight has a built-in Java agent that detects them immediately, and shows them up on the central APM console.
The ubiquitous Log4j bug will be with us for years. John Hammond, senior security researcher at Huntress, discusses what’s next.
Jen Easterly, the director of the Cybersecurity and Infrastructure Security Agency (CISA), stated in a public news interview that the now-infamous Log4j flaw is the “the most serious vulnerability that [she has] seen in her career.” It’s not a stretch to say the whole security industry would agree.
December of 2021 will be looked back on with a tinge of trauma and dread for incident responders, system administrators and security practitioners. You all probably already know— on December 9, a remote code execution vulnerability threatpost.com/new-log4shell-attack-vector-local-hosts/177128/ in the programming library named Log4j, which is nearly ubiquitous in Java applications and software used all across the internet.
It felt like this vulnerability affected, well, everything. On top of that, it was very difficult to determine what applications were vulnerable, and from what entry point.