Log4j (Log4Shell) Poses Near-Zero Risk with Zero Trust

A Discovery That Shook the Internet

On Thursday, December 9, 2021, a security researcher discovered a severe zero-day vulnerability in the Log4j log collection framework used for Java applications. This specific vulnerability (CVE-2021-44228) is called “Log4Shell.” The problem is that the Log4j framework is particularly straightforward and follows its requests without any vetting or verifications. This “100-percent trust” approach allows hackers to execute code by sending a specific request that will execute a payload of code inside a string of code or commands.

As a result, any Java application or device containing Java that is connected to the public Internet can be accessed by hackers to perform all sorts of commands, including the installation and operation of malicious code. 

The Microsoft Security Response Center reports that most Log4Shell activities to-date have been mass scanning and fingerprinting by hackers—probably for future attacks—as well as scanning by security companies and researchers. Other observed activities have included installing coin miners, Cobalt Strike to enable credential theft and lateral movement, and exfiltrating data from compromised systems. 

Who or What can be Affected?

The discovery of this zero-day vulnerability has created a virtual earthquake because it affects anything that uses Java. Any servers exposed to the Internet, and have Java applications with the affected Log4j library are at risk. According to Wired magazine and Dark Reading, hundreds of millions of devices are potentially affected. As a result, a lot of companies have been—and still are—very busy over the last few days updating their code with the Log4j update.

Major tech vendors and services such as Amazon Web Services, Cisco, Google Cloud, IBM, and Microsoft have all reported that some of their services were vulnerable and have been quickly working to fix any issues, release software updates where applicable, and advise customers what they should do.

What We are Doing or Have Done

Since the Log4j flaw was discovered, networking experts at Perimeter 81 have been:

  1. Identifying any potential instances of the vulnerable Log4j code in our environment
  2. Assessing the impact and upgrading our systems and infrastructure where applicable
  3. Mitigating any vulnerabilities with any third-party solutions we use
  4. Having our developer and technical teams fix any software or firmware issues as soon as possible

What You Should be Doing

  1. Closely follow the announcements from Perimeter 81 and your other IT vendors to see if any of your IT resources are at risk
  2. Implement software and firmware patches as soon as they become available for your non-cloud resources
  3. Monitor your network for unusual activity
  4. Communicate with your employees, customers, and partners
  5. If you are only using selected features of Perimeter 81 have not yet implemented ZTNA now is the time to start. Please contact our Customer Support for assistance.

Why Perimeter 81 and ZTNA Minimize Your Risk

Perimeter 81 takes a zero-trust approach to its solution and services and should minimize your risk. If you have implemented a Zero Trust Network Architecture (ZTNA) with Perimeter 81, your servers are not publicly exposed to the Internet, but only to users who meet certain rules and are allowed past your hardware firewall or Firewall as a Service (FWaaS). 

Although there are very few services that must be open to the public Internet, such as a corporate website, they are easy to track and maintain. Using ZTNA to protect and hide all of the internal services from public access mitigates the Log4Shell vulnerability by only passing activity logs within the internal network, and does not allow them to be sent outside the local network over a public Internet connection.

Perimeter 81’s ZTNA significantly reduces the attack surface and potential damage to the internal network since you are able to precisely control and limit any traffic generated from outside or inside the network. This is the opposite of the “100% trust approach” of the Log4j flaw. By segmenting your cloud or hybrid network with ZTNA, you can also prevent the spread of malicious code or activity within your organization’s network and its resources.