Log4Shell – Follow This Multi-Layered Approach for Detection and Remediation

Since the Log4Shell vulnerability was first discovered, Qualys has analyzed and responded to the threat in a systematic way approaching it from all angles – detection, mitigation and remediation. Recognizing the challenge it poses to large enterprises, we recommend that organizations follow a prioritized, layered approach in addressing this vulnerability.

Since the Log4Shell vulnerability was first discovered, the Qualys Research Team has analyzed the threat and updated Qualys Cloud Platform to help customers respond quickly.

We recognize that for many organizations the scope of the challenge is large, as it involves all Java-based applications in their environment. Recognizing which application was written in Java, let alone if it uses a vulnerable version of Log4j, can be a challenge. As a result, Qualys recommends that organizations take a prioritized, layered approach to remediate and eliminate this vulnerability wherever it lives.

---

Log4Shell – 5 Key Things You Need to Know

1. Java is the third most used computer language.
2. Log4j is used in most Java based applications. You should assume that any application, home grown or purchased, in your environment that is based on Java – including web, server, database, desktop, and client applications (even games) – may be impacted and must be validated.
3. Detection is not straightforward, as there is no standard way of using Log4j inside Java applications, and therefore multiple detection techniques are required.
4. The vulnerability is very easy to exploit and exploit tools are already available to download. Attackers are actively exploiting this vulnerability at a rate of 100+ attacks per minute!
5. The US Cybersecurity & Infrastructure Security Agency (CISA) has directed all civilian agencies to mitigate CVE-2021-44228 by December 24, 2021 – Christmas Eve – which clearly communicates the urgent risk introduced by this vulnerability.

---

What Attackers Know and What They Are Doing

Log4Shell is a new, easy-to-exploit vulnerability that was discovered in mid-December 2021. It is potentially one of the most significant code errors ever discovered, given the prevalence of Java. Most of the world’s enterprises are still trying to figure out if they are impacted and to what extent. Because Java is commonly used to build web applications, it made Log4Shell easy to proliferate across the web. Even worse, most web applications connect to a backend application that is most likely also written in Java. This means that one successful exploit could result in additional exploits downstream.

The bottom line: compromises of public-facing web applications around the world with this newly discovered, easy to exploit vulnerability have a good chance of succeeding.  

Inevitably, many security firms have already reported seeing large-scale attacks against publicly facing web applications that leverage the Log4Shell vulnerability.

So What Can You Do

STEP 1: Quickly Scan Your External Attack Surface

As a first step, Qualys recommends that all organizations quickly scan their external attack surface (public-facing websites and applications) to identify any potential vulnerability by simulating the attack.  using the free service we have provided. 

Our Research Team has created dedicated attack simulations that mimic Log4Shell attack vectors currently in use. Customers can easily run those simulations directly from the Qualys cloud without the need to install any software or reconfigure their network. By running these simulations, customers can see what attackers see, and be alerted if one of their publicly available websites is exposed.

Qualys has made its Web Application Scanner (WAS) application available for everyone for 30 days.

STEP 2: Find Where You Are Vulnerable and Prioritize

A big challenge introduced by this vulnerability is detecting it. As Log4Shell may affect any Java application that uses a vulnerable version of Log4j, it is important to consider the following:

• Java is used in different ways for different applications, in some cases it is not straightforward to even recognize a Java application
• Java applications can run on different platforms and OSes, from servers to workstations to appliances
• By its nature the Log4j library can be embedded in nonstandard ways, which is making the detection of all vulnerable Log4j instances not a straightforward task

As such, Qualys offers a multi-layered approach to help our customers detect where they are vulnerable. These layers are comprised of three of our apps: CSAM, VMDR, and Container Security.

Qualys Cybersecurity Asset Management (CSAM)

Querying inventory is an efficient way to find Java-based software installed in your environment. However, since Java-based applications may be common in any environment, such queries may return a long list of applications that will require a time-consuming process to validate. It is better to focus your time on other higher priority tasks.

To help our customers run more efficient inventory queries for suspected Java applications, the Qualys Research Team has enriched the inventory data collected by CSAM. We can now flag applications that are recognized by the community as vulnerable to the Log4Shell exploit (based on this GitHub). Furthermore, by utilizing CSAM’s ability to tag internet-facing assets, those queries can focus first on your external facing Java-based applications that are flagged as vulnerable. CSAM integration with your CMDB provides another method for prioritization, as it will allow you to focus on your business-critical applications first.

Qualys Vulnerability Management Detection and Response (VMDR)

Qualys Research Team has added multiple signatured QIDs that are designed to detect this vulnerability on all assets in your organization.

As explained above, by its nature this vulnerability is harder to detect and will require a multi-layered approach for detection. Qualys recommends its customers use different types of detection methods that are designed to complement each other:

• First, a fast, accurate detection for commonly used Java and Log4j deployment methods. The benefit of this set of QIDs is their ability to be used as part of your regular VM scans as they are efficient and accurate. However, the downside is that they may miss some applications that do not use Java or Log4j in standard ways.
• Second, a complimentary, out-of-band, in-depth detection method. That is designed to detect the majority of Log4j vulnerable instances, regardless of the deployment method used or the application status. This is an accurate method of detecting the Log4Shell vulnerability but may require intensive computation and more time to scan. As such, this detection method should be used out-of-band and does not need to run as frequently as the faster detection methods mentioned above.

Note: even if the application does not log anything that can be compromised by an attacker, Qualys still recommends that you treat this application as vulnerable and patch it. Qualys detection logic assumes that a vulnerable application is one that has a vulnerable version of Log4j.

Qualys Container Security

As containers are common in many environments, and Java is a commonly used language for building applications that run in containers, scanning for the Log4Shell vulnerability in your containers is a critical next step. Qualys’ Container Security product offers multiple methods to help you detect Log4Shell in your container environment for running containers and container images. Qualys offers multiple methods to help you detect Log4Shell in your container environment. Initially, we recommend running a vulnerability scan against all your running containers. Similar to our VMDR scan mentioned above, those runtime scans will help identify all instances of this vulnerability in cases where the app is using the common methods of deploying Java and Log4J. But similar to VMDR detection, Qualys recommends utilizing our dedicated, in-depth detection to complement the runtime detection methods. This dedicated, in-depth detection logic for all vulnerable Log4j instances can interact with your build and/or deployment process and perform an in-depth scan of your container images. This in-depth container image scan can be triggered in three different stages of your container’s image lifecycle: during the build process, as the image is uploaded to the register, and before the image is deployed to production.

Qualys Container Security offers a comprehensive solution for detecting Log4Shell vulnerabilities across the entire lifecycle of the container from build time to runtime.

STEP 3: Remediation

Once your higher priority vulnerable applications are identified, we recommend that our customers begin their remediation processes. As the Log4Shell vulnerability may affect every Java-based application, different remediation methods will be required. Each should be based on the unique application type and function.

As vendors start to release patches to their Java-based vulnerable applications, we recommend using Qualys Patch Management to patch your Linux and Windows assets in an efficient way.

However, in some cases the vulnerable Java application will require a “surgical” fix as it cannot be patched. In such cases the patch management solution can be used to update the Log4j jar to a non-vulnerable version, or to delete the JNDI class as recommended by Apache.

STEP 4: Detect Exploits

Due to the complexity of detecting and remediating this vulnerability, we recommend utilizing Qualys EDR to help detect exploit attempts in real-time. Qualys EDR has been updated with specific content and workflows to help monitor and alert suspicious activities related to the Log4Shell exploit. Using the EDR tool, customers can view real-time threat reports and triage exploits in cases where a suspicious activity was detected. We at Qualys hope that this blog has provided you with some guideposts to follow when confronting how Log4Shell may threaten your environment. Please bookmark the Log4Shell section of our website and return regularly for the latest threat intelligence.