Action plans for Log4j or Log4shell

In early December, reports began to circulate about the vulnerability in Apache’s Log4j 2, the second version of a popular Java logging framework. As it turns out, the vulnerability, known as “Log4Shell” or “Log4j/Shell” is one of the most serious cyber threats in recent history. Think wannacry, heartbleed or the exploit that led to the 2017 Equifax data breach. Mitre’s common vulnerabilities and exploits (CVE-2021-44228) alert on Log4Shell gave the threat a score of 10, the highest rating possible. Why is Log4j such a serious concern? And more importantly, what can you do about it? Here is Masergy’s advice.

What is Log4j/shell?

Log4j is a piece of free and open-source software, specifically a Java library that logs error messages in applications. The fact that it is free for anyone to use is a big part of why this vulnerability is such a big problem – the software is essentially everywhere. Since 2013, Log4j has been installed in almost every type of device on planet earth – servers, software applications, and computing devices including phones. It’s built into frameworks such as Apache Struts2, Solr, Druid, Flink and Swift. Unpatched, Log4j/Shell represents a powerful “Zero Day” exploit.

Why is Log4j/shell generating so much attention?

Log4j/Shell has generated massive engagement and activity among cybersecurity professionals and a sprint to remediate the vulnerability. What’s the big deal? Several factors account for the extreme nature of the reaction:

• Ubiquity: One is the incredible ubiquity of the software itself. As mentioned, it’s everywhere and in almost every device used by corporations, governments and consumers.
• Simplicity: Another issue is the apparent simplicity of the flaw. It seems that almost anyone could potentially gain access to a vulnerable device merely by sending a 12-character code or renaming their device with that code. Indeed, the flaw first emerged in the Minecraft game, where it became evident that players could use the exploit to run arbitrary code on pretty much any of hundreds of millions of servers and devices around the world.
• Weaponization: The third major area of concern relates to how Log4j/Shell may be weaponized by malicious actors. It could be used to take over machines for cryptocurrency mining. Or, it could comprise the basis for distributed denial of service (DDoS) attacks. It’s a powerful tool at the hands of cybercriminals.

What should you or your company do about Log4j/Shell?

What should you do about this? The short answer is start patching! Patch everything with a sense of urgency.

However, for patching to be meaningful, organizations will first need to inventory devices that have Log4j installed. The Log4Shell vulnerability scanner from Huntress is one tool that can perform this task. This should include both internal- and external-facing devices. Some of the official guidance that’s come down on mitigating Log4j/Shell has focused on external-facing devices. This is not enough, because internal devices can also receive log data from untrusted sources.

This will be a massive undertaking, and in for many, it will be difficult to complete. With literally billions of servers, IoT devices, endpoint devices, and endless instances to deal with, it is almost a certainty that some systems will remain vulnerable to this threat.

It’s safe to say, we’ll be living with Log4j/Shell for years. As a result, it makes sense to do whatever you can to harden systems that contain sensitive data to protect them from Log4j/Shell exploits.

Key Takeaway and Lesson Learned: This threat episode reveals the risks inherent in using open-source code in application development without paying adequate attention to security. Longer-term, a good practice will be to maintain a repository of libraries that are known to be secure as part of a secure DevOps process.

Do SASE and Zero Trust help with Log4j?

A quick disclaimer: Masergy never claims or even implies that our company, advice, products and services will completely prevent vulnerabilities or exploits such as Log4Shell. No managed security service, including SASE and Zero Trust, can 100% prevent zero-day (no notice) cybersecurity threats. However, choosing a trusted security services provider, like Masergy, as your partner empowers companies to monitor their IT environment for threats and respond with more efficiency, agility, and speed to changing circumstances in the global cybersecurity space.

The Secure Access Service Edge (SASE) model of security has a great deal of applicability to strengthening defenses against Log4j/Shell. SASE has multiple security components, but for Log4j/Shell, the most important element is Zero Trust (ZT). With ZT and Zero Trust Network Access, access to any digital asset, be it a network or an application, is denied by default. No one is trusted until properly verified.

ZT is a good countermeasure against Log4j/Shell because Log4J runs without pure trust. An unauthenticated person can send the fatal Log4j/Shell input string. With ZT, that unauthenticated user will be automatically blocked from being able to access a network, device or application. With the software-defined wide area network (SD-WAN) part of SASE factored in, the ZT mitigation of Log4j/Shell is now spanning an organization’s entire network.

Conclusion: The race is on to mitigate

Log4j/Shell represents a major cybersecurity event. It poses a threat to billions of digital devices worldwide. The exploit could have a significant impact on corporate operations and governments. The race is on to mitigate the risk. It will not be an easy process. New models, such as SASE, can help in this effort, as well in preventing further events of this kind in the future.

If you need help handling security at this critical time or would like a copy of Masergy’s security bulletin with more detailed information and guidance on Log4j, contact us.