Apply Zero Trust Principles to Log4j Risks

December 2021 will likely be remembered as the month a vulnerability in an Apache library known as “Log4j” wreaked havoc. Subsequent attacks are called “Log4Shell”, “Log4js” “LogJam”, and others. The vulnerability is tracked as CVE-2021-44228. It affects numerous products and cloud services across the Internet that leverage Apache. Linux servers host most instances of vulnerable software but a small percentage of them run on Windows servers. The exploit allows for remote code execution (RCE), an AppJacking attack. Organizations with vulnerable servers can be confident that AppGuard will help protect them from the effects of “Log4j2” or “Log4Shell” based attacks.

Will Log4j be the Worst Ever?

Trade magazines and “experts” craving attention are prone to exaggerate. With Log4j, those might not be exaggerations. So much of what is on the Internet relies on Log4j. Mitigations recommended by Apache and others are apparently not easily or quickly done.

Jen Easterly, the director of CISA described the Log4J vulnerability as "one of the most serious that I've seen in my entire career, if not the most serious"

Fortunately, for AppGuard customers, especially those with the more at-risk Linux servers, they are already well protected from this Log4j risk.

Detection Alone is Never Enough

Whenever vulnerabilities and malware make headlines, detection-based endpoint protection vendors usually post new indicators of attack or compromise data. This affirms that there are always attacks for which detection data does not yet exist. Enterprises with Log4j vulnerabilities need non-detection-based protection to augment their detection-based tools.

AppGuard Protection of Linux Servers

Default policies ensure Apache software processes cannot harm their host. Should adversaries exploit a vulnerable Apache application or component, AppGuard would not allow the exploited process to alter critical files, add malicious files to critical areas, inject malicious code into other processes, steal credentials from memory, and/or run malicious files downloaded from the Internet.

AppGuard Protection of Windows Servers

For Apache to run, default AppGuard policies must be altered from prohibiting Java to containing it. We generally prescribe applying containment to all Internet-facing processes. Typical deployments apply containment to both Java and the respective Apache software applications. This prevents their resulting processes from altering critical parts of the host, adding malicious files/data to sensitive places, launching potentially malicious files from low privilege folders, injecting malicious code into the memory of other applications, and/or scraping credentials from memory.

Log4Shell Reminds Us that Applications Cannot be Trusted (a.k.a., AppJacking)

A common element found in nearly all malware attacks is that the adversaries essentially use the applications on endpoints against the enterprise. They use vulnerable or weak applications to either download malicious code into their host or perform harmful actions against the host (Click the AppJacking link for more info). This has always been the inspiration for the name AppGuard and its concept of applying zero trust principles within endpoints to protect the enterprise from its own applications.


Subscribe to our blog to receive email notifications when new posts are added!