When Log4Shell, an easy-to-trigger exploit in Apache Log4j, one of the world's most popular packages, was disclosed on December 9, it set off a firestorm of activity for security teams around the world. With all that's going on in the world these days, maybe a CVSS severity 10 0-day is what it takes for 2021 to really go out with a bang.
Thankfully, Zentera does not use Log4j and is not affected by this issue, but many other companies are. What happened, and why is Log4Shell such a problem for companies? And, more importantly, what can companies to do protect themselves from being hacked?
What is Log4Shell, and why do I care?
Log4Shell exploits a vulnerability in the ubiquitous Apache Log4j logging package for Java. Log4j was released over 20 years ago, and due to the popularity of Java, this package has found its way into an incredible number of projects, both in vendor products and in customer in-house applications.
The exploit itself is easy to trigger; all the attacker has to do is get the victim to log a specially crafted message. That's usually pretty easy for anything with a web interface, as most user input is logged in some way in order to maintain a transaction history and for debugging purposes. Log4j is tricked into interpreting that string as a command to open a connection to a remote server and download a malicious package.
The sheer simplicity of this attack has led to a huge spike in attempts to exploit this vulnerability. As a web interface as it's often the main user input, you can't just hide vulnerable products behind a VPN. This practically guarantees bad actors a target-rich environment to exploit.
Is my company at risk because of Log4Shell?
You should assume so, and immediately take action to check with your vendors and app developers. CISA has created a helpful community-sourced repository to list vulnerability status for various vendors that may shortcut some of the work.
What can I do about Log4Shell?
First of all, patch all vulnerable products as soon as you can to remove this vulnerability. In addition to patches, vendors may have alternate recommendations to help you mitigate the impact of Log4Shell in your environment by using different configuration settings.
However, vendors release patches at different speeds. Many vendor patches are already available, but some vendors may take months to release patches. And this assumes that you have an active maintenance and support agreement with your vendors, which may not be the case for legacy software licensed perpetually. Some EOL software may never be patched, and if the vendor has gone out of business, patching may never be an option.
How can I mitigate Log4Shell without patching?
Without patching, you may not be able to fully block the Log4Shell exploit. However, you can take steps to mitigate the potential risk of compromise, even if you cannot patch.
A successful compromise requires an attacker to trigger an access to a malicious remote server. While this is commonly using the LDAP protocol, an attacker use other protocols, such as LDAPS, Java Remote Method Invocation (RMI), DNS, and the Internet Inter-ORB Protocol (IIOP).
You can configure your perimeter firewall to block access to the Internet for those protocols from an unpatched server. This will block the download step which injects the malware payload to the vulnerable application server, thereby protecting the company from compromise. However, it may be difficult to set up and manage rules if there are more than a handful of vulnerable servers that need protection.
Application Chambers provide another simple option. An Application Chamber is essentially a Zero Trust firewall that is deployed to individual application servers and allow Chamber policies to be configured as a group. Policies are based on identity, allowing you to cloak the unpatched application servers and provide privileged access only for identified users and applications. The Chamber policy can be set up to block unidentified outbound traffic to the Internet for vulnerable application servers, without having to program the corporate firewall. Simply installing Zero Trust security agents on the endpoint inoculates those servers against Log4Shell, while cloaking applications reduces the attack surface to protect against the next 0-day to hit the press.
Share this article
